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 continuing our developer journey and we are going to story time today. We were going to talk about user stories. I'm hoping I've got something that I just came up with that's an analogy that sticks with you with user stories, but it also follows up well with our prior episode where we were talking about requirements, gathering those and user stories are a huge portion of that. Before we get into that, my user story is I am one of the founders of developer. It's not really a user story, but we're, hey, go with it. My name is Rob Brodhead. I happen to be one of the founders. I'm also founder of RB Consulting where we use simplification, integration and automation to take all of your code, all your systems, all that stuff that has grown into this big technology sprawl. And we bring it down into a nice little nutshell so that you can use it, maintain it and scale it. On the other side who needs no scaling is Michael. Go ahead and introduce yourself. Hey everyone. My name is Michael Mollage and my story is I'm one of the co-founders of developer and I'm the founder of Envision QA where we help small mid-sized companies and healthcare doctors and clinicians build software and automate their systems in a way that makes the job easier, gets the job done and improves patient care or customer performance. So user stories, this is an analogy I just came up with and so pardon me if it goes off the rails at one point, but I was thinking about this and I think this is a good layers of the onion approach to getting your user stories and to getting good requirements. Now user stories in general, the most general way to start if you've never done one is who are the users of the system? And then among those users it's what are they doing? How do they use the system? What is the story? So if it's a, let's say it's a system that's a back office system that the office manager uses on a daily basis. They're going to have multiple stories because they may go in there to enter a customer information, to look up a customer, to provide support, to go maybe to go enter bills that have come in, to enter payments that have come in, to look up somebody in the HR system because they need to call them. All of these are user stories that it is the path that you're going on to achieve a goal within that system. Now what we've talked before, there's this thing called the happy path, which is basically I'm going to go from point A to point B. I'm going to get on the system. I have this problem I want to solve or this task I want to complete and these are the steps to get it done. Here's my analogy. Let's think about that. That's your G rated movie right there. That is like everything goes right. That is the happy path. Everything's good. The data is correct. The data is clean. The data is consistent. The system works the way it's supposed to and the answer you get is exactly the answer you get. Now, ideally, most of the time that's what happens. I don't know if that's true. Just like in the movie world, there's not a lot of G rated movies. Your next step is your PG. There's a lot more of those. That's more common. This is where we've built the happy path. Now we've talked about that with our user and said, okay, well, if everything goes right, what does it look like? Now we start looking a little bit at it. We start picking at a little bit. It's like, well, okay, what if it may be things like what if this data is outside of a normal range or what if there is a typo? What if this phone number they put an A in there instead of numbers? Things like what are these things that can go wrong and then how do we handle them? Do we let the user know? Do we just push it through the system? What do we do? This is getting them thinking through as you're building the user story and as your customer you're working with them. What are the essentially sort of the exceptions or what are the messages? Some of this is even within the happy path because it's things like, okay, you get all the way to the end. Does anybody need to know it? Do you need to send an email? Do you need to pop a little you were successful message? Things like that. PG is where we go into that next step is we start picking at the happy path a little bit and we're adding to it and saying, okay, this is some everybody is on the same page and everything's awesome. Well, but now we're not. So let's do we have to notify people? Do we have some side effects and things like that? And then you start moving into now like the R rated stuff, which is where things are not good. And this is where people have like, for example, what happens if you're entering a person a user's name and you misspell the name? We don't know that you misspelled the name necessarily, but what happens there? Do you do validation checks if they're entering a city in a state in a zip code? What happens if they put the incorrect zip code? What if they put a try to put a three digit number in there for us? It's going to be at least a five digit zip code. What is it if they don't put a value in? Are there things that are required? Are there things that aren't required? Are there things that are in the requirements that must connect to other things? For example, if you have a zip code and you have a state and that zip code doesn't exist in that state, do we need to verify that? Do we need to stop that from moving forward? If you're doing like a bank account transaction, what happens if you try to withdraw money and they don't have funds in the account? What happens if somebody is going through and entering data and they just put, you know, a a a b b b b c c c? What is that? What if they enter an email address that you know is like a b dot com or something like that? This is where you're getting into the stuff where it's like, what about these situations where somebody is just inept or is trying to just like fly through the system and just get stuff slammed in as opposed to doing it the right way? Or maybe even intentionally, which is where we get into like the rated X stuff. They're intentionally trying to crash or screw with the system. So this is where you talk about like SQL injection and things like that. It's like what happens if somebody tries to shove something in here that's effectively that the system decides it's going to try to execute. So you can go from the happy path and sunshine and rainbows to rated X Jason versus Michael Myers thing and all those guys. I mean, it's like you can go into the horror movie side of it. When you're going through those, that's when you're going to get really full featured user stories. Yes, I did get back to my original point. That's where you get your really full featured user stories because you're peeling that onion off. You're saying, okay, this is good. And then what? What if this happens? What about this? What if this isn't right? And as you start picking out what every step is, what every data item is, as you're examining each of those and what can go wrong effectively, now you are fleshing out a true story. It's not just some little paragraph of this is what it is. Now you've got like full plot and character development in your user story. And that is where you're going to have super detailed, super valuable requirements. And now I'm going to take a breath and see what you thought about that one. Yeah, I really liked your approach to that. I would like to add a couple things to it, though. So I like how you kind of walk through the different analogies of movies and ratings with different stories and different levels of chaos that potentially comes from trying to define these stories. However, in addition to that, some of the things that come to my mind are so you have the story, you're writing these stories. But as developers, I've seen this more often than not. Instead of listening for the story, they start injecting code or methodologies into the stories, which don't need to be there. It's like the person needs an accounting software system or a payroll system. Cool. They don't care that it's written in C, Java. They don't care if there's a database behind it. They just want a payroll system, an accounting system. So stories don't necessarily translate to tech. The story is what we are saying. It is a story. This is what I want. This is the journey from point A to point B. You're going to have a beginning, a middle, and an end. How do I get there? Tell me about it. Tell me how the system is going to work. Tell me how you want this feature to be implemented. And you go through that process. You're going to have to, for lack of a better term, shut up, put on your hearing aids, crank them up, and listen to the customer. And from developers, when we're busy, that can be hard. We can fall into that crutch where, yeah, I heard you say that, but in reality, I didn't fully hear the story. I heard parts of the feature, and only parts of the feature get implemented. So you have to be very careful that the story that you are being told or the story that you are gathering, that you get the details of the story for the full feature. You may not get everything. So the other thing to think about, too, in addition to that, is there's different levels of stories. Not necessarily ratings, but levels. You have your feature complete story, which is what I need to just get a working system that complies with the basic of this story. OK? I need a payroll system. I want to get paid. So I need a system that will pay me. Cool. That is the baseline story. Now I start hiring people. Oops, my current system, that's a new feature, a new story to be added on to an existing application. All right? Now we have to add some additional requirements. OK, now I have multiple people whose, you know, do I have to worry about managing? What type of security constraints do I have? Who can see what? I don't want people seeing my payroll information. So these are stories that have to be flushed out. And then you get into bigger systems where you hand this off to, OK, so now I want to sell this system to someone else. Now there's other features. So you have at the beginning what you need, the basic story to build the application, the happy path. The must have features of your application. Then you have the nice to have features or new features that get implemented later. These stories are additions to the main story. These could be spinoffs. These could be, you know, book two, book three, book four, which would be version two, three and four of your software. They could essentially be integration pieces that just kind of tie in to your story. So there are different layers and different levels to story writing, listening to the stories, and then writing the applications or asking all those what if questions to define the story the right way. Rob, that's. That really adds to that. Yeah. My analogy was awesome because now I'm thinking about it as like that's one of the other things is are you building a documentary where you're just like Michael said, where it's just about the features or is this a summer blockbuster where you're not just building features, but you are putting a wow factor in it that's going to like draw people in regardless. I mean, there's the feature, but as well on top of the feature, because that's sometimes what you're going to get. It's not as people are saying, hey, I don't want just I don't want something where this is going to come and they're going to be able to select a product from my store. I want them to want to sit on my store and play around with selecting products because that's how awesome the environment is. There is also, as he said, there's like you think almost like there are levels and there are different, we'll even say genres of stories and user stories do the same way. And this is where you get into reading between the lines a little bit. And what as Michael mentioned is like really listening to the story as it is, not solving it while they're doing it, but letting them talk through that story because you're going to want to get that stuff like, wait a minute, you mentioned this feature. It seems like you need more than just that feature. Maybe you need to like, you know, it's maybe it's something that seems like you mentioned entering this data, this piece of data. But what if it sounds like it's hard to get that data? So do we need to also have as a feature a way to look that up or to validate that or something like that or a way to go jump and view that and shop? It would be like in a shopping cart. You can add products, but if you only know SKUs, your shopping experience is going to be very difficult. What you want is a catalog behind that, you know, shopping cart and things like that. And it's things like, okay, and the checkout process, how does that look? And there's there's so many things around the user stories that I think the more you realize they are stories and not just bullet point items necessarily, the more you're going to be able to ask the right questions. And this is where you can really help your customer take it to the next level, because instead of just regurgitating what they give you, you can help talk them through and think through some of these processes and say, okay, this is what you've got. This is where you want to go. How can we make adjustments to that journey? How can we make it easier? How can we make it faster? Is there maybe something that would mean we won't even need to take that journey? Because sometimes you do that as you get in the stories, you're like, wait a minute, that story we talked about last week is exactly the story we're talking about this week, except it's only a different user. So is that really just the same user story? And two people can access it. There's things like that. I don't want to run too long because I got places to go and things to do, even though you may think that's just virtually and we just live here all the time. We do have lives outside of the outside of this little box here that we're in or your your your ear holes. If you're listening to us, basically, we are not just, you know, mindless or face our body and we have endless voices out there, phantasms that are just talking. So anyway, as I digress more than a little bit, as always, reach out and just any information that you have feedback, suggestions, comments, love it all. We do this partially for us, partially for you, more so for you than us. So we'd love to do topics, questions in areas that are concerns for you as you are becoming better developers. For me, there's some ways that we can we can sit down and talk through some of the things that are stymieing you or just challenges or your own pain points or your own stories, user stories that we can help you with to work through and get you to that point where you are a better developer. And sometimes it just takes a couple of different people, a couple of different perspectives to get us over that hump. Shoot us an email at info at developer.com. Check us out at developer.com. Send us a get a contact form. We are out on Twitter slash well ex formerly Twitter at developer. You can check us out there. Follow us. You can see us wherever you get podcasts. We're there. You tube out on developer channel and there's other stuff around that. It's not just the podcast, but we also have a lot of other content tutorials, things of that nature. And then there's school.development.com. We're funny enough. We have tutorials and classes and things that you can learn as well. We're just trying to, we just spew all this content out there, trying to help you guys out and actually it helps us out as well. It's amazing how often we go to search something and we end up going back to our page to be like where we were with the steps to knock that out 10 years ago and we haven't had to use it since. Don't wait 10 years before you come back here though. Go out there and have yourself a great day, great week and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Noor Podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.