Detailed Notes
In this episode of the developer podcast, the hosts explore user stories, a crucial tool in gathering effective software requirements. Using a creative analogy comparing user stories to movie ratings, the episode explains how to create detailed and valuable user stories that go beyond the basics.
Read More... https://develpreneur.com/user-stories-unveiled-a-developers-guide-to-capturing-the-full-narrative
Stay Connected: Join the Developreneur Community
We invite you to join our community and share your coding journey with us. Whether you’re a seasoned developer or just starting, there’s always room to learn and grow together. Contact us at [email protected] with your questions, feedback, or suggestions for future episodes. Together, let’s continue exploring the exciting world of software development.
Additional Resources
* How to write effective user stories in agile development? (https://develpreneur.com/how-to-write-effective-user-stories-in-agile-development/)
* The Importance of Properly Defining Requirements (https://develpreneur.com/the-importance-of-properly-defining-requirements/)
* Changing Requirements – Welcome Them For Competitive Advantage (https://develpreneur.com/changing-requirements-welcome-them-for-competitive-advantage/)
* Creating Your Product Requirements (https://develpreneur.com/product-requirements/)
* Creating Use Cases and Gathering Requirements (https://develpreneur.com/creating-use-cases-and-gathering-requirements/)
Transcript Text
[Music] so this gets me to am I muted oh that's to mute me um I think I want to do user stories next because you had like while you're were talking I had this great little thought around user storage I think that's one we that um one second I like the going into user stories after that that's good um I also think we should Circle back down the road later about agile again but also this time um like do like discuss the points like how points should work because everywhere I work all the scrum Masters are like it should be this way but all the managers are like no it's this way it's and there's that balance between that's yeah that's a good conversation but it also falls into oh by the way hi hi everybody um that also that also goes into the whole yeah that's like there's a I've seen seen several times where it's a scrum Master manager sort of like battle of wills there but it really comes down to it's like whatever you decide that's like the worst I know it's the worst possible answer but it's like what you pick is the right one to do and don't change it from scrum to scrum just pick it go with it that's your metric and then go there um yeah I've seen that and I've like seen all kinds of different ways to do points and it's just I have my own way I like to do it that's but it's all built on sort of my estimates even with people I've worked with developers that are in the same roughly the same point system it's fun talking to them because they will Point things differently they will assign values a little differently from how I do it even within the um the overall approach that we use so that's a pretty cool one that I think agile scrum Sprints stuff like that itself may be a good little one to get into at some point is you just give like a do an agile special or maybe a twofer on that yeah and then with that follow with like de definition of done and when code goes out when when is code ready what really becomes interesting in the agile approach yeah because what is what makes Deployable useful software at the end of each Sprint that you're supposed to do so yep so we're GNA do user stories is that good okay well hello and welcome back we are continuing our developer journey and we are going to story time today we are going to talk about user stories I'm hoping I've got something that I just came up with it's an analogy that sticks with you with user stories but it also follows up well with our prior episode where we're talking about requirements Gathering those and user stories are a huge portion of that before we get into that my user story is I am one of the founders of developer or I'm not it's not really user story but we're hey go with it my name is Rob Broadhead I happen to be one of the founders I'm also a founder of RB Consulting where we use Simple ification integration and automation to take all of your code all your systems all that stuff that has grown into this big technology sprawl and we bring it down into a nice little nutshell so that you can use it maintain it and scale it on the other side who needs no scaling is Michael go ahead and introduce yourself hey everyone my name is Michael Mage and my story is I'm one of the co-founders of developer ner and I'm the founder of Envision QA where we help small midsize companies and Healthcare uh doctors and clinicians build software and automate their systems in a way that makes the job easier gets a job done and improves patient care or customer U performance so user stories I this is an analogy I just came up with and so pardon me if it goes off the rails at one point but I was thinking about this and I think this is a good um layer of the layers of the onion approach to getting your user stories into getting good requirements now user stories in general what you the the most General way to start if you've never done one is who are the users of the system and then what among those users it's what are they doing how do they use the system what is the story so if it's a let's say it's a system that's a back office system that the office manager uses on a daily basis they're going to have multiple stories because they may go in there to uh to enter a customer customer information to look up a customer to provide support to go maybe to go enter uh bills that have come in to enter payments that have come in to uh look up somebody in the HR System because they need to call them all of these are user stories that it is the path that you're going on to achieve a goal within that system now what we've we've talked before there's this thing called happy path which is basically I'm going to go from point A to point B I'm going to get on the system I have this problem I want to solve or this task I want to complete and these are the steps to get it done now here's my analogy let's think about that that's your G-rated movie right there that is like everything goes right that is the happy path everything's good the data is correct the data is clean the data is consistent the system works the way it's supposed to and the answer you get is exactly the answer you get now ideally most of the time that's what happens I don't know if that's true just like in the movie world there's not a lot of G-rated movies your next step is your PG there's a lot more of those that's more common and this is where we've built the happy path now we've talked about that with our user and said okay well if everything goes right what does it look like now we start looking a little bit at it we start picking at a little bit it's like well okay what if it may be things like what if this data is outside of normal range or what if there is a typo you know what if this phone number they put an A in there instead of numbers you things like what are these things that go can go wrong and then how do we handle them do we let the user know do we just push it through the system what do we do and it's this is getting them thinking through you know as you're building the user story and as your customer you're working with them what are the essentially sort of the exceptions or what are the messages and some of this is even within the happy path because it's things like okay you get all the way to the end does anybody need to know it do you need to send an email do you need to pop a little you were successful message things like that and so PG is where we you go into that next step is we start picking at the happy path a little bit and we're adding to it and saying okay this assume everybody is on the same page and everything's awesome well but now we're not so let's do we have to notify people do we have some side effects and things like that and then you start mov moving into now like the R-rated stuff which is where things are not good and this is where people have like for example what happens if you're entering a person a user's name and you misspell the name we don't know that you've misspelled the name necessarily but what happens there do you do validation checks if they're entering a city and a state and a zip code what happens if they put the incorrect zip code what if they put a try to put a three-digit number in there for us it's going to be at least a five-digit zip code what is it if they don't put a value in are there things that are required are there things that aren't required are there things that are in the requirements that must connect to other things for example if you have a zip code and you have a state and that zip code doesn't exist in that state do we need to verify that do we need to stop that from moving forward if you're doing like a bank account Transaction what happens if you try to withdraw money and they don't have funds in the account what happens if somebody's going through and entering data and they just put you know a AAA bbbb CCC what is that what if they enter an email address that you know is like a.com or something like that this is where you're getting into the stuff where it's like what about these situations where somebody is just aept or is trying to just like fly through the system and just get stuff slammed in as opposed to doing it the right way or maybe even intentionally which is where we get into like the rated X stuff they're intentionally trying to crash or screw with the system so this is where you talk about like sequel injection and things like that it's like what happens if somebody tries to shove something in here that's effectively code that the system decides it's going to try to execute so you can go from the happy path and sunshine and rainbows to rated X Jason versus Michael Myers thing and all those kind of stuff me it's like you can go into the horror movie side of it when you're going through those that's when you're going to get really full featured user stories yes I did get back to my original Point that's where you get your really full featured user stories because you're peeling that onion off you're saying okay this is good and then what what if this happens what about this what if this isn't right and as you start picking out what every step is what every data item is as you're examining each of those and what can go wrong effectively now you are fleshing out a true story it's not just some little you know paragraph of this is what it is now you've got like full plot and character development in your user story and that is where you're going to have super detailed super valuable requirements and now I'm going to take a breath and see what you thought about that one yeah I I really liked your approach to that I would like to add a couple things to it though so I like how you kind of walk through the different analogies of movies and ratings with different stories and different levels of chaos that potentially comes from trying to Define these stories however in addition to that some of the things that come to my mind are so you have the sto like you're writing these stories but as developers I've seen this more often than not instead of listening for the story they start injecting code or methodologies into the stories which don't need to be there it's like the person needs an accounting software system or a payroll system cool they don't care that written in C Java they don't care if there's a database behind they just want a payroll system an accounting system so stories don't necessarily translate to Tech the story is what we are saying it is a story this is what I want this is the journey from point A to point B you're going to have a beginning a middle and an end how do I get there tell me about it tell me how the system is going to work tell me how you want this feature to be implemented and you go through that process you're going to have to for lack of a better term shut up put on your hearing aids crank them up and listen to the customer and from developers when we're busy that can be hard we can fall into that crutch where yeah I I heard you say that but in reality I didn't fully hear the story I heard parts of the feature and only parts of the feature get implemented so you have to be very careful that the story that you are being told or the story that you are gathering that you get the details of the story for the full feature you may not get everything so the the other thing to think about too in addition to that is there's different levels of stories not necessarily ratings but levels you have your feature complete story which is what I need to just get a working system that complies with the basic of this story okay I need a payroll system I want to get paid so I need a system that will pay me cool that is the Baseline story now I start hiring people oops my current system that's in then a new feature a new story to be added on to an existing application all right now we have to add some additional requirements okay now I have multiple people who's are you know do I have to worry about managing what type of security constraints do I have who can see what I don't want people seeing my payroll information so these are stories that have to be flushed out and then you get in the bigger systems where you hand this off to okay so now I want to sell this system to someone else well now there's other features so you have at the beginning what you need the basic story to build the application the happy pack they must have features of your application then you have the nice to have features or new features that get implemented later these stories are additions to the main story these could be spin-offs these could be you know book two book three book four which would be version two three and four of your software or they could essentially be integration pieces that just kind of tie in to your story so that are different layers and different levels to story writing listening to the stories and then writing the applications or asking all those what if questions to define the story The Right Way Rob that's that really adds to that yeah wow my my analogy was awesome because now I'm thinking about it is like that's one of the other things is are you building a documentary where you're just like Michael said where it's just about the features or is this a summer blockbuster where you're not just building features but you are putting a wow factor in it that's going to like draw people in regardless I mean there's the feature but as well on top of the feature because that's sometimes what you're going to get it's not it's people are saying hey I don't want just I don't want something where just just going to come and they're going to be able to select a product from my store I want them to want to sit on my store and play around with selecting products because that's how awesome the environment is it's there is also as he said there's like you think almost like there are levels and there are different we even say genres of stories and user stories do the same way and this is where you get into reading between the lines a little bit and what as Michael mentioned is like really listening to the story as it is not solving it while they're doing it but letting them talk through that story because you're going to want to get that stuff like wait a minute you mentioned this feature it seems like you need more than just that feature maybe you need to like you know it's it's maybe it's something as like you mentioned entering this data this piece of data but what if it sounds like it's hard to get that data so do we need to also have as a feature a way to look that up or to validate that or something like that or a way to go jump and view that and Shop it would be like in a shopping cart you can add products but if you only know SKS your shopping experience is going to be very difficult what you want is a catalog behind that you know shopping cart and things like that and it's things like okay and the checkout process how does that look and there's there's so many things around the user stories that I think the more you realize they are stories and not just bullet point items necessarily the more you're going to be able to ask the right questions and this is where you can really help your customer take it to the next level because instead of just regurgitating what they give you you can help talk them through and think through some of these processes and say okay this is what you've got this is where you want to go how can we make adjustments to that Journey how can we make it easier how can we make it faster is there maybe something that would mean we even need to take that Journey because sometimes you do that as you get into the stories you're like wait a minute that story we talked about last week is exactly the story we're talking about this week except for it's only a different user so is that really just the same user story and two people can access it there's things like that I don't want to run too long because I got places to go and things to do uh even though you may think that's just virtually and we just live here all the time we do have lives outside of the yeah outside of this little box here that we're in or your your your ear holes if you're listening to us basically we are not just you know mindless or face or bodyless voices out there fantasms that are just talking so anyways I digress more than a little bit as always reach out and just any information that you have feedback suggestions comments love it all we do this partially for us partially for you more so for you than us so we'd love to do topics questions in areas that are concerns for you as you are becoming better developers maybe there's some ways that we can we can sit down and talk through some of the things that are uh stying you or just challenges or your own pain points or your own stories user stories that we can help you with to work through and get you to that point where you are a better developer and sometimes it just takes a couple of different people a couple different perspectives to get us over that hump shoot us an email at info developer.com check us out at developer.com send us got a contact form we were out on Twitter SL well X formerly Twitter at uh develop anur you can check us out there follow us you can see us wherever you get podcasts we're there YouTube out on developer Channel and there's other stuff around that it's not just the podcast but we also have a lot of uh other content tutorials things of that nature and then there's school. developer.com where funny enough we have tutorials and classes and things that you can learn as well we're just trying to we just spew all the this content out there trying to help you guys out and actually it helps us out as well it's amazing how often we go to search something and we end up going back to our page to be like where we wrote the steps to knock that out 10 years ago and we haven't had to use it since don't wait 10 years before you come back here though go out there and have yourself a great day great week and we will talk to you next time bonus material so I kept it out of the audio but once you have find your stories don't just go write the code you can break down the stories into the smaller chunks and then because again this could be a feature story this could be a full featured story where you have to build everything from scratch but typically what you can do is you can take those stories down you break it down into the individual components and then these essentially will become at the end of the movie did I check all these boxes this is going to be your checklist these will become your unit tests your integration tests your user acceptance criteria hell it may even be your regression or smoke testing but your story is where you get all the checkpoints you need so at the beginning of the story by the end did I touch all the the touch points of the story if I didn't then what did I miss I did not tell a complete story so I need to go back and figure out what I need to plug back in to get the full story yeah that is truly the those are the stories are your requirements these are things that you have to address they are not as we talked about a little bit there the they are not your design there's not necessarily probably shouldn't be anywhere in the stories references to programming languages or really even databases and things like that now you may store data and stuff like it's just say hey the system stores X but whatever that is it may be in a database it may be out in the cloud somewhere it could be in a relational database it could be in a nosql database it could be on a flat file there's like there's so many ways those things can be done that gets into design side of it you don't want to clutter your stories with the implementation with the technology you want to leave that open as long as possible and then the design is where you start picking apart those stories and you start figuring out how you're going to put those pieces together and then of course as you flow through there there's going to be you should see all of the items that were addressed in the stor should be addressed by your design should be addressed in implementation and then those really lead you know make it really easy for the testers because then they just easily write a little test script that walks through those items and checks to make sure they exist that I think will do it because I got to run I got one of these fun customers and I got crap to do so uh you know hey busy people we got bills to pay that being said as always we'd love to get any feedback that you have leave us comments U check us out twice a week we're going to drop these out check out the the developer North site we do sometimes throw additional blog articles and other stuff out there as well I don't think we have have done as much now but as usually we get little seasonal we get times a year that things settle down for us and we can knock out more of that kind of information get that stuff out there and of course we do requests so if there's anything that you that you would like us to talk about maybe a tutorial You' like us to do a technology you'd like us to to review any of that kind of stuff more than happy to do so again info@ developer.com that's d v p r ne.com it's also all over the place here on since you're watching you can see the developer nor thing all over the place use that leave us you know comments however you want to get to it that being said we're going to wrap this one up let you guys get to it have yourself a great night great evening great week and we will talk to you next time [Music]
Transcript Segments
[Music]
so this gets me to
am I muted oh that's to mute me um I
think I want to do user stories next
because you had like while you're were
talking I had this great
little thought around user storage I
think that's one we that
um one
second I like the going into user
stories after that that's good um I also
think we should Circle
back down the road later about agile
again but also this time um like do like
discuss the points like how points
should work because everywhere I work
all the scrum Masters are like it should
be this way but all the managers are
like no it's this way it's and there's
that balance between that's yeah that's
a good conversation but it also falls
into oh by the way hi hi everybody um
that
also that also goes into the
whole yeah that's like there's a I've
seen seen several times where it's a
scrum Master manager sort of like battle
of wills there but it really comes down
to it's like whatever you decide that's
like the worst I know it's the worst
possible answer but it's like what you
pick is the right one to do and don't
change it from scrum to scrum just pick
it go with it that's your metric and
then go there um yeah I've seen that and
I've like seen all kinds of different
ways to do points and it's just I have
my own way I like to do it that's but
it's all built on sort of my estimates
even with people I've worked with
developers that are in the same roughly
the same point system it's fun talking
to them because they will Point things
differently they will assign values a
little differently from how I do it even
within the um the overall approach that
we use so that's a pretty cool one that
I think agile scrum Sprints stuff like
that itself may be a good little one to
get into at some point is you just give
like a do an agile special or maybe a
twofer on that yeah and then with that
follow with like de definition of done
and when code goes out when when is code
ready what really becomes interesting in
the agile approach yeah because what is
what makes Deployable useful software at
the end of each Sprint that you're
supposed to
do so yep so we're GNA do user stories
is that good
okay well hello and welcome back we are
continuing our developer journey and we
are going to story time today we are
going to talk about user stories I'm
hoping I've got something that I just
came up with it's an analogy that sticks
with you with user stories but it also
follows up well with our prior episode
where we're talking about requirements
Gathering those and user stories are a
huge portion of that before we get into
that my user story is I am one of the
founders of developer or I'm not it's
not really user story but we're hey go
with it my name is Rob Broadhead I
happen to be one of the founders I'm
also a founder of RB Consulting where we
use Simple ification integration and
automation to take all of your code all
your systems all that stuff that has
grown into this big technology sprawl
and we bring it down into a nice little
nutshell so that you can use it maintain
it and scale it on the other side who
needs no scaling is Michael go ahead and
introduce yourself hey everyone my name
is Michael Mage and my story is I'm one
of the co-founders of developer ner and
I'm the founder of Envision QA where we
help small midsize companies and
Healthcare
uh doctors and clinicians build software
and automate their systems in a way that
makes the job easier gets a job done and
improves patient care or customer U
performance so user stories I this is an
analogy I just came up with and so
pardon me if it goes off the rails at
one point but I was thinking about this
and I think this is a good um layer of
the layers of the onion approach to
getting your user stories into getting
good requirements now user stories in
general what you the the most General
way to start if you've never done one is
who are the users of the system and then
what among those users it's what are
they doing how do they use the system
what is the story so if it's a let's say
it's a system that's a back office
system that the office manager uses on a
daily basis they're going to have
multiple stories because they may go in
there to uh to enter a customer customer
information to look up a customer to
provide support to go maybe to go enter
uh bills that have come in to enter
payments that have come in
to uh look up somebody in the HR System
because they need to call them all of
these are user stories that it is the
path that you're going on to achieve a
goal within that system now what we've
we've talked before there's this thing
called happy path which is basically I'm
going to go from point A to point B I'm
going to get on the system I have this
problem I want to solve or this task I
want to complete and these are the steps
to get it done now here's my analogy
let's think about that that's your
G-rated movie right there that is like
everything goes right that is the happy
path everything's good the data is
correct the data is clean the data is
consistent the system works the way it's
supposed to and the answer you get is
exactly the answer you get now ideally
most of the time that's what happens I
don't know if that's true just like in
the movie world there's not a lot of
G-rated movies your next step is your PG
there's a lot more of those that's more
common and this is where we've built the
happy path now we've talked about that
with our user and said okay well if
everything goes right what does it look
like now we start looking a little bit
at it we start picking at a little bit
it's like well okay what if it may be
things like what if this data is outside
of normal range or what if there is a
typo you know what if this phone number
they put an A in there instead of
numbers you things like what are these
things that go can go wrong and then how
do we handle them do we let the user
know do we just push it through the
system what do we do and it's this is
getting them thinking through you know
as you're building the user story and as
your customer you're working with them
what are the essentially sort of the
exceptions or what are the messages and
some of this is even within the happy
path because it's things like okay you
get all the way to the end does anybody
need to know it do you need to send an
email do you need to pop a little you
were successful message things like that
and so PG is where we you go into that
next step is we start picking at the
happy path a little bit and we're adding
to it and saying okay this assume
everybody is on the same page and
everything's awesome well but now we're
not so let's do we have to notify people
do we have some side effects and things
like that and then you start mov moving
into now like the R-rated stuff which is
where things are not good and this is
where people have like for example what
happens if you're entering a person a
user's name and you misspell the name we
don't know that you've misspelled the
name necessarily but what happens there
do you do validation checks if they're
entering a city and a state and a zip
code what happens if they put the
incorrect zip code what if they put a
try to put a three-digit number in there
for us it's going to be at least a
five-digit zip code
what is it if they don't put a value in
are there things that are required are
there things that aren't required are
there things that are in the
requirements that must connect to other
things for example if you have a zip
code and you have a state and that zip
code doesn't exist in that state do we
need to verify that do we need to stop
that from moving forward if you're doing
like a bank account Transaction what
happens if you try to withdraw money and
they don't have funds in the
account what happens if somebody's going
through and entering data and they just
put you know a AAA bbbb
CCC what is that what if they enter an
email address that you know is like
a.com or something like that this is
where you're getting into the stuff
where it's like what about these
situations where
somebody is just aept or is trying to
just like fly through the system and
just get stuff slammed in as opposed to
doing it the right way or maybe even
intentionally which is where we get into
like the rated X stuff they're
intentionally trying to crash or screw
with the system so this is where you
talk about like sequel injection and
things like that it's like what happens
if somebody tries to shove something in
here that's effectively code that the
system decides it's going to try to
execute so you can go from the happy
path and sunshine and rainbows to rated
X Jason versus Michael Myers thing and
all those kind of stuff me it's like you
can go into the horror movie side of it
when you're going through those
that's when you're going to get really
full featured user stories yes I did get
back to my original Point that's where
you get your really full featured user
stories because you're peeling that
onion off you're saying okay this is
good and then what what if this happens
what about this what if this isn't right
and as you start picking out what every
step is what every data item is as
you're examining each of those and what
can go wrong effectively now you are
fleshing out a true story it's not just
some little you know paragraph of this
is what it is now you've got like full
plot and character development in your
user story and that is where you're
going to have super detailed super
valuable
requirements and now I'm going to take a
breath and see what you thought about
that
one yeah I I really liked your approach
to that I would like to add a couple
things to it though so I like how you
kind of walk through the different
analogies of movies and ratings with
different stories and different levels
of chaos that potentially comes from
trying to Define these
stories however in addition to that some
of the things that come to my mind are
so you have the sto like you're writing
these stories but as
developers I've seen this more often
than not instead of listening for the
story they start injecting code or
methodologies into the stories which
don't need to be there it's like the
person needs an accounting software
system or a payroll system cool they
don't care that written in C Java they
don't care if there's a database behind
they just want a payroll system an
accounting system so stories don't
necessarily translate to Tech the story
is what we are saying it is a story
this is what I want this is the journey
from point A to point B you're going to
have a beginning a middle and an end how
do I get there tell me about it tell me
how the system is going to work tell me
how you want this feature to be
implemented and you go through that
process you're going to have to for lack
of a better term shut
up put on your hearing aids crank them
up and listen to the customer and from
developers when we're busy that can be
hard we can fall into that crutch where
yeah I I heard you say that but in
reality I didn't fully hear the story I
heard parts of the feature and only
parts of the feature get implemented so
you have to be very careful that the
story that you are being told or the
story that you are gathering that you
get the details of the story for the
full feature you may not get everything
so the the other thing to think about
too in addition to that is there's
different levels of stories not
necessarily ratings but levels you have
your feature
complete story which is what I need to
just get a working
system that complies with the basic of
this story okay I need a payroll system
I want to get paid so I need a system
that will pay me cool that is the
Baseline story now I start hiring people
oops my current system that's in then a
new feature a new story to be added on
to an existing application all right now
we have to add some additional
requirements okay now I have multiple
people who's are you know do I have to
worry about managing what type of
security constraints do I have who can
see what I don't want people seeing my
payroll information so these are stories
that have to be flushed
out and then you get in the bigger
systems where you hand this off to okay
so now I want to sell this system to
someone else well now there's other
features so you have at the
beginning what you need the basic story
to build the application the happy pack
they must have features of your
application then you have the nice to
have features or new features that get
implemented later these stories are
additions to the main story these could
be spin-offs these could be you know
book two book three book four which
would be version two three and four of
your
software or they could essentially be
integration pieces that just kind of tie
in to your
story so that are different layers and
different levels to story writing
listening to the stories and then
writing the applications or asking all
those what if questions to define the
story The Right
Way Rob that's that really adds to that
yeah wow my my analogy was awesome
because now I'm thinking about it is
like that's one of the other things is
are you building a documentary where
you're just like Michael said where it's
just about the features or is this a
summer blockbuster where you're not just
building features but you are putting a
wow factor in it that's going to like
draw people in regardless I mean there's
the feature but as well on top of the
feature because that's sometimes what
you're going to get it's not it's people
are saying hey I don't want just I don't
want something where just just going to
come and they're going to be able to
select a product from my store I want
them to want to sit on my store and play
around with selecting products because
that's how awesome the environment is
it's there is also as he said there's
like you think almost like there are
levels and there are different we even
say genres of stories and user stories
do the same way and this is where you
get into reading between the lines a
little bit and what as Michael mentioned
is like
really listening to the story as it is
not solving it while they're doing it
but letting them talk through that story
because you're going to want to get that
stuff like wait a minute you mentioned
this
feature it seems like you need more than
just that feature maybe you need to like
you know it's it's maybe it's something
as like you mentioned entering this data
this piece of data but what if it sounds
like it's hard to get that data so do we
need to also have as a feature a way to
look that up or to validate that or
something like that or a way to go jump
and view that and Shop it would be like
in a shopping
cart you can add products but if you
only know
SKS your shopping experience is going to
be very difficult what you want is a
catalog behind that you know shopping
cart and things like that and it's
things like okay and the checkout
process how does that look and there's
there's so many things around the user
stories that I think the more you
realize they are stories and not just
bullet point items
necessarily the more you're going to be
able to ask the right questions and this
is where you can really help your
customer take it to the next level
because instead of just regurgitating
what they give you you can help talk
them through and think through some of
these processes and say okay this is
what you've got this is where you want
to go how can we make adjustments to
that Journey how can we make it easier
how can we make it faster is there maybe
something that would mean we even need
to take that Journey because sometimes
you do that as you get into the stories
you're like wait a minute that story we
talked about last week is exactly the
story we're talking about this week
except for it's only a different user so
is that really just the same user story
and two people can access it there's
things like
that I don't want to run too long
because I got places to go and things to
do uh even though you may think that's
just virtually and we just live here all
the time we do have lives outside of the
yeah outside of this little box here
that we're in or your your your ear
holes if you're listening to us
basically we are not just you know
mindless or face or bodyless voices out
there fantasms that are just talking so
anyways I digress more than a little bit
as always reach out and just any
information that you have feedback
suggestions comments love it all we do
this partially for us partially for you
more so for you than us so we'd love to
do topics questions in areas that are
concerns for you as you are becoming
better developers maybe there's some
ways that we can we can sit down and
talk through some of the things that are
uh stying you or just challenges or your
own pain points or your own stories user
stories that we can help you with to
work through and get you to that point
where you are a better developer and
sometimes it just takes a couple of
different people a couple different
perspectives to get us over that hump
shoot us an email at info developer.com
check us out at developer.com send us
got a contact form we were out on
Twitter SL well X formerly Twitter at uh
develop anur you can check us out there
follow us you can see us wherever you
get podcasts we're there YouTube out on
developer Channel and there's other
stuff around that it's not just the
podcast but we also have a lot of uh
other content tutorials things of that
nature and then there's school.
developer.com where funny enough we have
tutorials and classes and things that
you can learn as well we're just trying
to we just spew all the this content out
there trying to help you guys out and
actually it helps us out as well it's
amazing how often we go to search
something and we end up going back to
our page to be like where we wrote the
steps to knock that out 10 years ago and
we haven't had to use it since don't
wait 10 years before you come back here
though go out there and have yourself a
great day great week and we will talk to
you next time bonus
material so I kept it out of the audio
but once you have find your stories
don't just go write the
code you can break down the
stories into the smaller chunks and then
because again this could be a feature
story this could be a full featured
story where you have to build everything
from scratch but typically what you can
do is you can take those stories down
you break it down into the individual
components and then these essentially
will
become at the end of the movie did I
check all these boxes this is going to
be your checklist these will become your
unit tests your integration tests your
user acceptance criteria hell it may
even be your regression or smoke testing
but your
story is where you get all the
checkpoints you need so at the beginning
of the story by the end did I touch all
the the touch points of the story if I
didn't then what did I miss I did not
tell a complete story so I need to go
back and figure out what I need to plug
back in to get the full
story yeah that is truly the those are
the stories are your requirements these
are things that you have to address they
are not as we talked about a little bit
there the they are not your design
there's not necessarily probably
shouldn't be anywhere in the stories
references to programming languages or
really even databases and things like
that now you may store data and stuff
like it's just say hey the system stores
X but whatever that is it may be in a
database it may be out in the cloud
somewhere it could be in a relational
database it could be in a nosql database
it could be on a flat file there's like
there's so many ways those things can be
done that gets into design side of it
you don't want to clutter your stories
with the implementation with the
technology you want to leave that open
as long as possible and then the design
is where you start picking apart those
stories and you start figuring out how
you're going to put those pieces
together and then of course as you flow
through there there's going to be you
should see all of the items that were
addressed in the stor should be
addressed by your design should be
addressed in implementation and then
those really lead you know make it
really easy for the testers because then
they just easily write a little test
script that walks through those items
and checks to make sure they
exist that I think will do it because I
got to run I got one of these fun
customers and I got crap to do so uh you
know hey busy people we got bills to pay
that being said as always we'd love to
get any feedback that you have leave us
comments U check us out twice a week
we're going to drop these out check out
the the developer North site we do
sometimes throw additional blog articles
and other stuff out there as well I
don't think we have have done as much
now but as usually we get little
seasonal we get times a year that things
settle down for us and we can knock out
more of that kind of information get
that stuff out there and of course we do
requests so if there's anything that you
that you would like us to talk about
maybe a tutorial You' like us to do a
technology you'd like us to to review
any of that kind of stuff more than
happy to do so again info@ developer.com
that's d v p r ne.com it's also all over
the place here on since you're watching
you can see the developer nor thing all
over the place use that leave us you
know comments however you want to get to
it that being said we're going to wrap
this one up let you guys get to it have
yourself a great night great evening
great week and we will talk to you next
time
[Music]