Detailed Notes
In this episode of the Building Better Developers podcast, the hosts delve into the critical role of effective user stories in software development. The discussion highlights how these stories serve as a powerful tool for conveying system requirements and improving both development and testing processes.
Read More... https://develpreneur.com/transform-your-projects-the-ultimate-guide-to-effective-user-stories
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
* Updating Developer Tools: Keeping Your Tools Sharp and Efficient (https://develpreneur.com/updating-developer-tools-keeping-your-tools-sharp-and-efficient/)
* Building Your Personal Code Repository (https://develpreneur.com/building-your-personal-code-repository/)
* Your Code Repository and Ownership of Source – Consulting Tips (https://develpreneur.com/your-code-repository-and-ownership-of-source-consulting-tips/)
* Using a Document Repository To Become a Better Developer (https://develpreneur.com/using-a-document-repository-to-become-a-better-developer/)
Transcript Text
[Music] and we're back sort of uh so next episode let's talk about what our topic is going to be I had a really good one as we were going through the prior one I want to where was I going with this it had to do with requirements and Gathering those I believe oh I don't think we've talked about user stories I want to get into a little bit like what makes a good user story I think we've referred to them dozens if not hundreds if not thousands of times but I don't know that we've ever actually talked about user story specifically so I was thinking this is one we can sort of you not really go too much into like the because there's a template out in the book and we can I'll reference that because we're Shameless like that but um I think sort of walking through some the things like how do you what is a story what is a user story because people talk about it all the time and it is one of those things that it's like that's the fun thing about working with newer developers is sometimes you'll they'll ask questions like what the heck is a user story you've mentioned it a lot of times like everybody knows what it is and I don't and I'm like you know what that's not a bad idea because I have also seen a bunch of different ones so I think I have a feeling whatever I lay out you'll have some modifications to it because you've seen you know had different experience you've seen different user stories as well how about that for a topic yeah I like that one and then for the one after this I think I have a great idea so if we do user stories now let's maybe do prototyping maybe mockups like because I don't think we've talked about that either and from the previous one that made me think about that one as well so I like yours as a good followup but maybe the followup to this one would be that one so put that in the yeah put that in the slack notes there and we'll uh in the podcast ideas and we will knock that one out next time around uh because that's a good one I like that too it's sort of like what is that that and clickable demo is uh very near and dear to my heart while you're doing that I'll kick us off well hello and welcome back we are building better developers we are the developer or podcast we are talking this time our topic like I'm going to write I'm going to spoiler alert topic this time around is we're going to talk about user stories we're not about telling stories about the around the campfire we're talking about user stories in a technical sense which I think a lot of people have an idea that like oh yeah user stories but if you try to nail them down down then it's going to take them a minute to figure out like what actually is a user story but before we do that my user story I'm Rob Broadhead I am one of the founders of develop andur building better developers I'm also a founder of RB Consulting where we help you leverage your technology and all of your investments in that wherever we can usually through simplification Automation and integration and finding the various ways for you to take that big nasty bowl of spaghetti and turn it into something very nice and easy to use good thing bad thing I say good thing that has happened in the last week um these are always it's sort of fun when you get to a point where you've got your own company and you're you know or side gig or or Consulting and stuff like that and when you just get sort of a call out of the blue where what especially when it starts with like this one was awesome it started with do you know X and that's not Twitter I'm just going to say just not to go into it but it's like do you know this thing and I'm like yes that was literally my I was like because I couldn't add any more to it get an email do you know this particularly with this platform yes okay 10 minutes later I get this thing hey can you jump on a call in a little bit turned out to be an hourong call turned out to be something that suddenly I'm like the the expert in the room and I was because basically I was like okay I've done this before apparently nobody else had but it turned into like a little mini gig it'll probably be you know it's a couple hours here or there but it's still those are always good things bad thing bad thing bad thing bad thing bad thing uh oh bad thing this actually goes a little bit into our psychopath thing that we talked about last time around I had this really cool I had this system that we built initially it was very simple it was not that comp you know it's not very complicated it's like it's run it all in one server it's great we found out as we got into it that you really want to distribute it it was built it really needs to be a distributed system of some sorts I'm like cool I'm going to do this so I might go crank it restructure everything and basically try to put all of the distributed Parts on one machine because it's just like hey it's really it shouldn't be that much more we're just breaking apart and then later we can offload this stuff so we can scale from one server to a billion servers if we need to and so I I go in and I crank these things up and it's you know there is a little bit of extra overhead because I was using like celery for the task manager and stuff like that and so it's like all right we're you we get the beat going and it's starting to crank through this stuff I had to go to it was an Amazon server I had to go to AWS and shut the server down to be able to do something with it and it took a while to shut it down it locked itself up so bad and it was one of those that it worked great when I was on my like you know eight processor work machine that's got like 64 gig of RAM or something but when you go down that little ec2 tiny instance or whatever it wasn't that tiny but it was not that but it was like two processor a gig of RAM I could hear it screaming from here I mean it was just one of those it's like not a good thing so sometimes you want like luckily it wasn't like production or anything like that but it is one of those where you're like sometimes you want to like inch yourself into it instead of just like okay I'm gonna fire it all off and then next thing you know you have brought that thing to the ground to such level that you cannot get back on your server so that's probably not a good thing and I took too long but I'm going to go ahead anyways and you on to Michael let him introduce yourself himself and see where he can can he can he top that want I catch my bre that was funny sorry hey everyone my name is Michael M I'm one of the co-founders of developer also the founder of Envision QA if you're looking to transform your business with customer software Solutions hey we're here to help we offer tailored software and quality solutions to optimize the and performance reliability of your e-commerce platform pitcher flawless user experience increased sales and a comprehensive Edge in the market good and bad uh good making great progress with a lot of the customers I'm working with right now things are moving smoothly even though we've had a few hiccups for that listen last episode uh bad um it's fall allergy season is upon us and it's going to be hay fever heck till we get cold so that's my bad yeah just as a quick side note to that we were to place we won't name it we'll just it it rhymes with uh I don't know brick kill K and um we were sitting there and it was me and my son we both have allergy issues and daughter and wife were there and we're we're eating and we had a sneeze Fest it was like I sneeze he sneeze I sneeze he sneeze I sne there's like eight or nine in a row each of us it was just it was almost like volleyball was sneezes it was just I had a whole pile of like of of napkins and by the time we're done we're like let's just blow our noses and go get a whole other pile of napkins all right back to user stories now user stories I think a lot of people sort of get sometimes they over complicate them sometimes they're like trying to figure out too much how to do it uh we'll call it like the correct way and I'm using air quotes if you're on listening to the podcast but the like the correct way where it's like this is the way that I was taught by you know a Six Sigma Black Belt or whatever the heck it is or something like that I think about user stories they are really just a more detailed a better way I think and I think a lot of people probably would agree to convey how something works than a flowchart because at the end of the day it is more or less like a flowchart when you think of like particularly when you think of like you've got swim lanes and and the decision boxes and stuff like that thing about a user story is it instead of it being those little points of the boxes that are your the items in your chart the objects in your chart and then little flows it is now it is a story it is something that flows as a discussion of it now some key the thing about user stories in general is there are some data items that you need to make from properties you need to have for your story for it to be useful and for it to make sense now there's going to be other stuff that you will see because there may be things like you people have like IDs or specific names or codes or short names or things like that that are basically a way to uh to either categorize them or sometimes to link them but effective user stories can link to each other anyways you shouldn't really have to do that those are really more like convenience functions in building out your user stories now that the thing you want to have is a title to your story of some sort a name or something like that and it's just a way this is really just a way to organize your stories and to share with other people without going through the whole story so the user login story you say that and now people like okay that's a user I know what you're talking about even if they haven't read it they at least know that they can if they need to know the details now in any user story you have an actor or actors and you can call them this is like gives it away a little bit you need a user or users to have a user story and this is actually key because sometimes we we struggle with what the actor is and talking about the actor so a lot of times before you get into building user stories for your your system you also need to spend some time thinking about who are the actors who are the users and a lot of times those questions are what are the roles or profiles or permissions things like that and sometimes it's very easy because it's like you have a a super user a regular user and a readon user or something like that but often it gets much more complicated very quickly and you want to make sure when you're going through doing the user stories that it is a specific user that you're talking about now it may be that you can take that same story and say well this story works for all of the users because maybe it's something like login it's any user but is it really because you may have a user that is logged in that is registered and a different user that is unregistered and now it's a different story because you have to figure out how did they how do they get registered to get to the login different from a path now with the story you're usually going to have some a story is g to have progression so it is going to have steps however you refer to them whether it is uh key items or whether it is steps and usually it does have some sort of flow it does have sort of a you're going from point A to point B as part of the story so you at least have a a starting point and an end point now those steps can be between them but a lot of times those are key is the starting point and the end point are also going to give you assumptions which you're actually going to have all through it so in your starting point this is a starting point and there are going to be assumptions or maybe requirements based on how do I get to this point how do I get to the starting point so it is uh you know simp questions that often be like am I log in uh have I already done certain other things for example let's take an ATM kind of thing would you're just going to an you're doing a user story to get money out of an ATM machine well part of that story you know just sort of cutting around moving around it part of that story is entering your uh your pen number your pen for your card most likely or retina scan or however it is that you authenticate yourself to your card well somewhere in there there's an assumption that you've put the card into the reader or something along those lines so depending on where your story begins that's where you that's how you set the stage for the story is what are my requirements and maybe what are my inputs or what are my assumptions on the back end of that it is okay what is the output what state has changed uh what things now need to persist potentially and what things get to go away now those can be part of the steps within the story but that's really where you get into details around each of those steps and a lot of times there there's many things I've seen them called extensions sometimes they're called exceptions sometimes it's just addenda or additional information because it's things like the story is a b c d this is where we go and then we go to B we go to C we go to D the exceptions extensions or whatever you are those additional notes are at each step here are some some some assumptions or here are some validations or here are some verifications or here are notifications so all of those things that could happen and there's all sorts of little families of them really can be applied to each single step now they may may not matter for each it may be a very simple step and there's not a lot that matters but then there going to be some where it all matters so when you're plotting out your story this is much like again going back to the whole psychopath thing is you have your your user story is your happy path but within that user's story you do need to Branch out to the other path if you're old enough or have stumbled across a thing called Choose Your Own Adventure books that used to exist years and years ago it is very much like that because what they would do is you would start on page one and then you it was just decision trees and so whatever your decision is would take you a different page now it could be a 100 pages in that book any given path was not going to hit all 100 pages I mean I don't think there was any possible way to do it but you would have all these different paths and that's still your your user story but within that you need to have all of the Alternatives that here all of your other Adventures that you choose along the way to the user story I pause there because I I kept a little high level I did get into some details but I want to I want to throw this out to you and see where you can start fleshing some of that out and add your own flavor to the story as well yeah so as you're thinking about user stories from a tester's perspective we think about user stories more is a blackbox testing you have information in information out so your story is going to talk about what it is that you're going to be doing and what output you should have you really don't get into the inner workings that's more the white box gray box testing with user stories like Rob mentioned and we've talked about login is it's you have a story you have a beginning and an end but you have all these other Pathways or conditions that could potentially happen a story should be a One andone requirement there should be one story One path that you can go if you have branching pass you have other stories for instance user wants to uh let me back up so we have a login page we have user validation so one user story is a valid registered user can log into the system with a valid username and a valid password click login they're logged into the system another use case or user story is I am an a unregistered user trying to log into the system with some username some password I should not be allowed to log into the system and then you have the other situation again I am a registered user I'm logging in with my user name but whoops I entered in the wrong password I should get you know invalid password or some message returned back to me that's just three examples of user stories for a login page so really your page or your feature login has multiple stories to explain how you want the user experience to happen the user story should explain the entire story of the user experience again I we have a user a registered user an anonymous user a user is logging into our system doing something and I'm expecting some kind of output so you can kind of fill in the blanks think of a spreadsheet you could just kind of run through a whole bunch of different scenarios if you think from a data perspective just sort a spreadsheet up what are are all the possible combinations that could break the application just based on those two Fields if you start with that if if stories are hard for you start with that start with this simple okay I have a a username I have a password pass or fail if I enter in a valid username valid password pass valid username invalid password fail but am I returning a message you know should I return a log uh password invalid entering another one invalid username valid password but that doesn't matter because username is invalid you return back unknown username again you enter in a valid username no password oops password required so you just kind of run through the different scenarios and then you can write the stories from that I am a given you know I am a registered user using this information to Lo l in what is the expected out this can be applied to anything it can be applied to mobile apps it can be applied to backend Services now it's funny though Rob that you mentioned that this is only user uh user stor requires users but there are applications that are headless where there is no user uh interaction you know like backend Services you know um cron jobs things that run on schedules those still can have user stories you don't necessarily have a user but the job is your user or the service is your user so user stories can apply to multiple things but it's essentially the same logic think spreadsheet think data put in what your input is what your output should be and what the final result should be so if I have input and action what is the exception what is the expect outcome from there you should almost always be able to write your stories now if you say I have a I have B but I could get this I could get this I could get this that's not a user story that is a Choose Your Own Adventure story that needs to be refined down further into the individual stories so if and this is another thing if you have requirements that you question or you have assumptions like we've mentioned before that is a choose your own path that's those psychopath you don't want that you want to nail it back to what is it that I'm trying to do what is the expected outcome and what is basically I have a I have B what is C keep it simple as you know me and Rober running across this for years doing user stories you can go down rabbit holes that is okay but keep it simple stupid and also even though you're keeping it simple it's okay to go down those rabbit holes but make sure the rabbit holes follow the 8020 principle are you getting 80% of the user functionality up front so that you're getting those STS out quickly you're covering most of the functionality that the users are going to get and then you have that 20% of those outliers that you can address in the next iteration so those could be those Psychopaths those could be the crazy path to try to get to again like those SQL injections but these are things not to be ignored because these are still could be potential security flaws in your system that you don't want to overlook within your user stories well you stole my thunder because there was a couple things I was going to say was like what are the common uh this is a problem we don't talk about this beforehand actually it's not a problem for him he stole it I'm just the I'm the one that was stolen from one it was like some of the common uh mistakes or misconceptions that we run into one of them that he mentioned is that user stories require a physical user that's why I mentioned initially there's and a lot of people change it to like an actor or something like that or a participant or something but even even then people forget that there are things like backend services that may be a user story that doesn't have a user but the user is the system the system is the user in that case and that hens happens a lot when you're talking about like uh automated systems and things like that where there's maybe some data integration or there's nighttime process like your nighttime processes all of those are going to be user stories could be user stories where it's there's no actual person necessarily it's but is to some extent it's maybe like there is a um there's an account that gets logged into things of that nature the other thing is user stories fall into one of those categories I find along the lines of data modeling and object raring design and normalization and things like that where it's like there are different ways you can do it you can have very you can have a big all-inclusive Choose Your Own Adventure story and you can have something you can have thousands of stories that are all of the possible paths that you can go through and it becomes like it is often it is that challenge of are you going to build something using bricks or are you going to build it starting with sand and there is really not an answer that is always going to apply now with user stories as I think you may have picked up as Michael was going through it you're better off to air on the side of too many because what will happen is if you have a if you really break it down to every possible thing you will find user stories that are essentially The Identical story there's going to be pths that are basically the same stuff and what you can do is you can always come back and go oh these see things are basically the same so that will just be one user story and then we can do our testing we can do the pieces we need to to deal with that just like if you build an object-oriented system and you start from like really lowlevel stuff you're going to be able to roll it up and say oh this is a class this is a subass and blah blah blah user stories are the same way and it comes down to if you look at a user story and you're walking through it and it has a path that now changes the steps so like you're CH you know you have five steps one two 3 4 5 and if you go one two three and sometimes it goes to 3A something else now you have a different user story now it may be that you're going to just refer to it and say if we get to this point we stop go see story ABC or you know one two three or whatever you call it and that's where as I talked about before that you will have these sometimes you will see your relations within the stories because you do have like families of stories or you will have stories that only start at a certain point it would be things like a login the login story is assumed if you're in a web application a lot of times the login story is assumed to have succeeded because you're logged in and you got to see the menu and you got to choose that menu item but those kinds of things still need to have their own stories you don't want to just write like oh somebody was you know somebody logged in because as we've seen and shown many many times login is not just that's it it's not that simp it's not like a onepoint thing there's a lot of logic inside that little black box so those are the thoughts I had I wanted to S throw some things out on user stories as you're depending on where you're at those are things that are sort of like check your yourself a little bit as you're going into building user stories now the final thought I have on this for I'm going to toss it back and get your my final thought is the usefulness of user stories now sometimes people are going to sit down and say you know what all I need is requirements I just need to like you know I can put I'll just I'll create screens here's the buttons here's the data boom you know here's a here's the alerts that come up and and I'm done that does not help I mean it's it it is useful but it does not replace user Stories the thing that user stories give you is something that you can walk through and test and verify that is not unit level user stories are where you start understanding your system and being able to do system testing as opposed to I have this you know I'm at this one step and here's my inputs and here's my outputs and I can verify them this is where with user stories is where you get to start figuring out what does this look like in the real world or at least mapping what you're building to the real world because now it's not just I built this screen this screen is part of this user story so I need to make sure that it fits the story it's just like if you get a a a movie and you put an actor in the movie that totally sucks at the role that is not built for that and if you put PeeWee Herman this is like aging me I guess you put PeeWee Herman in as a action star then you know it's going to throw it off it's those are C there's certain people that you there are certain actors that work in certain things same thing there are certain screens and pieces that you have that they need to you need to have that story to understand whether it fits or not uh closing thoughts from you so the only additional to everything we've discussed so far is be careful when you're writing the user stories or when you're in the requirements Gathering phase not to think that oh that's implementation or oh I'm jumping ahead sometimes if you're getting to that you might have uncovered another story or another requirement that may go to a particular require or feature or implementation whatever but it may feel like an implementation or you know framework modeling whatever but if you're thinking about that unpack it find out why you went that path and if you did did chances are You' just discovered another story that should be written in a way that can help you understand oh if I'm doing this oh I may need an MVC framework or oh I may need a relational database your stories can sometimes lead to framework or lead to implementation but usually if you're starting to think implementation you may have gone too far but unpa that walk back a little bit and say wait if I'm thinking this is that because the story triggered that or did that trigger because I thought maybe there's something else to this story that sent me down that rabbit hole so sometimes rabbit holes uncover other stories so don't always ignore them but do check yourself and make sure you don't get too far into building the application before you have the requirements and one thing is that we've mentioned before is that it's it's very useful you can tell somebody to have somebody tell you about something or you can say show me that is one of the biggest values as as he alluded to there one of the biggest values of the user story is that then you can basically read that story back and now you have somebody thinking through that actions and then you can have these all those little things that you know maybe you're like oh okay this is a story and they'll be like well wait a minute there's this other point and next thing you know you may have another story or you may have some sort of missed requirement things like that for example a requirement to all of you is to sooner or later shoot usn't an email at info develop and.com because that's just who we are we are demanding like that we have poured all of this time we haven't asked for a dime from you I want to hear it from you like I would love to get emails from all you guys so that we can and particularly not just hey this is my email what up dude or something like that but give us some of that say what are your thoughts where where would you like us to go what are topics you would like us to cover what are some of the things that are challenging you in your developer Journey or this is one of those things we're coming up to is like things we could have in a future season I almost let slip but I forgot we haven't let that slip here what the next season is going to be but if you keep if you check us in all the different places there are Easter eggs that are actually not even Easter eggs it's just blatantly us saying hey here's what's going on that being said I'm gonna wrap this one up because obviously we've gone a little too far getting a little slap happy as always go out there and have yourself a great day a great week and we will talk to you next time and that little bonus thing that little Easter egg is yeah we're going to talk about the things that we can do to be a better developer and that's one of the things I would love to get from you guys that's like the bonus material this time is contribute to this there are a lot of little things that we can do there's a lot of things that we do to help us be better developers I almost all of us every developer I know Works beyond their you know their day job whether they're their specific uh side hustle things they do or Hobby Habit hobbies and habits that they have to you read technical books or listen to podcasts or do all there's so many things out there that we could spend another 800 episodes just going through those things very similar to like the getting things done podcast where he has just sometime he's got the big ones but he's got just like the little hits after hit after hit after hit we could do the same thing so we would love to hear from you guys because I'm sure there's a ton of stuff out there that we haven't thought of I will let you sort of wrap that up and then we'll we'll wrap this one up because obviously I'm getting a little slap happy I'm ready to go grab some food chill for the end of the day thoughts so the only bonus I'll throw out this time is if you are new to user stories if you are not familiar with writing requirements literally start with things like Vio draw I diagram. any type of flowcharting application and literally start with an actor or start with I have someone that wants to do this what is they want and then walk through the diagram to get to the end how do you get from A to B sometimes just doing that triggers a whole slew of ideas and requirements that you never thought all right so I'm going to retract your air quotes for your bonus because that was actually an actual bonus kind of thing that was that was not a bonus that was a bonus so uh because that is that's very key it's like just if you struggle with it find any kind of tool that is a way for you to capture thoughts as you go through this because those kinds of things often will lead to those gaps they will point you to the gaps as soon as you put it in a way a format whatever it is that works for you that you can visualize it that is where it helps and then if you can take that and make that something you can give to your customers your clients whoever's the decision makers so they can visualize it that's going to help them as well you as I already alluded to can give us something we can visualize by you know leaving us a comment leave us some feedback send us a form uh use a contact form out on develop andure uh check out school. develop or.com we've got some classes out there we're trying to figure out what we're going to do in the in the near future with some of that so there may be some new stuff or it may just go disappear if we decide to go a different path so you should grabb it while it's out there that being said I'm gonna grab the rest of the day while it's out there you go do the same have a great one and we will talk to you next time [Music]
Transcript Segments
[Music]
and we're back sort of uh so next
episode let's talk about what our topic
is going to be I had a really good one
as we were going through the prior
one I want to where was I going with
this it had to do with requirements and
Gathering those I believe oh I don't
think we've talked about user stories I
want to get into a little bit like what
makes a good user story I think we've
referred to them dozens if not hundreds
if not thousands of times but I don't
know that we've ever actually talked
about user story specifically so I was
thinking this is one we can sort of you
not really go too much into like the
because there's a template out in the
book and we can I'll reference that
because we're Shameless like that but um
I think sort of walking through some the
things like how do you what is a story
what is a user story because people talk
about it all the time and it is one of
those things that it's like that's the
fun thing about working with newer
developers is sometimes you'll they'll
ask questions like what the heck is a
user story you've mentioned it a lot of
times like everybody knows what it is
and I don't and I'm like you know what
that's not a bad idea because I have
also seen a bunch of different ones so I
think I have a feeling whatever I lay
out you'll have some modifications to it
because you've seen you know had
different experience you've seen
different user stories as well how about
that for a topic yeah I like that one
and then for the one after this I think
I have a great idea so if we do user
stories now let's maybe do prototyping
maybe mockups like because I don't think
we've talked about that either and from
the previous one that made me think
about that one as well so I like yours
as a good followup but maybe the
followup to this one would be that one
so put that in the yeah put that in the
slack notes there and we'll uh in the
podcast ideas and we will knock that one
out next time around uh because that's a
good one I like that too it's sort of
like what is that that and clickable
demo is uh very near and dear to my
heart
while you're doing that I'll kick us off
well hello and welcome back we are
building better developers we are the
developer or podcast we are talking this
time our topic like I'm going to write
I'm going to spoiler alert topic this
time around is we're going to talk about
user stories we're not about telling
stories about the around the campfire
we're talking about user stories in a
technical sense which I think a lot of
people have an idea that like oh yeah
user stories but if you try to nail them
down down then it's going to take them a
minute to figure out like what actually
is a user
story but before we do that my user
story I'm Rob Broadhead I am one of the
founders of develop andur building
better developers I'm also a founder of
RB Consulting where we help you leverage
your technology and all of your
investments in that wherever we can
usually through simplification
Automation and integration and finding
the various ways for you to take that
big nasty bowl of spaghetti and turn it
into something very nice and easy to use
good thing bad thing I say good thing
that has happened in the last week um
these are always it's sort of fun when
you get to a point where you've got your
own company and you're you know or side
gig or or Consulting and stuff like that
and when you just get sort of a call out
of the blue where what especially when
it starts with like this one was awesome
it started with do you know X and that's
not Twitter I'm just going to say just
not to go into it but it's like do you
know this thing and I'm like yes that
was literally my I was like because I
couldn't add any more to it get an email
do you know this particularly with this
platform
yes okay 10 minutes later I get this
thing hey can you jump on a call in a
little bit turned out to be an hourong
call turned out to be something that
suddenly I'm like the the expert in the
room and I was because basically I was
like okay I've done this before
apparently nobody else had but it turned
into like a little mini gig it'll
probably be you know it's a couple hours
here or there but it's still those are
always good things bad thing bad thing
bad thing bad thing bad thing uh oh bad
thing this actually goes a little bit
into our psychopath thing that we talked
about last time
around I had this really cool I had this
system that we built initially it was
very simple it was not that comp you
know it's not very complicated it's like
it's run it all in one server it's great
we found out as we got into it that you
really want to distribute it it was
built it really needs to be a
distributed system of some sorts I'm
like cool I'm going to do this so I
might go crank it restructure
everything and basically try to put all
of the distributed Parts on one machine
because it's just like hey it's really
it shouldn't be that much more we're
just breaking apart and then later we
can offload this stuff so we can scale
from one server to a billion servers if
we need to and so I I go in and I crank
these things up and it's you know there
is a little bit of extra overhead
because I was using like celery for the
task manager and stuff like that and so
it's like
all right we're you we get the beat
going and it's starting to crank through
this stuff I had to go to it was an
Amazon server I had to go to AWS and
shut the server down to be able to do
something with it and it took a while to
shut it down it locked itself up so bad
and it was one of those that it worked
great when I was on my like you know
eight processor work machine that's got
like 64 gig of RAM or something but when
you go down that little
ec2 tiny instance or whatever it wasn't
that tiny but it was not that but it was
like two processor a gig of RAM I could
hear it screaming from here I mean it
was just one of those it's like not a
good thing so sometimes you want like
luckily it wasn't like production or
anything like that but it is one of
those where you're like sometimes you
want to like inch yourself into it
instead of just like okay I'm gonna fire
it all off and then next thing you know
you have brought that thing to the
ground to such level that you cannot get
back on your server so that's probably
not a good thing and I took too long but
I'm going to go ahead anyways and you on
to Michael let him introduce yourself
himself and see where he can can he can
he top
that want I catch my bre that was funny
sorry hey everyone my name is Michael M
I'm one of the co-founders of developer
also the founder of Envision QA if
you're looking to transform your
business with customer software
Solutions hey we're here to help we
offer tailored software and quality
solutions to optimize the and
performance reliability of your
e-commerce platform pitcher flawless
user experience increased sales and a
comprehensive Edge in the market good
and bad uh good making great progress
with a lot of the customers I'm working
with right now things are moving
smoothly even though we've had a few
hiccups for that listen last episode uh
bad
um it's
fall allergy season is upon us and it's
going to be hay fever heck till we get
cold so that's my
bad yeah just as a quick side note to
that we were to place we won't name it
we'll just it it rhymes with uh I don't
know brick kill K and um we were sitting
there and it was me and my son we both
have allergy
issues and daughter and wife were there
and we're we're eating and we had a
sneeze Fest it was like I sneeze he
sneeze I sneeze he sneeze I sne there's
like eight or nine in a row each of us
it was just it was almost like
volleyball was sneezes it was just I had
a whole pile of like of of napkins and
by the time we're done we're like let's
just blow our noses and go get a whole
other pile of
napkins all right back to user stories
now user stories I think a lot of people
sort of get sometimes they over
complicate them sometimes they're like
trying to figure out too much how to do
it uh we'll call it like the correct way
and I'm using air quotes if you're on
listening to the podcast but the like
the correct way where it's like this is
the way that I was taught by you know a
Six Sigma Black Belt or whatever the
heck it is or something like that I
think about user stories they are really
just a more detailed a better way I
think and I think a lot of people
probably would agree to convey how
something works than a
flowchart because at the end of the day
it is more or less like a flowchart when
you think of like particularly when you
think of like you've got swim lanes and
and the decision boxes and stuff like
that
thing about a user story is it instead
of it being those little points of the
boxes that are your the items in your
chart the objects in your chart and then
little flows it is now it is a story it
is something that flows as a discussion
of it now some key the thing about user
stories in general is there are some
data items that you need to make from
properties you need to have for your
story for it to be useful and for it to
make sense now there's going to be other
stuff that you will see because there
may be things like you people have like
IDs or specific names or codes or short
names or things like that that are
basically a way to uh to either
categorize them or sometimes to link
them but effective user stories can link
to each other anyways you shouldn't
really have to do that those are really
more like convenience functions in
building out your user
stories now that the thing you want to
have is a title to your story of some
sort a name or something like that and
it's just a way this is really just a
way to organize your stories and to
share with other people without going
through the whole story so the user
login story you say that and now people
like okay that's a user I know what
you're talking about even if they
haven't read it they at least know that
they can if they need to know the
details now in any user story you have
an actor or actors and you can call them
this is like gives it away a little bit
you need a user or users to have a user
story and this is actually key
because sometimes we we struggle with
what the actor is and talking about the
actor so a lot of times before you get
into building user stories for your your
system you also need to spend some time
thinking about who are the actors who
are the users and a lot of times those
questions are what are the roles or
profiles or permissions things like that
and sometimes it's very easy because
it's like you have a a super user a
regular user and a readon user or
something like that but often it gets
much more complicated very quickly and
you want to make sure when you're going
through doing the user stories that it
is a specific user that you're talking
about now it may be that you can take
that same story and say well this story
works for all of the users because maybe
it's something like login it's any user
but is it really because you may have a
user that is logged in that is
registered and a different user that is
unregistered and now it's a different
story because you have to figure out how
did they how do they get registered to
get to the
login different from a path now with the
story you're usually going to have some
a story is g to have progression so it
is going to have steps however you refer
to them whether it is uh key items or
whether it is steps and usually it does
have some sort of flow it does have sort
of a you're going from point A to point
B as part of the story so you at least
have a a starting point and an end point
now those steps can be between them but
a lot of times those are key is the
starting point and the end point are
also going to give you assumptions which
you're actually going to have all
through it so in your starting point
this is a starting point and there are
going to be assumptions or maybe
requirements based on how do I get to
this point how do I get to the starting
point so it is uh you know simp
questions that often be like am I log in
uh have I already done certain other
things for example
let's take an ATM kind of thing would
you're just going to an you're doing a
user story to get money out of an ATM
machine well part of that story you know
just sort of cutting around moving
around it part of that story is entering
your uh your pen number your pen for
your card most likely or retina scan or
however it is that you authenticate
yourself to your card well somewhere in
there there's an assumption that you've
put the card into the reader or
something along those lines so depending
on where your story begins that's where
you that's how you set the stage for the
story is what are my requirements and
maybe what are my inputs or what are my
assumptions on the back end of that it
is okay what is the output what state
has changed uh what things now need to
persist potentially and what things get
to go away now those can be part of the
steps within the story but that's really
where you get
into details around each of those steps
and a lot of times there there's many
things I've seen them called extensions
sometimes they're called exceptions
sometimes it's just addenda or
additional information because it's
things like the story is a b c d this is
where we go and then we go to B we go to
C we go to D the exceptions extensions
or whatever you are those additional
notes are at each step here are some
some some assumptions or here are some
validations or here are some
verifications or here are notifications
so all of those
things that could happen and there's all
sorts of little families of them really
can be applied to each single step now
they may may not matter for each it may
be a very simple step and there's not a
lot that matters but then there going to
be some where it all matters so when
you're plotting out your story this is
much like again going back to the whole
psychopath thing is you have your your
user story is your happy path but within
that user's story you do need to Branch
out to the other path if you're old
enough or have stumbled across a thing
called Choose Your Own Adventure books
that used to exist years and years ago
it is very much like that because what
they would do is you would start on page
one and then you it was just decision
trees and so whatever your decision is
would take you a different page now it
could be a 100 pages in that book any
given path was not going to hit all 100
pages I mean I don't think there was any
possible way to do it but you would have
all these different paths and that's
still your your user story but within
that you need to have all of the
Alternatives that here all of your other
Adventures that you choose along the way
to the user story I pause there because
I I kept a little high level I did get
into some details but I want to I want
to throw this out to you and see where
you can start fleshing some of that out
and add your own flavor to the story as
well yeah so as you're thinking about
user stories from a tester's perspective
we think about user stories more is a
blackbox testing you have information in
information out so your story is going
to talk about what it is that you're
going to be doing and what output you
should have you really don't get into
the inner workings that's more the white
box gray box
testing with user stories like Rob
mentioned and we've talked about login
is it's you have a story you have a
beginning and an end but you have all
these other Pathways or conditions that
could potentially happen a story should
be a One andone requirement there should
be
one story One path that you can go if
you have branching pass you have other
stories for instance user wants to uh
let me back up so we have a login page
we have user validation so one user
story is a valid registered
user can log into the system with a
valid username
and a valid
password click login they're logged into
the
system another use case or user story is
I am an a unregistered user trying to
log into the system with some username
some password I should not be allowed to
log into the system and then you have
the other situation again I am a
registered user I'm logging in with my
user name but whoops I entered in the
wrong password I should get you know
invalid password or some message
returned back to me that's just three
examples of user stories for a login
page so really your page or your feature
login has multiple stories to
explain how you want the user experience
to happen the user story should explain
the entire story of the user
experience again I we have a user a
registered user an anonymous user a user
is logging into our system doing
something and I'm expecting some kind of
output so you can kind of fill in the
blanks think of a spreadsheet you could
just kind of run through a whole bunch
of different
scenarios if you think from a data
perspective just sort a spreadsheet up
what are are all the possible
combinations that could break the
application just based on those two
Fields if you start with that if if
stories are hard for you start with that
start with this simple okay I have a a
username I have a password pass or fail
if I enter in a valid username valid
password pass valid username invalid
password fail but am I returning a
message you know should I return a log
uh password
invalid entering another one invalid
username valid password but that doesn't
matter because username is invalid you
return back unknown
username again you enter in a valid
username no password oops password
required so you just kind of run through
the different scenarios and then you can
write the stories from that I am a given
you know I am a registered user using
this information to Lo l in what is the
expected out this can be applied to
anything it can be applied to mobile
apps it can be applied to backend
Services now it's funny though Rob that
you mentioned that this is only user uh
user stor requires users but there are
applications that are headless where
there is no user uh interaction you know
like backend Services you know um cron
jobs things that run on schedules those
still
can have user stories you don't
necessarily have a user but the job is
your user or the service is your user so
user stories can apply to multiple
things but it's essentially the same
logic think spreadsheet think data put
in what your input is what your output
should be and what the final result
should be so if I have input and action
what is the exception what is the expect
outcome from there you should almost
always be able to write your stories now
if you say I have a I have B but I could
get this I could get this I could get
this that's not a user story that is a
Choose Your Own Adventure story that
needs to be refined down further into
the individual stories so if and this is
another thing if you have
requirements that you question or you
have assumptions like we've mentioned
before that is a choose your own path
that's those psychopath you don't want
that you want to nail it back
to what is it that I'm trying to do what
is the expected outcome and what is
basically I have a I have B what is
C keep it
simple as you know me and Rober running
across this for years doing user stories
you can go down rabbit holes that is
okay but keep it
simple
stupid and
also even though you're keeping it
simple it's okay to go down those rabbit
holes but make sure the rabbit holes
follow the 8020 principle are you
getting 80% of the user functionality up
front so that you're getting those STS
out quickly you're covering most of the
functionality that the users are going
to get and then you have that 20% of
those outliers that you can address in
the next iteration so those could be
those Psychopaths those could be the
crazy path to try to get to again like
those SQL injections but these are
things not to be ignored because these
are still could be potential security
flaws in your system that you don't want
to overlook within your user
stories well you stole my thunder
because there was a couple things I was
going to say was like what are the
common uh this is a problem we don't
talk about this beforehand actually it's
not a problem for him he stole it I'm
just the I'm the one that was stolen
from one it was like some of the common
uh mistakes or misconceptions that we
run into one of them that he mentioned
is that user stories require a physical
user that's why I mentioned initially
there's and a lot of people change it to
like an actor or something like that or
a participant or something but even even
then people forget that there are things
like backend services that may be a user
story that doesn't have a user but the
user is the system the system is the
user in that case and that hens happens
a lot when you're talking about like uh
automated systems and things like that
where there's maybe some data
integration or there's nighttime process
like your nighttime processes all of
those are going to be user stories could
be user stories where it's there's no
actual person necessarily it's but is to
some extent it's maybe like there is a
um there's an account that gets logged
into things of that nature the other
thing is user stories fall into one of
those categories I find along the lines
of data modeling and object raring
design and normalization and things like
that where it's like there are different
ways you can do it you can have very you
can have a big all-inclusive Choose Your
Own Adventure story and you can have
something you can have thousands of
stories that are all of the possible
paths that you can go through and it
becomes like it is often it is that
challenge of are you going to build
something using bricks or are you going
to build it starting with
sand and there is really not an answer
that is always going to apply now with
user stories as I think you may have
picked up as Michael was going through
it you're better off to air on the side
of too
many because what will happen is if you
have a if you really break it down to
every possible thing you will find user
stories that are essentially The
Identical story there's going to be pths
that are basically the same stuff and
what you can do is you can always come
back and go oh these see things are
basically the same so that will just be
one user story and then we can do our
testing we can do the pieces we need to
to deal with that just like if you build
an object-oriented system and you start
from like really lowlevel stuff you're
going to be able to roll it up and say
oh this is a class this is a subass and
blah blah blah user stories are the same
way and it comes down to if you look at
a user
story and you're walking through it and
it has a path that now changes the steps
so like you're CH you know you have five
steps one two 3 4 5 and if you go one
two three and sometimes it goes to
3A something else now you have a
different user story now it may be that
you're going to just refer to it and say
if we get to this point we stop
go see story ABC or you know one two
three or whatever you call it and that's
where as I talked about before that you
will have these sometimes you will see
your relations within the stories
because you do have like families of
stories or you will have stories that
only start at a certain point it would
be things like a login the login story
is assumed if you're in a web
application a lot of times the login
story is assumed to have succeeded
because you're logged in and you got to
see the menu and you got to choose that
menu item but those kinds of things
still need to have their own stories you
don't want to just write like oh
somebody was you know somebody logged in
because as we've seen and shown many
many times login is not just that's it
it's not that simp it's not like a
onepoint thing there's a lot of logic
inside that little black box so those
are the thoughts I had I wanted to S
throw some things out on user stories as
you're depending on where you're at
those are things that are sort of like
check your yourself a little bit as
you're going into building user stories
now the final thought I have on this for
I'm going to toss it back and get your
my final thought
is the usefulness of user stories now
sometimes people are going to sit down
and say you know what all I need is
requirements I just need to like you
know I can put I'll just I'll create
screens here's the buttons here's the
data boom you know here's a here's the
alerts that come up and and I'm
done that does not help I mean it's it
it is useful but it does not replace
user Stories the thing that user stories
give you is something that you can walk
through and test and verify that is not
unit level user stories are where you
start understanding your system and
being able to do system testing as
opposed to I have this you know I'm at
this one step and here's my inputs and
here's my outputs and I can verify them
this is where with user stories is where
you get to start figuring out what does
this look like in the real world or at
least mapping what you're building to
the real world because now it's not just
I built this screen this screen is part
of this user story so I need to make
sure that it fits the story it's just
like if you get a a a movie and you put
an actor in the movie that totally sucks
at the role that is not built for that
and if you put PeeWee Herman this is
like aging me I guess you put PeeWee
Herman in as a action star then you know
it's going to throw it off it's those
are C there's certain people that you
there are certain actors that work in
certain things same thing there are
certain screens and pieces that you have
that they need to you need to have that
story to understand whether it fits or
not uh closing thoughts from
you so the only additional to everything
we've discussed so far is be careful
when you're writing the user stories or
when you're in the requirements
Gathering phase not to think that oh
that's implementation or oh I'm jumping
ahead sometimes if you're getting to
that you might have uncovered another
story or another requirement that may go
to a particular require or feature or
implementation whatever
but it may feel like an
implementation or you know framework
modeling whatever but if you're thinking
about that unpack it find out why you
went that path and if you did did
chances are You' just discovered another
story that should be written in a way
that can help you understand oh if I'm
doing this oh I may need an MVC
framework or oh I may need a relational
database your stories can sometimes lead
to framework or lead to implementation
but usually if you're starting to think
implementation you may have gone too far
but unpa that walk back a little bit and
say wait if I'm thinking this is that
because the story triggered that or did
that trigger because I thought maybe
there's something else to this story
that sent me down that rabbit hole so
sometimes rabbit holes uncover other
stories so don't always ignore them but
do check yourself and make sure you
don't get too far into building the
application before you have the
requirements and one thing is that we've
mentioned before is that it's it's very
useful you can tell somebody to have
somebody tell you about something or you
can say show me that is one of the
biggest values as as he alluded to there
one of the biggest values of the user
story is that then you can basically
read that story back and now you have
somebody thinking through that actions
and then you can have these all those
little things that you know maybe you're
like oh okay this is a story and they'll
be like well wait a minute there's this
other point and next thing you know you
may have another story or you may have
some sort of missed requirement things
like that for example a requirement to
all of you is to sooner or later shoot
usn't an email at info develop and.com
because that's just who we are we are
demanding like that we have poured all
of this time we haven't asked for a dime
from you I want to hear it from you like
I would love to get emails from all you
guys so that we can and particularly not
just hey this is my email what up dude
or something like that but give us some
of that say what are your thoughts where
where would you like us to go what are
topics you would like us to cover what
are some of the things that are
challenging you in your developer
Journey or this is one of those things
we're coming up to is like things we
could have in a future season I almost
let slip but I forgot we haven't let
that slip here what the next season is
going to be but if you keep if you check
us in all the different places there are
Easter eggs that are actually not even
Easter eggs it's just blatantly us
saying hey here's what's going on that
being said I'm gonna wrap this one up
because obviously we've gone a little
too far getting a little slap happy as
always go out there and have yourself a
great day a great week and we will talk
to you next time
and that little bonus thing that little
Easter egg is yeah we're going to talk
about the things that we can do to be a
better developer and that's one of the
things I would love to get from you guys
that's like the bonus material this time
is contribute to this there are a lot of
little things that we can do there's a
lot of things that we do to help us be
better developers I almost all of us
every developer I know Works beyond
their you know their day job whether
they're their specific uh side hustle
things they do or Hobby Habit hobbies
and habits that they have
to you read technical books or listen to
podcasts or do all there's so many
things out there that we could spend
another 800 episodes just going through
those things very similar to like the
getting things done podcast where he has
just sometime he's got the big ones but
he's got just like the little hits after
hit after hit after hit we could do the
same thing so we would love to hear from
you guys because I'm sure there's a ton
of stuff out there that we haven't
thought of I will let you sort of wrap
that up and then we'll we'll wrap this
one up because obviously I'm getting a
little slap happy I'm ready to go grab
some food chill for the end of the day
thoughts so the only bonus I'll throw
out this time is if you are new to user
stories if you are not familiar with
writing
requirements literally start with things
like Vio draw I diagram. any type of
flowcharting application and literally
start with an actor or start with I have
someone that wants to do this what is
they want and then walk through the
diagram to get to the end how do you get
from A to B sometimes just doing that
triggers a whole slew of ideas and
requirements that you never
thought all right so I'm going to
retract your air quotes for your bonus
because that was actually an actual
bonus kind of thing that was that was
not a bonus that was a bonus
so uh because that is that's very key
it's like just if you struggle with it
find any kind of tool that is a way for
you to capture thoughts as you go
through this because those kinds of
things often will lead to those gaps
they will point you to the gaps as soon
as you put it in a way a format whatever
it is that works for you that you can
visualize it that is where it helps and
then if you can take that and make that
something you can give to your customers
your clients whoever's the decision
makers so they can visualize it that's
going to help them as
well you as I already alluded to can
give us something we can visualize by
you know leaving us a comment leave us
some feedback send us a form uh use a
contact form out on develop andure uh
check out school. develop or.com we've
got some classes out there we're trying
to figure out what we're going to do in
the in the near future with some of that
so there may be some new stuff or it may
just go disappear if we decide to go a
different path so you should grabb it
while it's out there that being said I'm
gonna grab the rest of the day while
it's out there you go do the same have a
great one and we will talk to you next
time
[Music]