Detailed Notes
In this episode of Building Better Developers with AI, Rob Broadhead and Michael Meloche revisit a listener favorite: user stories.
We explore why writing better user stories is essential for keeping projects on track, avoiding vague requirements, and focusing on outcomes that truly matter to users.
👉 What you’ll learn: • The core structure of user stories (As a… I want… So that…) • The Three C’s: Card, Conversation, Confirmation • The INVEST model: Independent, Negotiable, Valuable, Estimable, Small, Testable • Practical tips for improving unclear or oversized stories • Real-world pitfalls when user requirements are misunderstood
Whether you’re a developer, product owner, or project manager, this guide will help you transform your projects by writing better user stories.
đź”— Read and listen to the podcast: https://develpreneur.com/writing-better-user-stories/ đź”— More episodes at https://develpreneur.com
đź‘Ť Like, comment, and subscribe for more insights on building better developers and better businesses!
00:00:00 Intro, Bug Story & Host Setup 00:05:00 Meet the Hosts & Good/Bad Things 00:09:00 Main Topic: Writing Better User Stories 00:17:00 Frameworks: Anatomy, Three C’s, INVEST 00:25:30 Practical Tips, Examples & Closing Thoughts
Transcript Text
[Music] interesting little thing because I hit record because I want to talk about this. This is an eagle bug is I think this is like one of these things that it's a fortuitous uh way that things happen. I think what we've got in this application is I'm pretty sure what happens is we've got three different statuses and different places where you set statuses where you activate or deactivate things. Different statuses get set. So, I think the the bug with this one is that it set a status, but it didn't set the same. It didn't ripple affect that status all the way down, which for those of you that have just joined us, this is a good little bit of bonus stuff. Is it make sure you're very clear when you are designing out your requirements and everything else that you have like one source of truth for things like what is the status of this record or is this active or is it deleted or things like that because if you don't it gets really confusing we get further on or have another project that has had similar things where it evolved and we redesigned a couple of core pieces and then suddenly some of those statuses moved and so the things that were in like one place are now actually in a different place or in two different places and then you have to go find all the logic that touches that and make sure that it got updated which if you do things right and it's truly object-oriented and all that kind of stuff then probably you only do it once but inevitably that's not always the case. So that was Yeah. And then the whole Okay, it's time to just not bother with that one. Let's just like take that feature out. That is I it is probably the fastest solution, but I said I'm still going to have to dig through all this stuff cuz like even taking that out means we need to go everywhere else that we did it and need to figure out how did we do it before and then take that, you know, feature away from them. which also means probably it's going to be its own little debugging journey of finding some inconsistencies I bet in the code where you know one developer did it this way and then later somebody else came and did it another way. So, I said it's probably a good cleanup effort anyways. It would it will probably protect us from uh surprise bugs that would show up further down the, you know, further downstream, you know, a month from now. We're like, well, this worked great until you did this one thing and you find out that it's Yeah, that one screen, that one button actually doesn't do it the same way. And fun times all around. So, um, that being said, I'm going to shorten myself a little bit here because of just where I am today as I was up in the apartment and doing that and it was too freaking hot. I didn't want to like close the windows. I was like, it's too hot to to do this, but I didn't want to close the windows. So, I'm like, let me get somewhere that's got air. And I've got my little fanny fan going here. And I want to go back to where cuz I'm going to try I think I'm going to try something different today. But how many freaking Zoom windows do I have open there? Okay. Um >> that reminded me do not disturb. Oh, that is a good catch because I actually just got um Why are you Let me see if I can move this. Well, that is not where I want to move it. Oh, that's that's my problem. Okay, I got to move this guy over here. This is I'm on two different screens and I was thinking I could just like do the uh whatever the the spaces that that Mac has. >> Mhm. >> And I was thinking I could do that, but um because I got two screens, it doesn't want to like move the spaces properly. So, what I'm going to do, I'm I know, trust me, I'm This is all for a fact. Dramatic pause. Everybody's like, "What's What are you doing? What's different?" I'm going to throw it in uh Gemini today. And it looks like it's giving me uh cool. It's giving me like a pretty good I wasn't sure how well it was going to give me a a breakdown. Uh and it looks pretty good. So I'm going to like hit the and copy that. Wow. This is this is actually going to be pretty fun. I think if I can find all the places that I need to move this uh you and you I need let me just get rid of that. I don't need a twoerson conversation with you. Need a oneperson conversation with you and put it right there. Okay. And the topic today is transform your projects, the ultimate guide to effective user stories. And so let me get my Zoom window back so I can sort of look at you [Music] because just keeps my stomach turning the whole time. H just kidding. Um, and so I think we are ready to go with a little th uno. 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. Who am I? I am Rob Broadhead. I'm one of the founders of Developer. Also one of the people that created this podcast, which is called the Developer Podcast, Building Better Developers. Actually just passed the 900 mark. If you guys want to flip back a episode or two, you'll get to see our little like yay celebration thing. Uh, 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 uh Gemini instead of chat GPT that we've been using up to this point. Hold your breath because it could be really exciting or maybe not very exciting what it gives us. I'm also the founder of RB Consulting 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 what 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 you're positioned for the future, whether it's 6 months or 6 years from now. We can hand you that road map 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 cuz we get four seasons uh where you don't run heat and you don't run air. You can pretty much just, you know, let it run all the you can just leave the windows open all the time and be all natural. Um, 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 and move and can't be in my like normal shooting the uh 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 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 Malashsh. I'm one of the co-founders of developer nerve building better developers 900 season or 900 episodes. Go check it out. You know, we've been around for a while. Um I'm also the owner of Envision QA. We help businesses run better by making sure their 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 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 like a sinus headache and I've been on benadryil, you know, antihistamines. So, unfortunately, it's one of those uh days where it's so nice to be outside, but you're in that kind of haze and 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, uh this is the episode was transformative projects, the ultimate guide to effective user stories. Uh episode title, transform your projects, the ultimate guide to effective user stories. Wow, that was very helpful. Thank you so much. AI uh host, your name, co-host name. Opening one to two minutes. Intro music, upbeat, tech focused. We have totally nailed that. I'm going to say um 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 are so crucial for developers. Emphasize their role as a communication tool, not just as a technical spec. And this is very much what we did uh 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 sentry. 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 was quite a bit here. I I want to talk a little bit about the basically it's a the customer centric piece of it because I think that this is very very key is that when you keep it customercentric when you keep it user story when it's user specific then what you end up doing is you are focusing on uh 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 For example, let's say it's a 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 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 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. There's 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 is it says hey this is what the user needs to experience. Now at 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 a 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 is the why. Why do we have this user story? What is the goal of the user? Why do we need provide this feature? Because if we do that now, we're actually building out the the highlevel design, we'll say, and the requirements 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'm going to start by picking the vague 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 um we have this feature or product that we uh 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, okay, 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 uh 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 a 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 okay I go over to this index card and I pull out the customer information. I go to the computer. I type it in and okay well where did you type it in? Oh I put it in Outlook. Well wait you have a uh 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? Why what is the purpose of this? And maybe you might have to reverse engineer the requirements or the why. uh because it they just may not know or it could be that they don't 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. Uh 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 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?" You know, there's things like that that are those insights that will help you with those user stories. That's just a little bonus stuff is to just make sure you're asking the right question the right way. Moving on to part two according to uh Gemini and 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 them. Buy us all we care. Uh the 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. uh 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 motiv motivation this is the most important part for a developer a discussion item the three C's of user stories the card physical and digital representation of story conversation the discussion that happens around the story confirmation the acceptance criteria that prove the story is complete and then a final discussion item in this part is the invest model for good user stories independent It's 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? Small. Is it a manageable size? And then T is testable. Can we verify it works? Um, wow. There's a again there's like a couple episodes just with that. I think I want to go with the the breaking down each 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 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 with RB 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 okay so that's how we're going to do it but let's make sure that we're phrasing it like the investment they talk about. Let's phrase it in a way to make sure that it is rightsized so that we're not stalling like this is like one user story that is actually got a bunch of other mini or micro user stories within it. Uh is it something that makes sense? Is it something that we can do and validate and you know verify and estimate things like that or is it too high in the sky? Uh, 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, okay, 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 it? How do you want to deliver it? Who are your customers? you know, because you may want to deliver it in a way that they can't get it. Um, there's things like that. You know, do you want to ask them for email at the end of the, you know, 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 that this discussion, the whole point is to draw some of that out, is to try to find gaps and 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, like I said, that's a lot of places you can go. So buckle up and like pick your spot, pick your race. >> All right. So I I'm going to kind of piggyback off that with some of the uh other discussion items down there because one of the biggest things especially if you're are a test-driven developer or you drive your applications or whatever you're building through testing where you put it's user centric it's 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 okay well what kind of if there are any questions about that if there is an if 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 you can get kind of break those apart cuz if you keep them too vague, your requirements could go down the rabbit hole later uh and you could end up with a solution that doesn't quite catch all the use cases that you need because you didn't define them clearly. And that gets into uh that invest model. So, you know, independent can it be worked on alone? You know, is this a small project? Do you need to break it out? Um it is it negotiable? Is there room for a discussion? You know, is this for instance a healthcare 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 uh or state or country that you live in. Uh 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 uh on developing what you know getting the product to um the MVP sooner and that also messes with the uh estimatables because can we guess how long it takes? Sure. If the requirements don't change mid-stream, if you can clearly define those deliverables at the beginning, you get those uh requirements and user stories defined well and everyone signs off on them and you do regular checkpoints, you should be on track that okay, 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. uh you shouldn't get to the end and find out that you're a year two years behind because whoops this core feature that absolutely had to be in the application took an additional year and a half to build. So you you these are why these requirements are so important. Uh small is it man 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 could not 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 an 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, I'll 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 okay for to 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. I just sort of follow up on that one is that the a part of that is it testable? Is it verifiable? Is that it's basically what does done mean? What does it what does it mean for this to actually be uh achieved or completed? And that often can be a very big issue. So uh I we're wrapping wrapping it up and I guess this part three even though it's not there is a conclusion but part three practical tips for developers discussion on 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 the I want to to get to the so that uh 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 story is for the user. The technical details go into the subtasks. Uh 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, and message so that I can get in touch with a company about their services. Tooling mentioned tools like Jira, Trello or ASA and how they can support user stories. I want to keep this one briefly 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, and a message so that I can get in touch with the company about their services. Now, I want to just like break this down really quick for like 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's it actually says a contact form with name, email, and message. Well, that is maybe something that is up for debate. It's like, okay, well, why why do you want that information? Where where's 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 app? You know, there's the contact stuff in particular can get very complicated very quickly. Can a person have multiple contacts? Do they need to have a preferred contact tact? Do they need to have a contact that only occurs at 2 am and a different one that occurs at 3:00 a.m.? 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, okay, can we contact a customer? Can we, you know, can we repull, can we pull back up their information? Can we see where we sent 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've built something and it has provided that uh the needed functionality. But because we do the 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 extra little pieces in? Uh closing thoughts on that? >> Yeah. So I'm going to take the first part because we talked about this a lot with our discussions of coder versus developer. This 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 will just 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. Uh I expect that I'm going to get some emails because not because I insensed people but because I'm asking for emails. Shoot us an email at [email protected]. Let us know what you think. What do you like? What don't you like? Where would you like us to go next? We we've been cruising along. We have another season coming up after, you know, about another half dozen episodes, something like that. And uh we haven't even decided where we want to go next with that one. Uh we are open to uh interviews. We we've got some thoughts on that. And I know I've been teasing that for ever since we last did an interview, but uh 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. Uh 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 got a lot of stuff going on there. There's contact us form, uh you any any article, any of where you 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. We'll 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 podcast, we are there. We're already there. We're waiting for you to listen. So, jump right on. Uh, if you're listening to this, then you can always check us out on the developer 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 uh 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. Bonus material. So, let's just go I'll just like read the little conclusion here, the last little bit, and then see where you want to go. Summary to recap the key points. User stories are about conversation and value, not just tasks. Personal challenge. Encourage listeners to actively improve the user stories on their projects this week. Call to action. What are your worst or best user stories? Share them with us on Twitter using developing. Look at even got that right. Uh mention where to find the podcast and how to subscribe. Um find it with subscri subscribe button. I don't even know how to subscribe. I like I know you go there, you hit subscribe. Whatever your app is, it's got a subscribe button. I'm not going to walk through all of them. And then there's outro music with a little fade out, which >> we do have. Yes, we do have. I was like I was like, we do still have the fade out. I've like this tells you it's like been a while since I've actually done that side of it. And I actually have I cheat. I have my podcast stuff all set up. So like I skip stuff at the end and the beginning and the end so that I can like move quickly into my next podcast and not listen to intros and outros 15 times in a row. So uh there you go. There's some bonus some bonus material right there. great ways to like cut out the stuff that you hear every single episode once you realize I don't really need to hear that anymore. But that's also bonuses. That's why sometimes I mix stuff up a little bit and throw odd things in. Uh just to make sure that we, you know, give you a little bit of a reason to stick around for a little. It's like a bonus. It's like the bonus at the end of a Marvel movie or something like that is you never know when we'll have a postredit scene. We haven't had one yet, but maybe we will now. All right. Bonus information, bonus material from you. >> Yeah. So, I'm going to check on the personal challenge a little bit here. So, we've talked multiple times, many different conversations. We've got lots of material on the site to check out. But, you know, if you are not writing user stories, if you really aren't sure what a user story is, I want you to go out, take a test that you're working on right now and Google how to write a user story. If you don't know how to do this, just do a quick Google search. There's lots of examples out there. Jira, um, Asana, those tools have, uh, documentation on their wikis about user stories and how to incorporate them with their applications. But start take the task that you're working on right now and take it clear. Start with what the problem is. Try to write a user story based on the problem that you would understand and then pick at it. Make sure it gives you everything you need to actually uh, you know, write the feature. make sure that you can test it and make sure that you have what you need to sign off on it to say that it's done. Essentially, what is the definition of done? So, I would start there. Uh go out, pick something, work through it, and then when you're done, uh see what the difference is compared to what you started with and see if your job is now easier or harder to get the test done. Or better yet, did what you come up with actually uh match what you started with? or is what you came up with actually what you need to do your work meaning that the initial task was going to send you down the wrong rabbit hole. >> Yeah, I think that's this is one of those places that uh no matter how many times you've built user stories, you can get better every time. Uh I think there's always something you can learn from them. Yeah, maybe it's like not every user story because you're going to get some that you will be able to just like you'll walk through and go like this is you story, this is your story. This is what it is. This is what you have to do. This is what you have to ask about. This is what you need to answer. These are those things. So there's going to be things like we talk all the time about like a login. You know, if you have a user, do you have one user? Do you have multiple users? How do they log in? What is their username? Like what's the unique value? What do they what if they forget their name? What if they forget their password? How do you do that? Like all of those stories are related to that. And we have them for other things depending on your integrations and all this other stuff that you do. But there's always going to be new stories. There always going to be new flavors of problems essentially you're going to be solving. so that you're you're going to learn how to better ask those questions and flesh out the pieces that you missed last time around when you were building out the user story. Uh that's why we ask for an email every single time basically because that helps us flesh out some of the pieces that we might be missing. But thank you for not missing this episode. Thank you for sticking around to the end and catching all of your bonus material as well. We will be back uh before you know it with the next episode starting out with our general green room stuff and whatever topic we're going to cover next. and then we'll dive right into it because that's what we're here for. Thank you so much for your time. We appreciate you so much and have a great day. [Music]
Transcript Segments
[Music]
interesting little thing because I hit
record because I want to talk about
this. This is an eagle bug is I think
this is like one of these things that
it's a fortuitous
uh way that things happen. I think what
we've got in this application is I'm
pretty sure what happens is we've got
three different statuses and different
places where you set statuses where you
activate or deactivate things. Different
statuses get set. So, I think the the
bug with this one is that it set a
status, but it didn't set the same. It
didn't ripple affect that status all the
way down, which for those of you that
have just joined us, this is a good
little bit of bonus stuff. Is it make
sure you're very clear when you are
designing out your requirements and
everything else that you have like one
source of truth for things like what is
the status of this record or is this
active or is it deleted or things like
that because if you don't it gets really
confusing we get further on or have
another project that has had similar
things where it evolved and we
redesigned a couple of core pieces and
then suddenly some of those statuses
moved and so the things that were in
like one place are now actually in a
different place or in two different
places and then you have to go find all
the logic that touches that and make
sure that it got updated which if you do
things right and it's truly
object-oriented and all that kind of
stuff then probably you only do it once
but inevitably that's not always the
case. So that was Yeah. And then the
whole Okay, it's time to just not bother
with that one. Let's just like take that
feature out. That is I it is probably
the fastest solution, but I said I'm
still going to have to dig through all
this stuff cuz like even taking that out
means we need to go everywhere else that
we did it and need to figure out how did
we do it before and then take that, you
know, feature away from them. which also
means probably it's going to be its own
little debugging journey of finding some
inconsistencies I bet in the code where
you know one developer did it this way
and then later somebody else came and
did it another way. So, I said it's
probably a good cleanup effort anyways.
It would it will probably protect us
from uh surprise bugs that would show up
further down the, you know, further
downstream, you know, a month from now.
We're like, well, this worked great
until you did this one thing and you
find out that it's Yeah, that one
screen, that one button actually doesn't
do it the same way. And
fun times all around. So, um,
that being said, I'm going to shorten
myself a little bit here because of just
where I am today
as I was up in the apartment and doing
that and it was too freaking hot. I
didn't want to like close the windows. I
was like, it's too hot to to do this,
but I didn't want to close the windows.
So, I'm like, let me get somewhere
that's got air. And I've got my little
fanny fan going here. And I want to go
back to where cuz I'm going to try I
think I'm going to try something
different today.
But how many freaking Zoom windows do I
have open there? Okay. Um
>> that reminded me do not disturb.
Oh, that is a good
catch because I actually just got
um Why are you
Let me see if I can move this. Well,
that is not where I want to move it.
Oh, that's that's my problem. Okay, I
got to move this guy over here. This is
I'm on two different screens and I was
thinking I could just like do the uh
whatever the the spaces that that Mac
has.
>> Mhm.
>> And I was thinking I could do that, but
um because I got two screens, it doesn't
want to like move the spaces properly.
So, what I'm going to do, I'm I know,
trust me, I'm This is all for a fact.
Dramatic pause. Everybody's like,
"What's What are you doing? What's
different?" I'm going to throw it in uh
Gemini today. And it looks like it's
giving me uh cool. It's giving me like a
pretty good I wasn't sure how well it
was going to give me a a breakdown. Uh
and it looks pretty good. So I'm going
to like hit the
and copy that. Wow. This is this is
actually going to be pretty fun. I think
if I can find all the places that I need
to move this uh
you and you I need let me just get rid
of that. I don't need a twoerson
conversation with you. Need a oneperson
conversation with you and put it right
there. Okay. And the topic today is
transform your projects, the ultimate
guide to effective user stories. And so
let me get my Zoom window back so I can
sort of look at you
[Music]
because just keeps my stomach turning
the whole time. H just kidding. Um, and
so I think we are ready to go with a
little th
uno.
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. Who
am I? I am Rob Broadhead. I'm one of the
founders of Developer. Also one of the
people that created this podcast, which
is called the Developer Podcast,
Building Better Developers. Actually
just passed the 900 mark. If you guys
want to flip back a episode or two,
you'll get to see our little like yay
celebration thing. Uh, 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 uh Gemini instead of
chat GPT that we've been using up to
this point.
Hold your breath because it could be
really exciting or maybe not very
exciting what it gives us. I'm also the
founder of RB Consulting 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 what 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 you're
positioned for the future, whether it's
6 months or 6 years from now. We can
hand you that road map 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 cuz
we get four seasons uh where you don't
run heat and you don't run air. You can
pretty much just, you know, let it run
all the you can just leave the windows
open all the time and be all natural.
Um, 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 and
move and can't be in my like normal
shooting the uh 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 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
Malashsh. I'm one of the co-founders of
developer nerve building better
developers 900 season or 900 episodes.
Go check it out. You know, we've been
around for a while. Um I'm also the
owner of Envision QA. We help businesses
run better by making sure their 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 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 like a sinus headache
and I've been on benadryil, you know,
antihistamines. So, unfortunately, it's
one of those uh days where it's so nice
to be outside, but you're in that kind
of haze and 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, uh this is the
episode was transformative projects, the
ultimate guide to effective user
stories. Uh episode title, transform
your projects, the ultimate guide to
effective user stories. Wow, that was
very helpful. Thank you so much. AI uh
host, your name, co-host name. Opening
one to two minutes. Intro music, upbeat,
tech focused. We have totally nailed
that. I'm going to say um 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 are so crucial for developers.
Emphasize their role as a communication
tool, not just as a technical spec. And
this is very much what we did uh 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 sentry. 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 was quite a bit here. I I want
to talk a little bit about the basically
it's a the customer centric piece of it
because I think that this is very very
key is that
when you keep it customercentric when
you keep it user story when it's user
specific then what you end up doing is
you are focusing on uh 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
For example, let's say it's a 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 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 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. There's 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 is it
says hey this is what the user needs to
experience. Now at 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 a
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 is the why.
Why do we have this user story? What is
the goal of the user? Why do we need
provide this feature? Because if we do
that now, we're actually building out
the the highlevel design, we'll say, and
the requirements 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'm going to start by picking the vague
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 um we have this feature or
product that we uh 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, okay,
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 uh 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 a
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
okay I go over to this index card and I
pull out the customer information. I go
to the computer. I type it in and okay
well where did you type it in? Oh I put
it in Outlook. Well wait you have a uh
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? Why what
is the purpose of this? And maybe you
might have to reverse engineer the
requirements or the why. uh because it
they just may not know or it could be
that they don't 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.
Uh 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 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?" You know, there's things like
that that are those insights that will
help you with those user stories. That's
just a little bonus stuff is to just
make sure you're asking the right
question the right way. Moving on to
part two according to uh Gemini
and 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 them. Buy us
all we care. Uh the 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. uh 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 motiv motivation this
is the most important part for a
developer a discussion item the three
C's of user stories the card physical
and digital representation of story
conversation the discussion that happens
around the story confirmation the
acceptance criteria that prove the story
is complete and then a final discussion
item in this part is the invest model
for good user stories independent It's
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? Small. Is it a
manageable size? And then T is testable.
Can we verify it works? Um, wow. There's
a again there's like a couple episodes
just with that. I think I want to go
with the the breaking down each 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 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 with RB 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 okay so
that's how we're going to do it but
let's make sure that we're phrasing it
like the investment they talk about.
Let's phrase it in a way to make sure
that it is rightsized so that we're not
stalling like this is like one user
story that is actually got a bunch of
other mini or micro user stories within
it. Uh is it something that makes sense?
Is it something that we can do and
validate and you know verify and
estimate things like that or is it too
high in the sky? Uh, 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, okay, 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 it? How do you want to
deliver it? Who are your customers? you
know, because you may want to deliver it
in a way that they can't get it. Um,
there's things like that. You know, do
you want to ask them for email at the
end of the, you know, 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 that this discussion,
the whole point is to draw some of that
out, is to try to find gaps and 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, like I said, that's
a lot of places you can go. So
buckle up and like pick your spot, pick
your race.
>> All right. So I I'm going to kind of
piggyback off that with some of the uh
other discussion items down there
because one of the biggest things
especially if you're are a test-driven
developer or you drive your applications
or whatever you're building through
testing where you put it's user centric
it's 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 okay
well what kind of if there are any
questions about that if there is an if
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 you can
get kind of break those apart cuz if you
keep them too vague, your requirements
could go down the rabbit hole later uh
and you could end up with a solution
that doesn't quite catch all the use
cases that you need because you didn't
define them clearly. And that gets into
uh that invest model. So, you know,
independent can it be worked on alone?
You know, is this a small project? Do
you need to break it out? Um it is it
negotiable? Is there room for a
discussion? You know, is this for
instance a healthcare 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 uh or state or country that
you live in. Uh 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 uh
on developing what you know getting the
product to um the MVP sooner and that
also messes with the uh estimatables
because can we guess how long it takes?
Sure. If the requirements don't change
mid-stream, if you can clearly define
those deliverables at the beginning, you
get those uh requirements and user
stories defined well and everyone signs
off on them and you do regular
checkpoints, you should be on track that
okay, 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. uh
you shouldn't get to the end and find
out that you're a year two years behind
because whoops this core feature that
absolutely had to be in the application
took an additional year and a half to
build. So you you these are why these
requirements are so important. Uh small
is it man 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 could not 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 an 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, I'll
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 okay for to 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.
I just sort of follow up on that one is
that the a part of that is it testable?
Is it verifiable? Is that it's basically
what does done mean? What does it what
does it mean for this to actually be uh
achieved or completed? And that often
can be a very big issue. So uh I we're
wrapping wrapping it up and I guess this
part three even though it's not there is
a conclusion but part three practical
tips for developers discussion on 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 the I want to to get to the so
that uh 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 story is for
the user. The technical details go into
the subtasks. Uh 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, and message so that I can
get in touch with a company about their
services. Tooling mentioned tools like
Jira, Trello or ASA and how they can
support user stories. I want to keep
this one briefly 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, and
a message so that I can get in touch
with the company about their services.
Now, I want to just like break this down
really quick for like 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's it actually says a contact
form with name, email, and message.
Well, that is maybe something that is up
for debate. It's like, okay, well, why
why do you want that information? Where
where's 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 app? You know, there's the
contact stuff in particular can get very
complicated very quickly. Can a person
have multiple contacts? Do they need to
have a preferred contact tact? Do they
need to have a contact that only occurs
at 2 am and a different one that occurs
at 3:00 a.m.? 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, okay, can we
contact a customer? Can we, you know,
can we repull, can we pull back up their
information? Can we see where we sent
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've built something and it has
provided that uh the needed
functionality. But because we do the 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 extra
little pieces in? Uh closing thoughts on
that?
>> Yeah. So I'm going to take the first
part because we talked about this a lot
with our discussions of coder versus
developer.
This 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 will just 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. Uh I expect that I'm going to
get some emails because not because I
insensed people but because I'm asking
for emails. Shoot us an email at
[email protected]. Let us know what you
think. What do you like? What don't you
like? Where would you like us to go
next? We we've been cruising along. We
have another season coming up after, you
know, about another half dozen episodes,
something like that. And uh we haven't
even decided where we want to go next
with that one. Uh we are open to uh
interviews. We we've got some thoughts
on that. And I know I've been teasing
that for ever since we last did an
interview, but uh 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. Uh 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 got a lot of stuff
going on there. There's contact us form,
uh you any any article, any of where you
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. We'll
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 podcast, we are
there. We're already there. We're
waiting for you to listen. So, jump
right on. Uh, if you're listening to
this, then you can always check us out
on the developer 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 uh 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. Bonus
material. So, let's just go I'll just
like read the little conclusion here,
the last little bit, and then see where
you want to go. Summary to recap the key
points. User stories are about
conversation and value, not just tasks.
Personal challenge. Encourage listeners
to actively improve the user stories on
their projects this week. Call to
action. What are your worst or best user
stories? Share them with us on Twitter
using developing. Look at even got that
right. Uh mention where to find the
podcast and how to subscribe. Um find it
with subscri subscribe button. I don't
even know how to subscribe. I like I
know you go there, you hit subscribe.
Whatever your app is, it's got a
subscribe button. I'm not going to walk
through all of them. And then there's
outro music with a little fade out,
which
>> we do have. Yes, we do have. I was like
I was like, we do still have the fade
out. I've like this tells you it's like
been a while since I've actually done
that side of it. And I actually have I
cheat. I have my podcast stuff all set
up. So like I skip stuff at the end and
the beginning and the end so that I can
like move quickly into my next podcast
and not listen to intros and outros 15
times in a row. So uh there you go.
There's some bonus some bonus material
right there. great ways to like cut out
the stuff that you hear every single
episode once you realize I don't really
need to hear that anymore. But that's
also bonuses. That's why sometimes I mix
stuff up a little bit and throw odd
things in. Uh just to make sure that we,
you know, give you a little bit of a
reason to stick around for a little.
It's like a bonus. It's like the bonus
at the end of a Marvel movie or
something like that is you never know
when we'll have a postredit scene. We
haven't had one yet, but maybe we will
now. All right. Bonus information, bonus
material from you.
>> Yeah. So, I'm going to check on the
personal challenge a little bit here.
So, we've talked multiple times, many
different conversations. We've got lots
of material on the site to check out.
But, you know,
if you are not writing user stories, if
you really aren't sure what a user story
is, I want you to go out, take a test
that you're working on right now and
Google how to write a user story. If you
don't know how to do this, just do a
quick Google search. There's lots of
examples out there. Jira, um, Asana,
those tools have, uh, documentation on
their wikis about user stories and how
to incorporate them with their
applications. But start take the task
that you're working on right now and
take it clear. Start with what the
problem is. Try to write a user story
based on the problem that you would
understand and then pick at it. Make
sure it gives you everything you need to
actually uh, you know, write the
feature. make sure that you can test it
and make sure that you have what you
need to sign off on it to say that it's
done. Essentially, what is the
definition of done? So, I would start
there. Uh go out, pick something, work
through it, and then when you're done,
uh see what the difference is compared
to what you started with and see if your
job is now easier or harder to get the
test done. Or better yet, did what you
come up with actually uh match what you
started with? or is what you came up
with actually what you need to do your
work meaning that the initial task was
going to send you down the wrong rabbit
hole.
>> Yeah, I think that's this is one of
those places that uh no matter how many
times you've built user stories, you can
get better every time. Uh I think
there's always something you can learn
from them. Yeah, maybe it's like not
every user story because you're going to
get some that you will be able to just
like you'll walk through and go like
this is you story, this is your story.
This is what it is. This is what you
have to do. This is what you have to ask
about. This is what you need to answer.
These are those things. So there's going
to be things like we talk all the time
about like a login. You know, if you
have a user, do you have one user? Do
you have multiple users? How do they log
in? What is their username? Like what's
the unique value? What do they what if
they forget their name? What if they
forget their password? How do you do
that? Like all of those stories are
related to that. And we have them for
other things depending on your
integrations and all this other stuff
that you do. But there's always going to
be new stories. There always going to be
new
flavors of problems essentially you're
going to be solving. so that you're
you're going to learn how to better ask
those questions and flesh out the pieces
that you missed last time around when
you were building out the user story. Uh
that's why we ask for an email every
single time basically because that helps
us flesh out some of the pieces that we
might be missing. But thank you for not
missing this episode. Thank you for
sticking around to the end and catching
all of your bonus material as well. We
will be back uh before you know it with
the next episode starting out with our
general green room stuff and whatever
topic we're going to cover next. and
then we'll dive right into it because
that's what we're here for. Thank you so
much for your time. We appreciate you so
much and have a great day.
[Music]