How to Use User Stories in Software Development for Better Results

Welcome to Building Better Developers, the Developer Noir podcast, where we work on getting better step by step, professionally and personally. Let's get started. Hello and welcome back. We are continuing this season where we're talking about, we're building better developers. We are Developing Noir. We are going through a bunch of past topics, or basically suggestions on how to be a better developer. This time with AI, because we're going to go through these same things out, the titles, basically the topics out to AI, see what it says, see what it suggests, and talk our way through it. Now, I happen to be, before we get into all of this, I guess there should be some introductions all around. I happen to be Rob Brodhead, one of the founders of Developing Noir, also the founder of RB Consulting, where we are. Some people call it boutique consulting. What that means is, essentially, we actually care about you, our customer. We sit down with you and talk through your challenges, your travails, figure out what your business is, and we use our experience, multiple decades of working in a lot of technology, to help you sort of sift through your technology junk drawer, look at what's out there. Whether you're brand new and you have no idea where to get started, like, where do I go other than a spreadsheet? Or whether you've been doing this for a while and you've got this technology sprawl that has, you know, goes back to DOS or something like that, and you've got 15 different applications that none of them want to talk to each other, which is always one of the key things. You don't want to have all these things that are working here with your data if you have to keep entering your data. So check us out anytime, rb-sns.com, and we'll be happy to sit down and talk to you, just sort of, like, help you out. And if we can turn into a partner on the long term, great. If not, we can always send you to somebody that can help you out and move you forward because we want you to be better businesses as well. Now, good thing, bad thing. This is the mother of all good things, bad things right now. And which means I don't know what I'm going to do with the next episode because this one should, I should be able to reuse this every time for the next 10 weeks. I'm going to shorten this one because we don't have all day to talk through it. But essentially, my son was leaving town, moving, had a, had, we'll just say he had a shrapnel hit his car, causing a lot of damage. We have been back and forth a couple of times to help him out, to be a part of this, to work through all the insurance stuff, to get the car eventually totaled. Now we're working on buying him a new car. So lots of time in a car, driving back and forth, eight hour trips each way, basically. So it would be more fun. The good news is we've gotten to spend a lot of quality time with said child. So it's actually been pretty cool. Been able to like, it's been sort of an excuse to have some extra vacation time, some And we've gotten to really explore the place that he's at. So I don't think I'll name it, but I will just say it's a really cool city. Sometime in the future, we may drop that when we're not sitting here, basically. Not as cool as where I am because I'm here and he's there is Michael. Go ahead and introduce yourself. Hey everyone. My name is Michael Moulache. I'm one of the co-founders of developer NURB building better developers. I'm also the owner of Envision QA where we help startups and growing companies build better software. Faster with fewer problems. We also offer services that cover software development, quality assurance, test automation, and release support. Companies come to us when they want to avoid delays, reduce bugs, and launch with confidence. Whether you're building your first MVP or scaling a live product, we make sure your software is reliable, efficient, and ready for growth. You can learn more at EnvisionQA.com. Good thing, bad things. Well, I guess the bad thing is, like you said, it is hot here. We are under this heat dome and a combination of that yesterday, went out to dinner with the kids and we're sitting down at the restaurant after sitting through traffic and the power goes out like right after we order our drinks. Lose power. It is almost a city wide blackout. I mean, we're talking almost a 10 mile radius, no power. We leave, go over to the next restaurant. It takes another 20 minutes to get over there. The cars had time to get hot again. So we get over there, we're miserable, we eat, and it was just a miserable experience. I think I ended up getting heat exhaustion on top of all of it, which made for some fun times. Good thing though was our daughter, who we were having dinner with, had gotten some good news and we officially got the news today that she has been promoted to a new job with a huge salary bump and she is really looking forward to moving up to this position. We weren't sure when they moved to Jackson a while back, if she was going to find something she liked, she got into something and she's apparently able to move up and is loving it. So kudos. That's a good win there. So loving it. All right. Speaking of love it, we're back to a loving chat GPT. They absolutely loved our suggestion. So it comes back right away and it says, that is a strong title. What is that title? That was user stories unveiled, a developer's guide to capturing the full narrative. It says, and it opens the door to a lot of impactful real world discussion. Here's a suggestion, episode breakdown with topics and talking points to keep things focused, but valuable. It gives us six points again. Starts with episode structure, user stories unveiled. And I think that's basically, looks like that's our own sort of like overall piece. So let's dive into the first, the first segment, essentially why user stories matter. It gives me a couple of bullet points and some talking points. So bullet points, the difference between requirements and user stories. How good user stories for feature creep and rework stories is a bridge between developers, product and users. Talking points as a in brackets user. I want brackets feature so that bracket benefit. Why this format works, the narrative behind user behavior, not just functionality. I think I want to get, I'm going to do like start with that first one. So as a blank, I want blank so that blank, and then sort of switch to the difference between requirements and user stories. So really the user story, you can think of the story is the, as a blank, I want blank so that blank as a, you know, as a customer, I want to be able to view my order status so that I can track my order status so that I can see where it's at. Or so that I can maybe, and this is where you get to some stuff. So let's look at this one is it could be so that I could, I can cancel or reschedule my order in that simple story. There's actually multiple requirements. And this is where the user story is the, the user point of view, essentially. It's like this, it's really, it comes down to it. It's the why it's why do I want to do, what is it I'm doing and why do I want to do it? Which is sort of the, I mean, so as a blank that gives you who the actor is, I want blank, which is basically their why or their goal. And then within that is so that blank, because that sort of gives us the coloring. It's like, it may be, you know, I want my account balance. Well, I want my account balance so that I can withdraw money or deposit money. Those kinds of things are going to give you additional points that are going to become your requirements. So in like something as simple as that, if they want to be able to see their account, then that means you have a requirement of one, tracking an account balance of some sort for a person, you need to be able to display that in some way, form or fashion. And if they want to be able to withdraw or deposit, then that's two requirements right there. Then they have to be able to withdraw money, which means they're going to have to pull some out, put it wherever they're going to have to do it. Those requirements probably around that. And then within that, obviously, it's got to update their balance and vice versa. If they want to deposit, then there has to be a way for them to put money into the system for it to recognize what that money is, for that to apply it to their balance and fund things like that. And that doesn't even begin to get into other requirements, which is why we have some of these conversations, which is really where the user stories do start to come into play, because it's things where within the user story, you're going to find out that, oh, for example, I say it is an ATM. You deposit money into the ATM machine. The money doesn't actually get to the bank until the end of the day when they empty the ATM machine, probably, or something like that. Or if you're like one of my horror stories in the past, two weeks later, when they can finally get through the snow to the ATM machine to get the money out and verify. So you have all of these other side actors inside things that come up that really help you flush out the requirements. That is where the user stories become very valuable, because what you do is you get people talking about the process and it gives you an opportunity, gives you a straw man, essentially, to ask questions about the process. And therefore, you can start, like, you know, sort of sucking out some of the requirements. And as you get further into this and you've done it, there are going to be things that are always going to be questioned. So it's things like, you know, all right, if you have an account, how do you register account? How do you log into the account? How do you change your password if you can log into account? Or how do you update it? Or is it a multifactor authentication? Or or or there's a lot of questions that come in there. So I'm going to stop here. I'm going to throw all those questions at Michael and see where you want to go with this particular one. So I'm going to kind of take what you just laid out with user stories and all the examples, and I'm going to kind of take where we can go with this. So user stories like Rob mentioned, you know, you have the take money out of the ATM, put money in the bank. User stories are your requirements from the user perspective. Once you get those requirements or once we get these user stories to define what happens after the fact is as you flush them out, you get all the if then cases. And if you run into situations where you have an A or B, you know, you're going to situations where you have an A or B or anything where it's a. A vergence where you could potentially have multiple paths, you need to then find out, OK, if you're checking money out of the ATM, OK, you go try to take out twenty dollars. The first if is does the ATM have money? You know, is there money there to give you the 20 bucks? If not, it would throw an error. If it does, it would return your money. So those are types of user stories that help you define requirements. What's to me, the beauty of user stories. Is when we get to coding, this is where the whole test driven development comes in, because you take these user stories and you essentially literally these are your tests. You start testing from the user's perspective and then you build the code along the lines of the stories. For instance, if you need security for your application, you need a login page. So you're going to say, OK, user needs to log in. So you're going to then write, OK, I need a user. What is a user in my system? So you ask yourself the question to start breaking down the problem based on the user story to then write your code. And you essentially have the test. You write the test to test your code. The beauty of this is if you're using things like Cucumber, Tess and G, they they force you to define the user stories to write the test, especially Cucumber. Cucumber is very powerful in this nature where it uses business speak essentially to define the story. And then you write feature. It's to test your to test the story, to test your code based on the user's perspective. There are other test environments out there with different ways of doing this. But essentially, at the end of the day, that is the point of how you can use test driven development. So you need things like user stories. You need the scenarios on how the application is going to work. What is the why and how am I going to use the application to get there? How am I going to test it? I'm going to go right into the next one, because I think this is partially some thoughts I had, but you brought up some good points and some things I want to talk about on user stories. I don't think we've actually talked about the past, but let's step into theirs first. So their next section is what makes a good user story. And this is the fun part of doing this kind of research in AI. So it mentions the INVEST criteria, independent, negotiable, valuable, estimable, small, testable, breaking up epics versus slicing vertical features, avoiding technical stories that have no user value, talking points, examples of vague versus strong user stories where acceptance criteria adds clarity and testability. Now, first, I want to go back to that first statement. I love when I come across one of these acronyms that somebody's put together somewhere and it's like, oh, that's actually pretty useful. And sometimes I've heard of them and I actually have no idea what they meant because I've just heard them so many times and they just, you get the sense of it. And sometimes they're very like this. It's like, I don't know that I've heard this one before, but it's like, that's a pretty good, you know, series of rule of thumb kind of items. Now I do want to take this as a whole and talk about what makes a good user story. And it's, I actually want to step back a little bit and talking about what, you know, Michael's talking about it from a testing point of view. I think the thing that user stories give us is a way, it's a common language to actually talk to a business user. If you are somebody that can sit down and just talk business and not care about requirements, but just like talk through stuff, then you really are just a walking user story, essentially, as you can say, well, this person needs to do that. And this is how they do it. And they need to do this and this is their goal and things like that. But what user stories give us is they give us something that's a little more structured so as to make sure that when we're essentially, when we're interviewing a customer, when we're gathering requirements, that we have, we have like a goal in sight, it would be like building out, we can go, go through, you know, you're writing a book, let's say, and say it's, you know, a game of thrones or something like that, where there's all these characters and you can do all of this character development, all this different stuff without ever putting the story together. And that's okay. If you know how to bring all that stuff together, but that's what the user stories become. They are not only a way for us to keep focused on what is it, what are the problems we're actually solving, but also it's a little bit of the glue to take all of these things that we're building and to make sure that they do work together. That means that like the technical stories that have no user value literally or usually they, they really tend to bubble the top very quickly because they're not going to have an actor most likely, or the actor, maybe the system itself, in which case. If the actor is the system, now, if it's a backend process that kicks something out to a user, okay, then there is some actor in there. There's somebody, there's a receiver of that information, but there's a lot of times you're getting the stuff and Michael and I've had this conversations before, and I know that he's heard me say it where I'm like, it doesn't matter. Nobody ever sees it. Those kinds of things don't really care. It's like, those are implementation details. And as long as it works based on the why of the story, then that is what you need to worry about. The rest of the stuff is fluff. Basically it really doesn't matter. It's, it does get back down to, can you solve the problem and give them, you know, give the actor what it is that they expect. I went a little bit big and also went back a little bit. So now what are your thoughts on this one? Cause there's plenty of folks that could go with this. Yeah. I mean, there are many ways to go with this. The interesting thing though, you mentioned that, and we have talked about this, you know, where if it doesn't match the why, we don't need to worry about it. But there are times though, even when you get to the implementation, especially if you're trying to focus on test driven development, that you need to understand enough of the why to be able to break it down to the minutia, the stuff behind the scenes, you need to at least be able to explain how your systems work. So from a user stories perspective, you're at the customer level, you're doing the front end level. So getting into some of the other stuff is going deeper beyond user stories, but it is beneficial for testing. The other things to think about with this though, is, you know, kind of peeling back the onion is, especially when you're talking to the customers and talking about new features, we've run into this a lot where they want something, they explain it, they give us their why. And then three months into the project, they're like, well, we don't need that. And then you're like, well, crap, you know, how much time did we waste on this feature, even though it was laid out in the user stories, it ended up not being something that was really required. So one interesting thing to think about with your user stories is once you have them laid out, still go back and review them again and make sure that every story is truly a requirement or a need, not a want or a nice to have, because if you're fighting to get your MVP done first, always go with what is the, what, what is a must have, what do we need to have for this delivery? So those are the user stories you need to focus on first. Anything outside of that needs to be put in the nice to have or future enhancements, still make note of it, but don't spend so much time on that. Now focus on the MVP. That is, we've talked about that before, and I do think that is a critical thing to have is, especially when you're actually, honestly, if you're doing an MVP, but I think honestly, any software project, and I have been on some true Greenfield projects and that where there is, it is still incredibly valued to have a, we're not going to do that right now kind of section. It is always the future version 2.0, whatever the heck you want to call it. And it may be that it is something that you actually never are going to get to. Cause a lot of times that's people's worries. Like, well, if you put it there, then we're never going to get it done. Maybe, maybe it doesn't really, it may be. There's no need for it to ever be done. However, that may be that you're going to get to the point somewhere down the road. There'll be a version 2.0 and that is your, your backlog basically to build out your version 2.0 and sometimes like Michael said, I have been in situations where the customers had all these like, we have to do this and sometimes there's a sizable chunk of the implementation of technology and the solution. And then they realize, oh, we really don't need that and we can pivot and we can start pulling some of that stuff back in. So, so you want to have that placeholder. You want to have a bucket to throw those things. And it also gives you permission to throw something there to say, we're not going to tackle this now. We're going to deal with it at another point. So it doesn't keep sucking up your time and things of that nature. Now let's move along one more. Cause we're as always, we can only get through about three of their points because they are pretty good discussion points. Common pitfalls developers see bullet points. Just tell me what to build the anti-pattern getting handed half baked stories or solutions tickets, how to push back constructively talking points, questions devs can ask to uncover the real user need partnering with PMs, BAs, that's project managers and business analysts to improve story quality. Just tell me what to build anti-pattern. Um, this one, I'm going to tackle on this because I, this is part of why development or exists, there is a difference to me, and I think I've talked about this before, but there's there's been programmers or coders and developers, developers are solving problems. Coders are just writing code. And there's, if you don't think there's a difference, then you're probably in the wrong category. Um, and keep listening because you will learn and you would advance your career because coders are going to be risked or basically are already basically being replaced by AI developers are going to continue to basically, they're going to drive AI and they're going to drive things like that. So the, the, just tell me what to build. This is so many points. And if you're either side of that, so if you're a developer and you get to that point and you're like, just tell me what I need to build, then you've given up. You're not going to be successful. And if you are a customer and hear this, you need to give up because you're not going to get there because they're not building, they're just trying to regurgitate, regurgitate what you've said. So you said, you know, there is a difference between like the ATM person. So person needs to, you know, see their account balance, withdraw money and keep it very simple. Well, there's a lot more to it than that. So if you just give me something that says, I can see an account balance and I can click a button and it withdraws money that does not cover so many other things that are out there. And that is the thing is you need to have that inquisitive mind and you're going to get this from the other side of it. You're going to have customers that are like, I just go build it. It's like, we've had that example where people are saying, you know, I want you to build eBay, but for pet food and I need it done for $50 by next week. It's stuff like that. Where it's like, okay, you don't understand at all what you're asking or even what you're looking for. And you can just walk away and say, okay, you're not, you're not worthy of my time. Or you sit down with the customer and say, okay, let's talk about your vision. What does this really mean? And start really pushing back on some of that. So if they just say, well, just do this, that's when you have to walk them through and say, okay, well, let's say we do this, but then what about this situation? And what about that? And why are you doing this? Do you really need to do that? What if we do this instead? You don't have to wear them out with questions. You don't have to be the two-year-old saying, are we there yet? Are we there yet? Are we there yet? But what you do want to do is you want to make sure that there's a conversation. And it's even in that conversation, you're keeping that goal of the, why, what are we doing it? Why are we doing it? Who are we going to serve? And all of a sudden done. And if you can start from there, then that usually gives you at least those North stars to keep as part of your conversation as you go forward. Thoughts on that? Yeah. So that last part you said is kind of interesting. And I don't want to deviate too much from the user stories, but this is where those software assessments come in handy and you sit down with the customer and you walk through their current systems. You figure out how their business works, what their products do, what they want. And then you can sit down with them and flush out the user stories because you'll have a better understanding of what it is that their business is and understand that, okay, now these are the stories that you really need, or at least you can ask the right questions at that point. I love your comment though, there where, you know, just tell me what to build. There are times as developers, not just coders, but as developers where we reach a point where we are so frustrated with the lack of requirements or the lack of features or lack of user stories where we literally are tired of look, basically doing the PMs or the POs jobs and in larger organizations, this is a huge problem and developer burnout is notorious. However, in smaller companies, you have to understand that there may not be that level of project manager, project owner, business owner. So you will have to step up at times and step into those rules to get these user stories that you need to do the work, to make sure that the work you're doing is answering that why and is sufficient for getting the product across the line or a deliverable. You just have to be careful though, that you don't always jump to the conclusion of, well, just tell me what to build. Sometimes you have to, because sometimes if you get into situations, especially as a contractor and you're on a time budget, hourly budget for getting things done, and the customer is arguing with you or basically not giving you what you need, you either need to say, okay, then we need to put a pause on this till we flush this out. Or what can you get from the customer enough to get enough of the user story to keep the work moving forward? And that sometimes is the deal is you'd have to pull enough out of them to get that next step. Sometimes, because I know developers, because we whine a lot, we're prima donnas sometimes, is that we will mention, hey, we're burned out. We're having trouble because actually it's not that common. It's more common for us to work 100 hours and not be burned out than vice versa. At least that's the story we tell. But our customers will get burned out too. They will get to a point where they're like, I've answered this question too many times or too many ways or things like that. And so sometimes we've got to figure out how to either stop in the blow or help them through it and say, okay, we know this, here's our foundation. All we need is just this next step. All we need is like this little thing. It's like, what does this look like? And this is where clickable demos and things like that are very helpful. This is awesome. I hate to be self-serving, but this is where the, you know, the assessments, those kinds of things are very valuable because you get to start from here's where you are, here's what you've got, and here's some of the things that can help you. And it allows a, uh, an earlier ROI kind of vision at least, because maybe you're not going to be able to get that ROI immediately, but you're going to be able to see it. You're going to be able to see that, oh, we're spending, you know, somebody's spending five hours a day on these reports. Now we're going to automate it and it's going to take five hours to get it to take five minutes a day. And so now that person is freed up to go do other work, those kinds of things. Having that almost carrot and stick approach, I think will really help your conversations with your customers. Well, it'll also help as if you send us an email at info at development.com because we towards the end of yet another episode, we'd love to hear from you. What do you like? What don't you like? Where would you like this to go? We are not done with this season by any stretch. We've still got quite a few more. However, we had to have no problem throwing a couple of interviews in. I know I keep teasing that, but we're going to get there at some point. We just, uh, you know, we're just having too much fun doing this actually right now. And, uh, if you want to get it, reach out to us at developer.com. If you want to go to Facebook, we have a developer nor Facebook. We are out on X at developer. Wherever you listen to podcasts, you can leave us a review, leave us a thumbs up, thumbs down five stars, 18 bananas, whatever the review approach is. Love to hear from you. Good or bad. We have the developer in our channel out on YouTube. Check that out. If you're listening to us, you can actually see us. We're not as ugly as some may think pretty close though. And then if you, if you're tired of seeing our face, you can always go back to the audio version and just listen to this. And you can be like me and you can cheat and you can kick it up to like 1.25 speed or faster. And I will just say that if you crank it up all the way, then the theme music goes really, really quick. It's like, wow, that guy is quite the drummer. Um, and then the rest of us, we talk really, really high, probably the rest of the time, that being said, we need to wrap this one up. So go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to building better developers, the developer nor 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.