Transform Your Projects - The Ultimate Guide to Effective User Stories

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Well, hello and welcome back. We are Building Better Developers. We are the Developer Podcast. We are talking this time our topics. 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 going to be telling stories 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, 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 Brodhead. I am one of the founders of Develop-a-Noor, 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 would say good thing that has happened in the last week. These are, 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 consulting and stuff like that. And when you just get sort of a call out of the blue, where, 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. I get an email. Do you know this? Particularly with this platform. Yes. Okay. Ten minutes later, I get this thing. Hey, can you jump on a call in a little bit? Turned out to be an hour long call. Turned out to be something that suddenly I'm like the expert in the room. And I was because basically, I was like, okay, I've done this before. Apparently nobody else had. I'm going to turn 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. 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, you know, it's not very complicated. It's like, 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'm like, 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 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 know, 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. It'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 big. 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 to like, luckily it wasn't like production or anything like that, but it is one of those where you like, sometimes you want to like inch yourself into it instead of just like, okay, I'm going to fire it all off. And the 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 send you on to Michael, let him introduce himself and see where he can, can he, can he top that? I wanted to catch my breath. That was funny. Sorry. Hey everyone. My name is Michael Melosh. I'm one of the co-founders of developer. I'm 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 assurance solutions to optimize the and performance reliability of your e-commerce platform, pitch your flawless user experience, increase sales and a comprehensive edge in the market. Good and bad. 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. Bad. 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 bet. Yeah. Just as a quick side note to that, we were at a place, we won't name it. We'll just, it rhymes with, I don't know, brick kill hay. And 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 eating and we had a sneeze fest. It was like I sneeze, he sneeze, I sneeze, he sneeze. I see there's like eight or nine in a row. Each of us. It was just, it was almost like volleyball with sneezes. It was just, I had a whole pile of like, of napkins. And by the time we're done with 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 overcomplicate them. Sometimes they're like trying to figure out too much how to do it. People call it like the correct way. And I'm using air quotes if you're on it, listen to podcasts, 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 flow chart. Because at the end of the day, it is more or less like a flow chart. When you think of like, particularly when you think of like, you've got swim lanes and the decision boxes and stuff like that. Thing about a user story is that instead of it being those little points of the boxes that are the items in your chart, the objects in your chart, and then the 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 know, people have like IDs or specific names or codes or short names or things like that that are basically a way to, 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 of 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 are 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 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. Sometimes it's very easy because it's like you have a super user, a regular user and a read only user or something like that. But often it gets much more complicated very quickly. 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 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 going to have progression. So it is going to have steps, however you refer to them, whether it is 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 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 they're 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... You know, some questions that often be like, am I logged in? Have I already done certain other things? For example, let's take an ATM kind of thing, where 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, just sort of cutting around, moving around it, part of that story is entering your PIN number, your PIN for your card most likely, or retina scan or however it is that you authenticate yourself to your card. Now, 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 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? 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'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 we go to B to go C, we go to D. The exceptions, extensions, or wherever you are, those additional notes are at each step and you're like, here are 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 not matter for each, it may be a very simple step and there's not a lot that matters, but then they're going to be somewhere 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 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. So whatever your decision is would take you a different page. Now it could be a hundred pages in that book. Any given path was not going to hit all hundred 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 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'm going to 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 flushing 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 as a black box 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 of the white box, gray box testing. With user stories, like Rob mentioned, and we've talked about log in 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 and done requirement. There should be one story, one path that you can go. If you have branching paths, you have other stories. For instance, user wants to 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 user name and a valid password. Log in. They're logged into the system. Click login. They're logged into the system. Another use case or user story is I am an 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 username, but whoops, I entered in the wrong password. I should get 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, 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 can just kind of run through a whole bunch of different scenarios. If you think from a data perspective, just sort of spreadsheet up, what are all the possible combinations that could break the application just based on those two fields? If you start with that, if stories are hard for you, start with that. Start with a simple, okay, I have 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? Should I return a password invalid? Enter in another one, invalid username, valid password, but that doesn't matter because the 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 registered user using this information to log in what is the expected value. 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 stories that requires users, but there are applications that are headless where there is no user interaction. Backend services, 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 expected 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. 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 a 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 Rob have run 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 80-20 principle. Are you getting 80% of the user functionality up front so that you're getting those stories 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 paths 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, he stole my thunder because there's a couple things I was going to say that was like, what are the common, this is a problem. We don't talk about this before him. Actually, it's not a problem for him. He stole it. I'm just the one that was stolen from. I want to say, it's like some of the common mistakes or misconceptions that we run into. One of them that he brought 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 then people forget that there are things like back end 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 happens a lot when you're talking about like 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 there's no actual person necessarily. But it is to some extent, it's maybe like 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 oriented design and normalization and things like that, where there are different ways you can do it. You can have a big all-inclusive, choose your own adventure story. And you can have something that 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? 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 is going through it, you're better off to err on the side of too many. Because what will happen is 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 paths that are basically the same stuff. And what you can do is you can always come back and go, oh, these three 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 low level stuff, you're going to be able to roll it up and say, oh, this is a class. This is a subclass 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 you know, you have five steps, one, two, three, four, five. And if you go one, two, three, and sometimes it goes to three, a 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 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 so it's not like a one point thing. There's a lot of logic inside that little black box. So those are the thoughts I had. I wanted to 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 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 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. But, you know, here's the, here's the alerts that come up and I'm done. That does not help. I mean, it's, 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. So 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 movie and you put an actor in the movie that totally sucks at the role that is not built for that. If you put Pee Wee Herman in, this is like aging me, I guess, you put Pee Wee Herman in as an action star, then it's going to throw it off. It's those are certain. There's certain people that, you know, there are certain actors that work in certain things. Same thing. There are certain screens and pieces that you have that they need that you need to have that story to understand whether it fits or not. Closing thoughts from you. So the only addition 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 feature or implementation, whatever, but it may feel like an implementation or framework modeling, whatever. But if you're thinking about that, unpack it, find out why you went that path. And if you did, chances are you just discovered another story that should be written in a way that can help you understand what's going on. 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 unpack 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 the implementation? Or did the story trigger 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 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 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 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 us an email with info at developinware.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 something that's like, 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 that we're coming up to is like things that 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 this 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 going to 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.