Transform Your Projects: The Ultimate Guide to Effective User Stories

Welcome to Building Better Developers, the Develop and Work Podcast, where we work on getting better step by step, professionally and personally. Let's get started. Hello and welcome back. I just faked out my co-host because he thought I was going to go Spanish, but I went back to the English translation this time. Hello, I am Rob Broadhead. I'm one of the founders of Develop and Work. Also one of the people they created this podcast, which is called the Develop and Work Podcast, Building Better Developers, actually just passed the 900 mark. If you guys want to flip back an episode or two, you'll get to see our little like, yay, celebration thing. So we've been doing this for a while. And as part of that, this season, we've taken a couple of seasons back, we're going back through those episodes and we're just kicking it out to AI and see what happens. What does it tell us? Essentially, we should have done and we're even changing the game today. We're going to try Gemini instead of ChatGPT that we're using up to this point. Hold your breath because it could be really excited. Maybe not very exciting what it gives us. I'm also the founder of RB Consultant where we are effectively, the easiest way to look at it, we are a fractional CIO consultancy. We're a business consultant. We come in, we do a technology assessment. We help you figure out basically by talking to you, what is, how your business works. Let's lay that out first. Let's get to the guts and the processes of how do you provide the best services and products to your customers. And then from there, we look at ways to improve it. It may be removing steps, it may be adding steps, it may be simplifying, it may be integrating, it may be automating, it may be innovating. There's a lot of different approaches we can take. We use technology and all the stuff that's out there at our disposal to find the best way for your program, for your company, for your product to move forward. We build you a technology roadmap that allows you to get started today, but then also make sure that your position for the future, whether it's six months or six years from now, we can hand you that roadmap and say, go for it, have fun, or anything else we can take you very deep. We can implement it with you. We can help you find a team that can implement it, you name it. We're going to help you find the best way forward and give you the keys to your car and let you drive. Good thing, bad thing. Good thing, bad thing today is like a perfect thing as I was coming into this is that it is cooled down a little bit. So the nights are finally cool enough that we are in what I, you know, my wife likes to call the free portion of the year a little bit in the spring and the fall where we're at because we get four seasons where you don't run heat and you don't run air. You can pretty much just, you know, let it run all that. You can just leave the windows open then all the time and be all natural. And that's pretty good, except for it got a little hot because of where we're at, it was getting a little hot today. So the bad thing is I was like, all right, I got to, I got to pick up the move and can't be in like, like normal shooting the episode spot, but it's not a bad thing. So it's like, it's pretty good and just a minor badge. So I think that's about as good as you could ask for on a given day, except you guys get to ask for even better, which is for Michael to introduce himself. So go for it, my friend. Hey everyone. My name is Michael Blosh. I'm one of the co-founders of developer Nerve building better developers. 900 seasons or 900 episodes. Go check it out. Now we've been around for a while. I'm also the owner of Envision QA. We help businesses run better by making sure that our software works the way it should, whether you're managing customers, selling online or running a clinic. We make sure your systems work more reliable, more efficient and easier to use. That means fewer headaches for you, happier customers and more time to focus on growth. We start by getting to know your business, reviewing your product, understanding your goals and assessing what works and what's not working. From there, we'd recommend the right solution, whether it's building you a custom tool, fixing what's broken, automating your tests or helping you prepare for a smoother launch. Our goal simply is to take care of the tech behind the scenes so you can focus on running and growing your business with confidence. You can learn more about us at EnvisionQA.com. Good thing, bad thing. Good thing, I'm loving this weather. This is awesome weather. Bad thing, my allergies have already started to kick in. I woke up this morning with a sinus headache. I've been on Benadryl, antihistamines. So unfortunately, it's one of those days where it's so nice to be outside, but you're in that kind of haze that you just can't really enjoy it. Well, we are not going to be in a haze moving forward with this, I hope. So we jumped right in. We're going to jump right into this one. So this episode was Transformative Projects, the ultimate guide to effective user stories. Episode title, Transformative Projects, the ultimate guide to effective user stories. Wow, that was very helpful. Thank you so much, AI. Host, your name, host's name. Opening one to two minutes, intro music, upbeat tech focus. We have totally nailed that, I'm going to say. Hooks, start with a relatable problem. Ever been in a sprint planning meeting where the user stories just don't make sense? You're left guessing what the customer actually wants. Today, we're talking about how to fix that. Introduce the topic, briefly explain what user stories are and why they're so crucial for developers, emphasize their role as a communication tool, not just as a technical spec. This is very much what we did the first time around. Actually, it's going to be interesting. I wonder how much this is going to be very close to what we did the first time around. So part one, the why, the philosophy of user stories, five to seven minutes. Discussion item, what is the core purpose of a user story? It's not a spec, it's a promise for a conversation. It's about shared understanding. Customer centric, the focus should always be on the user's perspective. Small digestible chunks, why breaking down work is essential for agility and accurate estimation. Another discussion item for this, why do developers often struggle with poorly written user stories? Vague requirements, which lead to rework, frustration and features nobody asked for. Lack of context, hard to build a robust solution without understanding the why. And blame game, when things go wrong, it's difficult to pinpoint where the breakdown happened. Now, this is quite a bit here. I want to talk a little bit about the, basically, the customer centric piece of it, because I think this is very, very key, is that when you keep it customer centric, when you keep it user story, when it's user specific, then what you end up doing is you are focusing on an outcome, for lack of a better term, you are focusing on like, what is the experience of this feature that we're building. And this, you know, for example, let's say it's always like the ATM. So you're focused on the user story of the user wants to get some money out of the ATM, and they need to get some from the checking. And then what that does is allows you to focus on requirements that are key for the story. So it's, you know, in that case, it's like the user needs to be able to enter a positive number, they need to be able to type it into a keyboard or maybe speak it through a microphone. You know, there's requirements like that. A very important thing that a user story does not get into if it's done right. And it usually it helps you because it's a user specific thing is that you don't get into implementation. It is very easy when you start really digging into requirements to get sucked into the implementation side of stuff, where you're now talking about like, well, we've got to have this data table, and we have to have this data type, and we have to have, you know, this special CSS class or whatever. It is a lot of things that can go into the the technical vision of how you're going to deliver it. And user stories are not really about the delivering it as much as they're about is what is how is it received? Is that user story? How do they experience the delivery part of it, which is where it talked here about it sets up a communication, because what it is, it says, hey, this is what the user needs to experience. Now, some later point, once we've got all of our user stories together, we can talk about how we deliver it, which is where we can go into some of the deeper requirements and validations and things like that. It's almost a straw man that we can use to start talking about that feature or that set of features. And really, the key to this, as it mentioned, is the why. Why do we have this user story? What is the goal of the user? Why do we need to provide this feature? Because if we do that, now we're actually building out the high level design, we'll say, in a way that is actually surface is serving the problem and solving the problem, as opposed to us just building some stuff and then sort of trying to tack on solutions after that. Where do you want to go with this one? Big area, plenty to go with. Yeah, so. I want to start by picking the big requirements, you know, leads to rework frustration and features nobody asked for. So, like you said, you know, if we start out by actually understanding the why and really focusing on the user, the customer centric approach to this, you hopefully won't run into this issue. But there are times, though, when your customer really doesn't understand their why. They may understand their business, but they don't know how their business works or how it's supposed to run. And that can run into a very huge problem when you start discussing requirements. You could easily get into a discussion where, well, we have this feature or product that we use and we do X, Y and Z with it. But in reality, they have six or seven paper trails or other processes that they do that are not exposed within the application that they're using. So you could be running into situations where because they don't understand their business, they have a vague understanding of the why, but they have all these compartmental pieces running their business that are not understood by the business. So when you get down to actually trying to figure out, OK, what are we building for you? You're going to run into a lot of rabbit holes and a lot of situations where you're going to have incomplete requirements. You're going to have disconnected requirements or you could have requirements that make no sense at all. It's like, wait, why are you doing this when you have this application over here that's doing it for you? Oh, I didn't know it did that. So you could even have them. The customer could have tools at their disposal already that they're misusing or don't even know that they have and they are using things incorrectly. So. I started I kind of went down to different rabbit hole with this, but that leads to the vague requirements, because if you ask them, how do you enter in, say, a customer's address, they say, oh, well, OK, I go over to this index card and I pull out the customer information, I go to the computer, I type it in and, OK, well, where did you type it in? Oh, I put it in Outlook. Well, wait, you have a, you know, like maybe a CRM or something. Why didn't you enter in them? Oh, I didn't know I could do that. So sometimes figuring out the why or the customer requirements may be taking a step back, have them walk through their business, like just walk through what they do in a day and figure out what they're doing and then start to ask them, well, why do you do that? What is the purpose of this? And maybe you might have to reverse engineer the requirements or the why, because they just may not know. Or it could be that they don't understand they understand what they need to accomplish, but they don't know how to get there. This actually brings up a conversation I was having with somebody the other day that is just it's a slight side note on this is the there is a level of trust that we have when we go with a customer. And when you start talking to staff in particular about like, what do you do? How do you how does it what is your user story? How do you solve this problem? What is the process? Sometimes you will get a different answer the first time than you get the second or third time, because the first time you get the official answer of this is how we're supposed to do it. But then once people have that trust and they're more comfortable with you, you find out either by hook or crook. Sometimes it's like they'll say, oh, by the way, we don't really do it this way. That's what we say we do. But this is actually how we do it. Or you'll be sitting there talking with them about it or watching them do it. And you'll just suddenly be like, wait a minute, what is that index card that you just pulled out of your desk? And why are you looking at that and actually like entering data based on that? There's things like that that are those insights that will help you with those user stories. That's just a little bonus stuff. Just make sure you're asking the right question the right way. Moving on to part two, according to Gemini. They are not a sponsor, by the way, but they would love to. I would be more than happy for an alphabet sponsor. That would be just great. Google, you guys can sponsor the heck out of a bias for all we cares. How? The anatomy of a great user story. 8 to 10 minutes. Discussion item. The classic as a dot dot dot. I want to dot dot dot. So that dot dot dot format. Break down each component as a user role. Why defining the user is critical. I want to goal the desired functionality. So that reason the business value or more of a motivation. This is the most important part for a developer. Discussion item. The three C's of user stories. The card, physical and digital representation story conversation. The discussion that happens around the story. Confirmation, the acceptance criteria that prove this story is complete. And then a final discussion item in this part is the invest model for good user stories. Is it independent? Is the I can it be worked on alone? Negotiable. Is there room for discussion? V is valuable. Does it provide business value? Estimation is E estimable. I'm sorry. Can we guess how long it'll take? S small. Is it a manageable size? And then T is testable. Can we verify it works? Well, there's a again, there's like a couple of episodes just with that. I think I want to go with the the breaking down each of the whole as a I want to. So that and it's the at the core, a user story is as a blah, I want to blah so that I can blah. And so that is the like that is the structure of the story. So it'd be as like as a podcaster, I want to record my discussion so that I can share it with my audience. It's it allows us to I think it's it's a great starting point. Let me start with that is it is no pun intended. That it is a great starting point to say, let's put the user story down in very human terms. Now, I would recommend and you can see this actually, I think the developer book or the site, one of those books we actually have, we get deeper into user stories and it's the other stuff. It's really gets into the discussion items because the user story itself is is critical. It's like, let's start. That's our why. That's our focus. That's what we're trying to get done. But then you've got underneath it these details that are a little bit more about like, OK, so that's how we're going to do it. But let's make sure that we're phrasing it like the investor they talk about. Let's phrase it in a way to make sure that it is right size so that we're not stalling. This is like one user story that has actually got a bunch of whether mini or micro user stories within it. Is it something that makes sense? Is it something that we can do and validate and verify and estimate things like that? Or is it too high in the sky? And if it's if it's not those things, then that means that we probably aren't adding enough details. So it could be stuff like I mean, I could start with as a podcaster, I want to be able to record my conversations so that I can share them with my my customers. But there's a lot around that. It's like, OK, well, you know, this is how you have that discussion to be like, well, how often do you want to record it? How do you want to record? How do you want to deliver it? Who are your customers? Because you may want to deliver it in a way that they can't get it. There's things like that. Do you want to ask them for email at the end of the end of every episode? There's things like there's a lot of details that come out of this. And it actually goes back a little bit to the prior part of of vague or missing requirements. Is this discussion? The whole point is to draw some of that out, is to try to find gaps and figure out where the story is not complete. Where did we miss something in this story that either needs to be its own story or needs to be specified in this one? So, again, I said this a lot of places you can go. So buckle up and like pick your spot, pick your race. All right. So I'm going to kind of piggyback off that with some of the other discussion items down there, because one of the biggest things, especially if you are a test driven developer or you drive your applications or whatever you're building through testing, where you put its user centric, its story based, the as a or I want to really helps you depict how what the story is, what is the requirement? Because number one question you have to have as you're going through those is do your stories have multiple meanings? And by that, I mean, if you basically read as a podcaster, I want to publish content. OK, well, what kind of if there are any questions about that, if there is an if then then you need to break that down into multiple stories. You need to do one story for like part one and you need to do one story for part two. You need to kind of break those apart because if you keep them too vague, your requirements could go down the rabbit hole later and you could end up with a solution. It doesn't quite catch all the use cases that you need because you didn't define them clearly. And that gets into that invest model. So, you know, independent can be worked on alone. You know, is this a small project? You need to break it out. It is a negotiable. It's a room for discussion. You know. Is this, for instance, a health care application? So there are certain rules and regulations that you are going to be bound to with the way that you write this application. You can't get around that. You are legally binding to follow those rules. Now, does that mean that there's no wiggle room in other parts of the application? No, you can probably do other things that you want within the application. You just have to follow a certain set of guidelines for the government or state or country that you live in. Value, you know, does it provide business value? This is a very interesting one because just recently we worked on a project where we actually had a feature that the customer asked for that we built because it was supposed to provide them value. And then we come to find out later in the project that that value that was so important at the beginning of the project went away. They actually went a different course and had not communicated that. So we had built something of value that was no longer used. So that is time wasted on developing what, you know, getting the product to the MVP sooner. And that also messes with the estimatables because can we guess how long it takes? Sure. If the requirements don't change midstream, if you can clearly define those deliverables at the beginning, you get those requirements and user stories to find well and everyone signs off on them and you do regular checkpoints. You should be on track. OK, yes, we are on track. If something changes, you should know early on how to pivot. Oh, if we change this or add this, this will change the estimates. You shouldn't get to the end and find out that you're a year or two years behind because, whoops, this core feature that absolutely had been in the application took an additional year and a half to build. So these are why these requirements are so important. Small, is it a manageable size? Well, if you do your user stories correctly, like I said, if you break them down to where they have only one meaning, it should be small enough. Now, that doesn't mean that that particular story is more complex and cannot be big. You could still pick at it and break it down into smaller pieces. Like Rob said, you know, do we need to send and collect an email at the end of the podcast? Do we need to do certain things? So you can ask additional questions to whittle that down smaller. And last of all, circle back around. Is it testable? Can we verify it works? Again, this goes with that test-driven development. So if you think about testing in mind, as you're working and building out the requirements for this application, you're going to know that, OK, in order to ensure that this user story works, this is how I'm going to test it from the user's perspective. So when you eventually put it in front of the user, there should be no surprise. And I just want to follow up on that one, is that a part of that, is it testable, is it verifiable, is that it's basically what does done mean? What does it mean for this to actually be achieved or completed? And that often can be a very big issue. So we're wrapping it up. I guess this is part three, even though there is a conclusion. But part three, practical tips for developers. Discussion item, what should developers do when they get a bad user story? Don't just code it, speak up and ask for clarification. Ask why. Challenge that I want to to get to the so that. Write acceptance criteria. Collaborate with the product manager to find clear testable criteria. Break it down. If a story is too big, propose a way to split it into smaller, more manageable pieces. Discussion item, pro tips and common pitfalls. Don't get lost in the technical weeds. The stories for the user, the technical details go into the subtasks. Example scenarios. Talk through a couple of bad stories and show how to fix them. Bad. Add a contact form. Good. As a potential customer, I want to fill out a contact form with my name, email, so that I can get in touch with the company about their services. Tooling. Mention tools like Jira, Trello or Asana and how they can support user stories. I want to keep this one brief because we are going to we could go very long again. I want to go with that last one, the good one. As a potential customer, I want to fill out a contact form with my name, email the message so that I can get in touch with the company about their services. I want to just break this down really quick for the anatomy of a good story, but then also where the discussion needs to go. It gives the potential customer, which it can have its own little discussion, but then it actually says a contact form with name, email, message. Well, that is maybe something that is up for debate. It's like, OK, well, why? Why do you want that information? And where is it going to go? How are we going to do that? And you have with that so that I can get in touch. Well, this would only say that you can get in touch by email. Do you want to actually ask for a phone number? Do you want to make email required? Do you want to make a phone number required? Do you want to use snail mail? I mean, there's do you want to use a WhatsApp or you want to do a LinkedIn? Yeah, there's the contacts stuff in particular can get very complicated very quickly. Can a person have multiple contacts? Do they need to have a preferred contact? Do they need to have a contact that only occurs at 2am and a different one that occurs at 3am? Do they need to have a weekday versus a weekend? Yeah, there's there are a lot of things that can go into this. And when you get into the implementation of it, actually building it out, that's part of it. And it is part of it. If you do test driven, then you're going to say, well, OK, can we contact a customer? Can we can we report? Can we pull back up their information? Can we see where we send them a message? Can they reply to us? If things like that, those questions are how we get to the the finality of what it is that we're building to say, yes, now we built something and it has provided that the needed functionality. But because we do this so that it really should spark questions of like, do you really need that information? Or if you're saying that, don't you also need to do this to get a couple of extra little pieces in? Closing thoughts on that. Yeah, so I'm going to take the first part because we've talked about this a lot with our discussions of Coder versus Developer. The first tip that was talked about with this was, you know, don't just code it, speak up and ask for clarification before you really work any ticket, you should always read through it and make sure that you understand what it is that's being asked. What is the why of the ticket, essentially? What is the acceptance criteria? What am I supposed to be doing with this ticket? Is it all clearly defined? And then finally, make sure that the task itself doesn't have one of those if then stories where it's unclear what it is that you're supposed to do. Implied requirements are not good requirements. Defined requirements are good requirements. I will add, I want to wrap that one up, add to that is that the make an app that looks like this app is not a good requirement. Or, you know, just make it look like this, make it work like that is not going to be good enough. And so expect that you're going to get some questions. I expect that I'm going to get some emails because not because I incensed people, but because I'm asking for emails. Shoot us an email at info at developerpremiere.com. Let us know what you think. What do you like? What don't you like? Where would you like us to go next? We have been cruising along. We have another season coming up after about another half dozen episodes, something like that. And we haven't even decided where we want to go next with that one. We are open to interviews. We've got some thoughts on that. And I know I've been teasing that for ever since we last did an interview, but it is it is real. It's not just like me, just like ripping or anything like that. We may actually get to it. We just haven't haven't followed through yet. So we'll see how that one goes. We'd love to hear if you want to be interviewed. If you'd like to talk to us, we would love to talk to you. Also, like I said, any suggestions, recommendations, anything like that email, you can check us out on developer.com. We've got a lot of stuff going on there. There's contact us form any any article, any of where we get our podcast, any podcast episode out on YouTube, any of the episodes there, you can leave comments there. And we will get back to you as soon as we can on those. And if you leave us something and you're like, hey, or you try to go somewhere, you're like, we don't find your podcast here. Let us know and make sure because we want to be seen there. Want to be there as well. But theoretically, we've been told that wherever you can get podcasts, we are there. We're already there. We're waiting for you to listen. So jump right on. If you're listening to this, then you can always check us out on the development or channel on YouTube. And you actually see us as we go through it and you get bonus episode bonus information on basically every single episode, sometimes way more bonus and sometimes a little less. Depends on how long we get off the on rabbit trails about this. All that being said, I do want to once again say how much we appreciate you and your time that so valuable and yet you're sharing it with us. So we want to make sure we're giving back and helping to make the most of respecting that time. And I'm going to respect it by saying 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 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.