Detailed Notes
In this episode of *Building Better Developers*, we revisit “User Stories Unveiled” and dive into why user stories matter in software development. We walk through how to write effective stories, how they relate to test-driven development, and how to avoid the common pitfalls that slow down delivery.
🎙 Hosts: Rob Broadhead & Michael Meloche 🎯 Topic: How to use user stories in software development to drive clarity, testing, and better results
🌐 Learn more: Develpreneur Podcast – https://develpreneur.com/user-stories-in-software-development/ EnvisionQA – https://envisionqa.com RB Consulting – https://rb-sns.com
📬 Email us: [email protected] 💬 Connect with us: * https://www.youtube.com/@develpreneur * https://facebook.com/Develpreneur * https://X.com/develpreneur * https://www.linkedin.com/company/develpreneur/
---
⏱ **Chapters**
00:00 Welcome & Episode Setup 01:05 Meet the Hosts 02:19 Good Thing / Bad Thing Stories 05:28 Why User Stories Matter 07:21 The User Story Format 08:29 Turning Stories into Requirements 10:05 Defining Edge Cases 11:07 User Stories and Test-Driven Development 13:20 What Makes a Good User Story (INVEST) 14:00 Talking to Business Users 16:20 Coders vs. Developers 18:26 MVP vs. Nice-to-Have Features 19:49 Common Mistakes with User Stories 21:06 How to Push Back on Vague Requests 23:11 Why Assessments Help 24:01 Developer Burnout & Missing Requirements 26:21 Using Visual Tools 27:08 Listener Feedback & Contact Info 28:42 Bonus: Agile, Tools & Real Examples 30:03 Rob’s Success Story with Good Stories 30:54 Michael’s Tool Recommendations 31:57 Final Thoughts 32:53 What’s Coming Next
#userstories #softwaredevelopment #agiledevelopment #buildingbetterdevelopers #podcast
Transcript Text
[Music] and I had a different place I could get it to. All right, we have pressed record. We are back. We're diving right in. I'm gonna dive right into this because we've been vamping for 30 minutes and I am ready to devamp after a fun day. So, we're gonna talk about user stories unveiled, a developer guide to capturing the full narrative. And it's back to its fun stuff because the first thing it said was that's a strong title. So, we're getting some chat GPT love again. So, let's see how this one goes. And let's just get start. Hello and welcome back. We are continuing this season where we're talking about we're building better developers. We are developing newer. We are going through a bunch of uh past topics. We're basically suggestions on how to be a better developer. This time with AI because we're going to go throw these same things out, the titles basically the topics out to AI, see what it says, see what it suggests, and talk our way through it. Now I happen to be before we get into all of this I guess there should be some introductions all around. I happen to be Rob Broadhead one of the founders of de developer also the founder of RB consulting where we are some people call a boutique consulting. What that means is essentially we actually care about you our customer. We sit down with you. We talk through your challenges, your travailes, figure out what your business is, and we use our experience, multiple decades of working in a lot of technology to help you sort of, you know, sip through your technology junk drawer, look at what's out there. you know, whether you're brand new and you have no idea where to get started, like where do I go other than a spreadsheet or whether you've been doing this for a while and you've got this technology sprawl that has, you know, goes back to DOSs or something like that and you've got 15 different applications that none of them want to talk to each other. Uh, which is always one of the key things. You don't want to have all these things that are working with your data. if you have to keep entering your data. So check us out anytime rb-sns.com and we'll be happy to sit down and talk to you. Just sort of like help you out and if we can turn into a partner on the long term, great. If not, we can always send you to somebody that can help you out and move you forward because we want you to be better businesses as well. Now, good thing, bad thing. This is the mother of all good thing, bad things right now. And which means I don't know what I'm going to do with the next episode because this one should I should be able to reuse this every time for like the next 10 weeks. I'm going to shorten this one because we don't have all day to talk through it. But essentially my son was leaving town, moving had a had we'll just say he had shrapnel hit his car caused a lot of damage. We have been back and forth a couple of times to help him out to be a part of this to work through all the insurance stuff to get the car eventually totaled. Now we're working on buying him a new car. So, lots of time in a car driving back and forth, eight hour trips each way basically. So, could be more fun. The good news is we've gotten to spend a lot of quality time with said child. So, it's actually been pretty cool. Been able to like it's been sort of an excuse to have some extra vacation time, some chill time, and we've gotten to really explore the place that he's at. Uh, so I don't think I'll name it, but I will just say it's a really cool city. Sometime in the future, we may drop that when we're not sitting here. basically not as cool as where I am because I'm here and he's there is Michael. Go ahead and introduce yourself. >> Hey everyone, my name is Michael Malashsh. I'm one of the co-founders of developer building better developers. I'm also the owner of Envision QA where we help startups and growing companies build better software faster with fewer problems. We also offer services that cover software development, quality assurance, test automation, and release support. Companies come to us when they want to avoid delays, reduce bugs, and launch with confidence. Whether you're building your first MVP or scaling a live product, we make sure your software is reliable, efficient, and ready for growth. You can learn more at envisionqa.com. Good thing, bad things? Well, I guess the bad thing is like you said, it is hot here. We are under this heat dome and a combination of that yesterday. went out to dinner with the kids and we're sitting down at the restaurant after sitting through traffic and the power goes out like right after we order our drinks, lose power. It is almost a citywide blackout. I mean, we're talking almost a 10 mile radius, no power. We leave, go over to the next restaurant. It takes another 20 minutes to get over there. The cars had time to get hot again. So, we get over there, we're miserable, we eat, and it was just a miserable experience. Uh, I think I end up getting heat exhaustion on top of all of it, which made for some fun times. Good thing though was our daughter, who we're having dinner with, had gotten some good news, and we officially got the news today that she has been promoted to a new job with a huge salary bump, and she is really looking forward to moving up to this position. We weren't sure when they moved to Jackson um a while back if she was going to, you know, find something she liked. Uh she got into something uh and she's apparently able to move up and is loving it. So kudos. That's a good win there. So, uh loving it. All right, speaking of love it, we are back to a loving chat GPT. They absolutely loved our suggestion. So he comes back right away and it says that is a strong title. What is that title? Title is user stories unveiled a developer guide to capturing the full narrative. It says and it opens the door to a lot of impactful real world discussion. Here's a suggested episode breakdown with topics and talking points to keep things focused but valuable. It gives us uh gives us six points again. Uh it starts with episode structure user stories unveiled. And I think that's basically looks like that's a sort of like overall piece. So let's dive into the first um the first segment essentially why user stories matter. Uh gives me a couple bullet points and some talking points. So bullet points the difference between requirements and user stories. Good user stories prevent feature creep and rework. Stories is a bridge between developers product and users talking points. as a in brackets user I want brackets feature so that bracket benefit why this format works the narrative behind user behavior not just functionality I think I want to get I'm going to do like start with that first one so as a blank I want blank so that blank and then sort of switch to the difference between requirements and user stories so really the user story you can think of the story is the as say blank. I want blank. So that blank as a um you know as a customer I want to be able to view my order status so that I can track my order status so I can see where it's at or so that I can uh maybe and this is where you get some fun stuff. So let's look at this one is it could be so that I could I can cancel or reschedule my order. In that simple story, there's actually multiple requirements. And this is where the user story is the the user point of view. Essentially, it's like this is it's really it comes down to it's the why. It's why do I want to do what is it I'm doing and why do I want to do it, which is sort of the I'm me. So, as a blank that is who the actor is, I want blank which is basically their why or their goal. And then within that is so that blank because that sort of gives us the coloring. It's like it may be you know I want my account balance. Well I want my account balance so that I can you withdraw money or deposit money. Those kinds of things are going to give you additional points that are going to become your requirements. So in like something as simple as that if they want to be able to see their account then that means you have a requirement of one tracking an account balance of some sort for a person. you need to be able to display that in some way, form or fashion. And if they want to be able to withdraw or deposit, then that's two requirements right there. Then they have to be able to withdraw money, which means they're going to have to pull some out, put it wherever they're going to have to do it. Those requirements probably around that. And then within that, obviously, it's got to update their balance. And uh vice versa, if they want to deposit, then there has to be a way for them to put money into the system for it to recognize what that money is, for that to apply it to their balance and fund things like that. And that doesn't even begin to get into other requirements which is why we have some of these conver conversations which is really where the user stories do start to come into play because it's things where within the user story you're going to find out that oh uh for example let's say it is an ATM you deposit money into the ATM machine the money doesn't actually get to the bank until the end of the day when they empty the ATM machine probably or something like that or if you're like one of my horror stories in the past two weeks later when they can finally get through the snow to the ATM machine to get the money out and verify. So you have all of these other side actors and side things that come up that really help you flush out the requirements. That is where the user stories become very valuable because what you do is you get people talking about the process and it gives you an opportunity gives you a straw man essentially to ask questions about the process and therefore you can start like you know sort of sucking out some of the requirements and as you get further into into this and you've done it they're going to be things that are always going to be questions things like you know oh well all right if you have an account how do you register account how do you log into the account how do you change your password if you can log into account or how do you update or is it multiffactor authentication or or or or there's a lot of questions that come in there. So, I'm going to stop here and I'm going to throw all those questions at Michael and be where you want to go with this particular one. >> So, I'm going to kind of take what you just laid out with user stories and all the examples and I'm going to kind of take where we can go with these user stories. So, user stories like Rob mentioned, you know, you have the take money out of the ATM, put money in the bank. User stories are your requirements from the user perspective. Once you get those requirements or once we get these user stories defined, what happens after the fact is as you flush them out, you get all the if then cases. And if you run into situations where you have an A or a B or anything where it's a a virgin where you could potentially have multiple pass, you need to then find out, okay, if you're checking money out of the ATM, okay, uh you go try to take out $20, the first if is does the ATM have money? You know, is there money there to give you the 20 bucks? If not, it would throw an error. If it does, it would return you your money. So those are types of user stories that help you define requirements. What's to me the beauty of user stories is when we get to coding. This is where the whole test-driven development comes in because you take these user stories and you essentially literally these are your tests. You start testing from the user's perspective and then you build the code along the lines of the stories. For instance, if you need security for your application, you need a login page. So you're going to say, okay, user needs to log in. So you're going to then write, okay, I need a user. What is a user in my system? So you ask yourself the questions. You start breaking down the problem based on the user story to then write your code. And you essentially have the test. You write the tests to test your code. The beauty of this is if you're using things like cucumber testng it they they force you to define the user stories to write the tests especially cucumber. Cucumber is very powerful in this nature where it uses business speak essentially to define the story and then you write feature to test your um to test the story to test your code based on the user's perspective. There are other you know test environments out there with different ways of doing this but essentially at the end of the day that is the point of how you can use test-driven development. So you need things like user stories. You need the scenarios on how the application is going to work. You know what is the why and how am I going to use the application to get there? How am I going to test it? >> I'm going to go right into the next one because I think this will sort of this is partially some thoughts I had but you you brought up some good points and some things I want to talk about on users first. I don't think we've actually talked about with task but let's step into theirs first. So their next section is what makes a good user story and this is the fun part of doing this kind of research in AI. So it it mentions the invest criteria independent negotiable valuable estimable small testable breaking up epics versus slicing vertical features. Avoiding technical stories that have no user value. Talking points examples of vague versus strong user stories where acceptance criteria adds clarity and testability. Now, first I want to go back to that first thing. I love when I come across one of these acronyms that somebody's put together somewhere and it's like, "Oh, that's actually pretty useful." And sometimes I've heard of them and I actually have no idea what they meant because I've just heard them so many times and they just you get the sense of it. And uh sometimes they're very like this. It's like I don't know that I've heard this one before, but it's like that's a pretty good, you know, series of, you know, rule of thumb kind of items. Now I do want to take this as a whole um and talk about what makes a good user story and it's I actually want to step back a little bit and talking about what you know Michael's talked about it from a testing point of view. >> I think the the thing that user stories give us is a way it's a it's a common language to actually talk to a business user. If you are somebody that can sit down and just talk business and not care about requirements but just like talk through stuff, then you you really are just a walking user story essentially. You can say, "Well, this person needs to do that and this is how they do it and they need to do this and this is their goal and things like that." But what user stories give us is they give us something that's a little more structured. So it's to make sure that when we're essentially when we're interviewing a customer, when we're gathering requirements that we have we have like a a goal in sight. It would be like building out we go go through a you know you're writing a book, let's say, and say it's you know Game of Thrones or something like that where there's all these characters and you can do all of this character development and all this different stuff without ever putting the story together. And that's okay if you know how to bring all that stuff together. But that's what the user stories become. They are not only a way for us to keep focused on what is it, what are the problems we're actually solving, but also it's a little bit of the glue to take all of these things that we're building and make sure that they do work together. Uh that means that like the technical stories that have no user value literally are usually they they really tend to bubble to top very quickly because they're not going to have an actor most likely or the actor may be the system itself in which case if the actor is the system. Now, if it's a back-end process that kicks something out to a user, okay, then there is some actor in there. There's somebody there's a receiver of that information, but there's a lot of times you get into stuff and Michael and I have had this conversations before and I know that he's heard me say it where I'm like, it doesn't matter. Nobody ever sees it. Those kinds of things don't really care. It's like those are implementation details and as long as it works based on the why of the story, then that is what you need to worry about. The rest of the stuff is bluff basically. It really doesn't matter. It's it does get back down to can you solve the problem and give them you know give the actor what it is that they expect. I went a little bit big and also went back a little bit. So now what are your thoughts on this one because there's there's plenty of focusing to go with this. >> Yeah, I mean there are many ways to go with this. What the interesting thing though you you mentioned there and we have talked about this you know where if it doesn't match the why we don't need to worry about it. But there are times though, even when you get to the implementation, especially if you're trying to focus on test riven development, that you need to understand enough of the why to be able to break it down to the minutia, the stuff behind the scenes. You need to to at least be able to explain how your systems work. So from a user stories perspective, you're at the customer level. You're doing the front-end level. So getting into some of the other stuff is going deeper beyond user stories, but it is beneficial for testing. The other things to think about with this though is, you know, kind of peeling back the onion is especially when you're talking to the customers and talking about new features. We've run into this a lot where they want something, they explain it, they give us their why, and then 3 months into the project they're like, "Well, we don't need that." And then you're like, well, crap. You know, how much time did we waste on this uh feature, even though it was laid out um in the user stories, it ended up not being something that was really required. So, one interesting thing to think about with your user stories is once you have them laid out, still go back and review them again and make sure that every story is truly a requirement or a need, not a want or a nice to have. Because if you're fighting to get your MVP done first, always go with what is what m what is a must have? What do we need to have for this delivery? Those are the user stories you need to focus on first. Anything outside of that needs to be put in the nice to have or future enhancements. Still make note of it, but don't spend so much time on that now. Focus on the MVP. That is we've talked about that before and I do think that is a a critical thing to have is especially when you're actually honestly if you're doing an MVP but I think honestly any software project uh and I have been on some true green field projects and that where there is it is still incredibly valued to have a we're not going to do that right now kind of section it is always the future version 2.0 go whatever the heck you want to call it. And it may be that it is something that you actually never going to get to cuz a lot of times that's people's worry. It's like, well, if you put it there, then we're never going to get it done. Maybe maybe it doesn't really maybe there's no need for it to ever be done. However, that may be that you're going to get to the point somewhere down the road there will be a version 2.0 and that is your your backlog basically to build out your version 2.0. And sometimes uh like Michael said I have been in situations where the customers had all these like we have to do this and sometimes there's a sizable chunk of of implementation of technology and the solution and then they realize oh we really don't need that and we can pivot and we can start pulling some of that stuff back in. So you want to have that placeholder. You want to have a bucket to throw those things and it also gives you permission to throw something there to say we're not going to tackle this now. we're going to deal with in another point so it doesn't keep sucking up your your time and things of that nature. Now, let's move along one more because we're as always we can only get through about three of their points because they are pretty good discussion points. Common pitfalls developers see uh bullet points. Just tell me what to build. The anti-attern getting handed halfbaked stories or solutioned tickets. How to push back constructively. Talking points, questions devs can ask to uncover the real user need. Partnering with PMs, BAS, that's project managers and business analysts to improve story quality. Just tell me what to build antiattern. Um, this one I I'm going to tackle on this because I this is part of why developer exists. There is a difference to me and I think I've talked about this before but there's a difference between programmers or coders and developers. Developers are solving problems. Coders are just writing code. And there is if you don't think there's a difference then you're probably in the wrong category. Um and keep listening because you will learn and you will advance your career because coders are going to be ris basically are already basically being replaced by AI. developers are going to continue to basically they're going to drive AI and they're going to drive things like that. So the the just tell me what to build misses so many points. And if you're either side of that, so if you're a developer and you get to that point and you're like just tell me what I need to build, then you've given up. You're not going to be successful. And if you are a customer and hear this, you need to give up because you're not going to get there because they're not building. They're just trying to regurgitate what you've said. So you said, you know, there is a difference between like the ATM person. So person needs to, you know, see their account balance, withdraw money. Keep it very simple. Well, there's a lot more to it than that. So if you just give me something that says I can see an account balance and I can click a button and it withdraws money, that does not cover so many other things that are out there. And that is the thing is you need to have that inquisitive mind and you're going to get this from the other side of it. You're going to have customers that are like, I just go build it. It's like we've had that example where people are say, you know, I want you to build eBay but for pet food and I need it done for $50 by next week. You know, stuff like that where it's like, okay, you don't understand at all what you're asking or even what you're looking for. And you can just walk away and say, "Okay, you're not you're not worthy of my time." Or you sit down with the customer and say, "Okay, let's talk about your vision. What does this really mean?" And start really pushing back on some of that. So if they just say, "Well, just do this." That's when you have to walk them through and say, "Okay, well, let's say we do this, but then what about this situation and what about that? And why are you doing this? Do you really need to do that? What if we do this instead?" And you don't have to wear them out with questions. You don't have to be the 2-year-old saying, "Are we there yet? Are we there yet? Are we there yet?" But what you do want to do is you want to make sure that there's a conversation and it's even in that conversation, you're keeping that goal of the why. What are we doing it? Why are we doing it? Who are we going to serve? And all is said and done. And if you can start from there, then that usually gives you at least those north stars to keep as part of your conversation as you go forward. Thoughts on that? >> Yeah. So that last part you said is kind of interesting and I don't want to deviate too much from the user stories, but this is where those software assessments come in handy and you sit down with the customer and you walk through their current systems. You figure out how their business works, what their products do, what they want, and then you can sit down with them and flush out the user stories because you'll have a better understanding of what it is that they their business is and understand that. Okay, now these are the stories that you really need or at least you can ask the right questions at that point. I love your comment though there where you know just tell me what to build. There are times as developers, not just coders, but as developers, where we reach a point where we are so frustrated with the lack of requirements or the lack of features or lack of user stories where we literally are tired of look basically doing the PMs or the PO's jobs and in larger organizations this is a huge problem and developer burnout is notorious. However, in smaller companies, you have to understand that there may not be that level of project manager, project owner, business owner. So, you will have to step up at times and step into those roles to get these user stories that you need to do the work to make sure that the work you're doing is answering that why and is sufficient for getting the product across the line or a deliverable. You just have to be careful though that you don't always jump to the conclusion of well just tell me what to build. Sometimes you have to because sometimes if you get into situations, especially as a contractor, and you're on a time budget, uh, hourly budget for getting things done and the customer is arguing with you or basically not giving you what you need, you either need to say, "Okay, then we need to put a pause on this till we flush this out." or what can you get from the customer enough to get enough of the user story to keep the work moving forward? And that sometimes is the deal is you have to pull enough out of them to get that next step. And sometimes they because I know developers because we whine a lot. We're primadonas sometimes is that we will mention, hey, we're burned out. we're having trouble because actually it's not that it's it's more common for us to work 100 hours and not be burned out than vice versa. At least that's the um the story we tell. But our customers will get burned out too. They will get to a point where they're like, I've I've answered this question too many times or too many ways or things like that. So sometimes we've got to figure out how to either soften the blow or help them through it and say, "Okay, we know this. Here's our foundation. All we need is just this next step. All we need is like this little thing is like what does this look like?" And this is where clickable demos and things like that are very helpful. This is awesome. I hate to be self- serving, but this is where the, you know, the assessments, those kinds of things are very valuable because you get to start from here's where you are, here's what you've got, and here's some of the things that can help you. And it allows a uh an earlier ROI kind of vision at least because maybe you're not going to be able to get that ROI immediately, but you're going to be able to see it. you're going to be able to see that, oh, we're spending, you know, somebody's spending 5 hours a day on these reports. Now, we're going to automate it and it's going to take five minutes a day. And so, now that person is freed up to go do other work. Those kinds of things. Having that almost carrot and stick approach, I think, will really help your conversations with your customers. What will also help is if you send us an email at [email protected] because we are towards the end of yet another episode and we'd love to hear from you. What do you like? What don't you like? Where would you like this to go? We are not done with this season by any stretch. We've still got quite a few more. However, we would have no problem throwing a couple interviews in. I know I keep teasing that, but we're going to get there at some point. We just uh you know, we're just having too much fun doing this actually right now. And uh if you want to get reach out to us at developer.com. If you want to go to Facebook, we have a developer Facebook. We are out on xdevelopure. Wherever you listen to podcast, you can leave us a review. Leave us a thumbs up, thumbs down, five stars, 18 bananas, whatever the review approach is. Love to hear from you. Good or bad. We have the developer channel out on YouTube. Check that out. If you're listening to us, you can actually see us. We're not as ugly as some may think. pretty close though. And then if you if you're tired of seeing our face, you can always go back to the audio version and just listen to this. And you can be like me and you can cheat and you can kick it up to like 1.25 m speed or faster. And I will just say the if you crank it up all the way, then the theme music goes really really quick. It's like, wow, that guy is quite the drummer. Um, and then the rest of us, we talk really, really high probably the rest of the time. That being said, we need to wrap this one up. So go out there and have yourself a great day, a great week, and we will talk to you next time. Uh let's see. Bonus material. Let me go through points four, five, and six really quick, and then we'll see what we want. User stories and agile process. Stories as a currency of sprints, estimating stories, story points, t-shirt sizing, refinement, backlog, grooming, best practices. I'm going to skip the talking points. uh five tools and techniques using tools like Jira, Trello, Azure DevOps, but focusing on conversation not tickets documenting user goals and flows with user story maps. Integrating personas into story design. Uh six, user story smells as a system. Uh multiple user types in one story. Vague success criteria. And then oh there's a seventh. Real world experiences. share a bad story that led to wasted time or confusion or a success story that was uh well written user story led to a smooth release or a delighted user. I will just first I'm going to just do this for pass it to Michael. I have been on projects that have had very wellwritten thorough user stories. They were a long time ago was the first time I had one of those happen and I was amazed at how much that helped us build a very complex system and get it done and stay pretty much on track. And this is I don't think we were using agile at that time. I think there's a waterfall kind of approach. We had really solid stories that had written from the start and we were able to just like start you line them up and knock them down. You had a whole series of requirements for any given story. as a developer, you could take that story. We didn't have a huge team, but it was easy to just take a story, walk through the whole thing. So, it was also very um rewarding as a developer to start with nothing and then get done and to be able to see that story and walk through and it had all of the exceptions and had all of the validations and all of the things that make the story real and successful. So, I do believe they're out there. It does take work. It does take intention and you can't shortcut it. If you start shortcutting it, then you're potentially going to lose some stuff. Where do you want to go with this one? >> So, I'll touch on the tools. So, I I know they touched on like Jira, um Trello, and things like that. There are other things too which uh if it it depends on the type of person you are. So, like if you're visual, look at tools like draw.io, Vizio, Miro, uh, Figma. Use additional visual tools to try to prototype and help you build those user stories for what you need. I did not expect you to stop that quickly. I was for a second and let you talk and you did not. So, I got busted on that one. Thanks a lot. You're fired. Except he does all the work. So if he's fired, if we don't have another episode, you know that he was actually fired. If we do, you know that he still has a job. The bad news is we don't get paid, so it doesn't really matter. >> All right, good point. I think I I don't want to like blow through that because it was very quick but your tool that you use is I think very very important for these things particularly for uh user stories and particularly for communicating with your development team. So definitely like there's a lot of stuff out there. Play around with a little bit. Find the stuff that speaks to you, your team, particularly if you have um this is it's a challenge because even if you move to a new sprint team, if you're doing an agile approach and you've been doing sprints for a while and now you move to a new project, new team, you may have different tools that work better. You may also have just different ways that you use the tools that you have. So be aware of those, work with those. And as always, let us know how it goes. We would love to hear your feedback. Uh I've already preached all of that kind of stuff. So I'm going to let you guys go. We're going to come back. We are going to continue the with AI approach to this because we're really getting some good stuff. We've been we've been having a great time with this. We've learned quite a bit. Uh it's added a lot of uh a lot of extra food for thought for some of our uh some of our ideas and some of our points and our past topics. I'm not even going to tease the next one. Actually, if you go back two seasons, you can probably see exactly. You can watch us walking through doing these topics again. But we will be back. We will carry on as we march towards uh I don't know where we're at. As we're marching towards episode 1,000. I don't know why, but that's like one of those things. It's like way way back. It seemed like that would never happened. And now it's like it feels like it's within reach even though it's probably like a year or two out, but hey, let me drink >> 900. >> So there you go. 900. That's like that might as well be. You can round up to a thousand at that point. So maybe we'll do the thousand episode celebration at episode 900 and just cheat like that. No, we won't. All right, go out there, have yourself a great one. We're going to get out of here. Come back. Talk to you later. [Music]
Transcript Segments
[Music]
and I had a different place I could get
it to. All right, we have pressed
record. We are back.
We're diving right in. I'm gonna dive
right into this because we've been
vamping for 30 minutes and I am ready to
devamp after a fun day. So, we're gonna
talk about
user stories unveiled, a developer guide
to capturing the full narrative. And
it's back to its fun stuff because the
first thing it said was that's a strong
title. So, we're getting some chat GPT
love again. So, let's see how this one
goes. And let's just get
start. Hello and welcome back. We are
continuing this season where we're
talking about we're building better
developers. We are developing newer. We
are going through a bunch of uh past
topics. We're basically suggestions on
how to be a better developer. This time
with AI because we're going to go throw
these same things out, the titles
basically the topics out to AI, see what
it says, see what it suggests, and talk
our way through it.
Now I happen to be before we get into
all of this I guess there should be some
introductions all around. I happen to be
Rob Broadhead one of the founders of de
developer also the founder of RB
consulting where we are some people call
a boutique consulting. What that means
is essentially we actually care about
you our customer. We sit down with you.
We talk through your challenges, your
travailes, figure out what your business
is, and we use our experience, multiple
decades of working in a lot of
technology to help you sort of, you
know, sip through your technology junk
drawer, look at what's out there. you
know, whether you're brand new and you
have no idea where to get started, like
where do I go other than a spreadsheet
or whether you've been doing this for a
while and you've got this technology
sprawl that has, you know, goes back to
DOSs or something like that and you've
got 15 different applications that none
of them want to talk to each other. Uh,
which is always one of the key things.
You don't want to have all these things
that are working with your data. if you
have to keep entering your data. So
check us out anytime rb-sns.com
and we'll be happy to sit down and talk
to you. Just sort of like help you out
and if we can turn into a partner on the
long term, great. If not, we can always
send you to somebody that can help you
out and move you forward because we want
you to be better businesses as well.
Now, good thing, bad thing. This is the
mother of all good thing, bad things
right now. And which means I don't know
what I'm going to do with the next
episode because this one should I should
be able to reuse this every time for
like the next 10 weeks. I'm going to
shorten this one because we don't have
all day to talk through it. But
essentially my son was leaving town,
moving had a had we'll just say he had
shrapnel hit his car caused a lot of
damage. We have been back and forth a
couple of times to help him out to be a
part of this to work through all the
insurance stuff to get the car
eventually totaled. Now we're working on
buying him a new car. So, lots of time
in a car driving back and forth, eight
hour trips each way basically. So, could
be more fun. The good news is we've
gotten to spend a lot of quality time
with said child. So, it's actually been
pretty cool. Been able to like it's been
sort of an excuse to have some extra
vacation time, some chill time, and
we've gotten to really explore the place
that he's at. Uh, so I don't think I'll
name it, but I will just say it's a
really cool city. Sometime in the
future, we may drop that when we're not
sitting here. basically
not as cool as where I am because I'm
here and he's there is Michael. Go ahead
and introduce yourself.
>> Hey everyone, my name is Michael
Malashsh. I'm one of the co-founders of
developer building better developers.
I'm also the owner of Envision QA where
we help startups and growing companies
build better software faster with fewer
problems. We also offer services that
cover software development, quality
assurance, test automation, and release
support. Companies come to us when they
want to avoid delays, reduce bugs, and
launch with confidence. Whether you're
building your first MVP or scaling a
live product, we make sure your software
is reliable, efficient, and ready for
growth. You can learn more at
envisionqa.com.
Good thing, bad things? Well, I guess
the bad thing is like you said, it is
hot here. We are under this heat dome
and a combination of that yesterday.
went out to dinner with the kids and
we're sitting down at the restaurant
after sitting through traffic and the
power goes out like right after we order
our drinks, lose power. It is almost a
citywide blackout. I mean, we're talking
almost a 10 mile radius, no power. We
leave, go over to the next restaurant.
It takes another 20 minutes to get over
there. The cars had time to get hot
again. So, we get over there, we're
miserable, we eat, and it was just a
miserable experience. Uh, I think I end
up getting heat exhaustion on top of all
of it, which made for some fun times.
Good thing though was our daughter, who
we're having dinner with, had gotten
some good news, and we officially got
the news today that she has been
promoted to a new job with a huge salary
bump, and she is really looking forward
to moving up to this position. We
weren't sure when they moved to Jackson
um a while back if she was going to, you
know, find something she liked. Uh she
got into something uh and she's
apparently able to move up and is loving
it. So kudos. That's a good win there.
So, uh loving it.
All right, speaking of love it, we are
back to a loving chat GPT. They
absolutely loved our suggestion. So he
comes back right away and it says that
is a strong title. What is that title?
Title is user stories unveiled a
developer guide to capturing the full
narrative. It says and it opens the door
to a lot of impactful real world
discussion. Here's a suggested episode
breakdown with topics and talking points
to keep things focused but valuable. It
gives us uh gives us six points again.
Uh it starts with episode structure user
stories unveiled. And I think that's
basically looks like that's a sort of
like overall piece. So let's dive into
the first um the first segment
essentially why user stories matter. Uh
gives me a couple bullet points and some
talking points. So bullet points the
difference between requirements and user
stories. Good user stories prevent
feature creep and rework. Stories is a
bridge between developers product and
users talking points. as a in brackets
user I want brackets feature so that
bracket benefit why this format works
the narrative behind user behavior not
just functionality
I think I want to get I'm going to do
like start with that first one so as a
blank I want blank so that blank and
then sort of switch to the difference
between requirements and user stories
so really
the user story you can think of the
story is the as say blank. I want blank.
So that blank as a um you know as a
customer I want to be able to view my
order status so that I can track my
order status so I can see where it's at
or so that I can uh maybe and this is
where you get some fun stuff. So let's
look at this one is it could be so that
I could I can cancel or reschedule my
order.
In that simple story, there's actually
multiple requirements. And this is where
the user story is the
the user point of view. Essentially,
it's like this is it's really it comes
down to it's the why. It's why do I want
to do what is it I'm doing and why do I
want to do it, which is sort of the I'm
me. So, as a blank that is who the actor
is, I want blank which is basically
their why or their goal. And then within
that is so that blank because that sort
of gives us the coloring. It's like it
may be you know I want my account
balance. Well I want my account balance
so that I can you withdraw money or
deposit money. Those kinds of things are
going to give you additional points that
are going to become your requirements.
So in like something as simple as that
if they want to be able to see their
account then that means you have a
requirement of one tracking an account
balance of some sort for a person. you
need to be able to display that in some
way, form or fashion. And if they want
to be able to withdraw or deposit, then
that's two requirements right there.
Then they have to be able to withdraw
money, which means they're going to have
to pull some out, put it wherever
they're going to have to do it. Those
requirements probably around that. And
then within that, obviously, it's got to
update their balance. And uh vice versa,
if they want to deposit, then there has
to be a way for them to put money into
the system for it to recognize what that
money is, for that to apply it to their
balance and fund things like that. And
that doesn't even begin to get into
other requirements which is why we have
some of these conver conversations which
is really where the user stories do
start to come into play because it's
things where within the user story
you're going to find out that oh uh for
example let's say it is an ATM you
deposit money into the ATM machine the
money doesn't actually get to the bank
until the end of the day when they empty
the ATM machine probably or something
like that or if you're like one of my
horror stories in the past two weeks
later when they can finally get through
the snow to the ATM machine to get the
money out and verify.
So you have all of these other
side actors and side things that come up
that really help you flush out the
requirements. That is where the user
stories become very valuable because
what you do is you get people talking
about the process and it gives you an
opportunity gives you a straw man
essentially to ask questions about the
process and therefore you can start like
you know sort of sucking out some of the
requirements and as you get further into
into this and you've done it they're
going to be things that are always going
to be questions things like you know oh
well all right if you have an account
how do you register account how do you
log into the account how do you change
your password if you can log into
account or how do you update or is it
multiffactor authentication or or or or
there's a lot of questions that come in
there. So, I'm going to stop here and
I'm going to throw all those questions
at Michael and be where you want to go
with this particular one.
>> So, I'm going to kind of take what you
just laid out with user stories and all
the examples and I'm going to kind of
take where we can go with these user
stories. So, user stories like Rob
mentioned, you know, you have the take
money out of the ATM, put money in the
bank. User stories are your requirements
from the user perspective.
Once you get those requirements or once
we get these user stories defined, what
happens after the fact is as you flush
them out, you get all the if then cases.
And if you run into situations where you
have an A or a B or anything where it's
a
a virgin where you could potentially
have multiple pass, you need to then
find out, okay, if you're checking money
out of the ATM, okay, uh you go try to
take out $20, the first if is does the
ATM have money? You know, is there money
there to give you the 20 bucks? If not,
it would throw an error. If it does, it
would return you your money. So those
are types of user stories that help you
define requirements.
What's to me the beauty of user stories
is when we get to coding. This is where
the whole test-driven development comes
in because you take these user stories
and you essentially literally these are
your tests. You start testing from the
user's perspective and then you build
the code along the lines of the stories.
For instance, if you need security for
your application, you need a login page.
So you're going to say, okay, user needs
to log in. So you're going to then
write, okay, I need a user. What is a
user in my system? So you ask yourself
the questions. You start breaking down
the problem based on the user story to
then write your code. And you
essentially have the test. You write the
tests to test your code.
The beauty of this is if you're using
things like cucumber testng it they they
force you to define the user stories to
write the tests especially cucumber.
Cucumber is very powerful in this nature
where it uses business speak essentially
to define the story and then you write
feature to test your um to test the
story to test your code based on the
user's perspective. There are other you
know test environments out there with
different ways of doing this but
essentially at the end of the day that
is the point of how you can use
test-driven development. So you need
things like user stories. You need
the scenarios on how the application is
going to work. You know what is the why
and how am I going to use the
application to get there? How am I going
to test it?
>> I'm going to go right into the next one
because I think this will sort of this
is partially some thoughts I had but you
you brought up some good points and some
things I want to talk about on users
first. I don't think we've actually
talked about with task but let's step
into theirs first. So their next section
is what makes a good user story and this
is the fun part of doing this kind of
research in AI. So it it mentions the
invest criteria independent negotiable
valuable estimable small testable
breaking up epics versus slicing
vertical features. Avoiding technical
stories that have no user value. Talking
points examples of vague versus strong
user stories where acceptance criteria
adds clarity and testability. Now, first
I want to go back to that first thing. I
love when I come across one of these
acronyms that somebody's put together
somewhere and it's like, "Oh, that's
actually pretty useful." And sometimes
I've heard of them and I actually have
no idea what they meant because I've
just heard them so many times and they
just you get the sense of it. And uh
sometimes they're very like this. It's
like I don't know that I've heard this
one before, but it's like that's a
pretty good, you know, series of, you
know, rule of thumb kind of items. Now I
do want to take this as a whole
um and talk about what makes a good user
story and it's I actually want to step
back a little bit and talking about what
you know Michael's talked about it from
a testing point of view.
>> I think the the thing that user stories
give us is a way it's a it's a common
language to actually talk to a business
user. If you are somebody that can sit
down and just talk business and not care
about requirements but just like talk
through stuff, then you you really are
just a walking user story essentially.
You can say, "Well, this person needs to
do that and this is how they do it and
they need to do this and this is their
goal and things like that." But what
user stories give us is they give us
something that's a little more
structured. So it's to make sure that
when we're essentially when we're
interviewing a customer, when we're
gathering requirements that we have we
have like a a goal in sight. It would be
like building out
we go go through a you know you're
writing a book, let's say, and say it's
you know Game of Thrones or something
like that where there's all these
characters and you can do all of this
character development and all this
different stuff without ever putting the
story together. And that's okay if you
know how to bring all that stuff
together. But that's what the user
stories become. They are not only a way
for us to keep focused on what is it,
what are the problems we're actually
solving, but also it's a little bit of
the glue to take all of these things
that we're building and make sure that
they do work together.
Uh that means that like the technical
stories that have no user value
literally are usually they they really
tend to bubble to top very quickly
because they're not going to have an
actor most likely or the actor may be
the system itself in which case if the
actor is the system. Now, if it's a
back-end process that kicks something
out to a user, okay, then there is some
actor in there. There's somebody there's
a receiver of that information, but
there's a lot of times you get into
stuff and Michael and I have had this
conversations before and I know that
he's heard me say it where I'm like, it
doesn't matter. Nobody ever sees it.
Those kinds of things don't really care.
It's like those are implementation
details and as long as it works based on
the why of the story, then that is what
you need to worry about. The rest of the
stuff is bluff basically. It really
doesn't matter. It's it does get back
down to can you solve the problem and
give them you know give the actor what
it is that they expect. I went a little
bit big and also went back a little bit.
So now what are your thoughts on this
one because there's there's plenty of
focusing to go with this.
>> Yeah, I mean there are many ways to go
with this. What the interesting thing
though you you mentioned there and we
have talked about this you know where if
it doesn't match the why we don't need
to worry about it. But there are times
though, even when you get to the
implementation, especially if you're
trying to focus on test riven
development, that you need to understand
enough of the why to be able to break it
down to the minutia, the stuff behind
the scenes. You need to to at least be
able to explain
how your systems work. So from a user
stories perspective, you're at the
customer level. You're doing the
front-end level. So getting into some of
the other stuff is going deeper beyond
user stories, but it is beneficial for
testing. The other things to think about
with this though is, you know, kind of
peeling back the onion is
especially when you're talking to the
customers and talking about new
features. We've run into this a lot
where they want something, they explain
it, they give us their why, and then 3
months into the project they're like,
"Well, we don't need that."
And then you're like, well, crap. You
know, how much time did we waste on this
uh feature, even though it was laid out
um in the user stories, it ended up not
being something that was really
required. So, one interesting thing to
think about with your user stories
is once you have them laid out, still go
back and review them again and make sure
that every story is truly a requirement
or a need, not a want or a nice to have.
Because if you're fighting to get your
MVP done first, always go with what is
what m what is a must have? What do we
need to have for this delivery? Those
are the user stories you need to focus
on first. Anything outside of that needs
to be put in the nice to have or future
enhancements. Still make note of it, but
don't spend so much time on that now.
Focus on the MVP.
That is we've talked about that before
and I do think that is a a critical
thing to have is especially when you're
actually honestly if you're doing an MVP
but I think honestly any software
project uh and I have been on some true
green field projects and that where
there is it is still incredibly valued
to have a we're not going to do that
right now kind of section it is always
the future version 2.0 go whatever the
heck you want to call it. And it may be
that it is something that you actually
never going to get to cuz a lot of times
that's people's worry. It's like, well,
if you put it there, then we're never
going to get it done. Maybe maybe it
doesn't really maybe there's no need for
it to ever be done. However,
that may be that you're going to get to
the point somewhere down the road there
will be a version 2.0 and that is your
your backlog basically to build out your
version 2.0. And sometimes uh like
Michael said I have been in situations
where the customers had all these like
we have to do this and sometimes there's
a sizable chunk of of implementation of
technology and the solution and then
they realize oh we really don't need
that and we can pivot and we can start
pulling some of that stuff back in. So
you want to have that placeholder. You
want to have a bucket to throw those
things and it also gives you permission
to throw something there to say we're
not going to tackle this now. we're
going to deal with in another point so
it doesn't keep sucking up your your
time and things of that nature. Now,
let's move along one more because we're
as always we can only get through about
three of their points because they are
pretty good discussion points. Common
pitfalls developers see uh bullet
points. Just tell me what to build. The
anti-attern getting handed halfbaked
stories or solutioned tickets. How to
push back constructively. Talking
points, questions devs can ask to
uncover the real user need. Partnering
with PMs, BAS, that's project managers
and business analysts to improve story
quality.
Just tell me what to build antiattern.
Um, this one I I'm going to tackle on
this because I this is part of why
developer exists. There is a difference
to me and I think I've talked about this
before but there's a difference between
programmers or coders and developers.
Developers are solving problems. Coders
are just writing code. And there is if
you don't think there's a difference
then you're probably in the wrong
category. Um and keep listening because
you will learn and you will advance your
career because coders are going to be
ris basically are already basically
being replaced by AI. developers are
going to continue to basically they're
going to drive AI and they're going to
drive things like that. So
the the just tell me what to build
misses so many points. And if you're
either side of that, so if you're a
developer and you get to that point and
you're like just tell me what I need to
build, then you've given up. You're not
going to be successful. And if you are a
customer and hear this, you need to give
up because you're not going to get there
because they're not building. They're
just trying to regurgitate
what you've said. So you said, you know,
there is a difference between like the
ATM person. So person needs to, you
know, see their account balance,
withdraw money. Keep it very simple.
Well, there's a lot more to it than
that. So if you just give me something
that says I can see an account balance
and I can click a button and it
withdraws money, that does not cover so
many other things that are out there.
And that is the thing is you need to
have that inquisitive mind and you're
going to get this from the other side of
it. You're going to have customers that
are like, I just go build it. It's like
we've had that example where people are
say, you know, I want you to build eBay
but for pet food and I need it done for
$50 by next week. You know, stuff like
that where it's like, okay, you don't
understand at all what you're asking or
even what you're looking for. And you
can just walk away and say, "Okay,
you're not you're not worthy of my
time." Or you sit down with the customer
and say, "Okay,
let's talk about your vision. What does
this really mean?" And start really
pushing back on some of that. So if they
just say, "Well, just do this." That's
when you have to walk them through and
say, "Okay, well, let's say we do this,
but then what about this situation and
what about that? And why are you doing
this? Do you really need to do that?
What if we do this instead?" And you
don't have to wear them out with
questions. You don't have to be the
2-year-old saying, "Are we there yet?
Are we there yet? Are we there yet?" But
what you do want to do is you want to
make sure that there's a conversation
and it's even in that conversation,
you're keeping that goal of the why.
What are we doing it? Why are we doing
it? Who are we going to serve? And all
is said and done. And if you can start
from there, then that usually gives you
at least those north stars to keep as
part of your conversation as you go
forward. Thoughts on that?
>> Yeah. So that last part you said is kind
of interesting and I don't want to
deviate too much from the user stories,
but this is where those software
assessments come in handy and you sit
down with the customer and you walk
through their current systems. You
figure out how their business works,
what their products do, what they want,
and then you can sit down with them and
flush out the user stories because
you'll have a better understanding of
what it is that they their business is
and understand that. Okay, now these are
the stories that you really need or at
least you can ask the right questions at
that point.
I love your comment though there where
you know just tell me what to build.
There are times as developers, not just
coders, but as developers, where we
reach a point where we are so frustrated
with the lack of requirements or the
lack of features or lack of user stories
where we literally
are tired of look basically doing the
PMs or the PO's jobs and
in larger organizations this is a huge
problem and developer burnout is
notorious.
However, in smaller companies, you have
to understand that there may not be that
level of project manager, project owner,
business owner. So, you will have to
step up at times and step into those
roles to get these user stories that you
need to do the work to make sure that
the work you're doing is answering that
why and is sufficient for getting the
product across the line or a
deliverable. You just have to be careful
though that you don't always jump to the
conclusion of well just tell me what to
build. Sometimes you have to because
sometimes if you get into situations,
especially as a contractor, and you're
on a time budget, uh, hourly budget for
getting things done and the customer is
arguing with you or basically not giving
you what you need, you either need to
say, "Okay, then we need to put a pause
on this till we flush this out." or what
can you get from the customer enough to
get enough of the user story to keep the
work moving forward?
And that sometimes is the deal is you
have to pull enough out of them to
get that next step. And sometimes they
because I know developers because we
whine a lot. We're primadonas sometimes
is that we will mention, hey, we're
burned out. we're having trouble because
actually it's not that it's it's more
common for us to work 100 hours and not
be burned out than vice versa. At least
that's the um the story we tell. But our
customers will get burned out too. They
will get to a point where they're like,
I've I've answered this question too
many times or too many ways or things
like that. So sometimes we've got to
figure out how to
either soften the blow or
help them through it and say, "Okay, we
know this. Here's our foundation.
All we need is just this next step. All
we need is like this little thing is
like what does this look like?" And this
is where clickable demos and things like
that are very helpful. This is awesome.
I hate to be self- serving, but this is
where the, you know, the assessments,
those kinds of things are very valuable
because you get to start from here's
where you are, here's what you've got,
and here's some of the things that can
help you. And it allows a uh an earlier
ROI kind of vision at least because
maybe you're not going to be able to get
that ROI immediately, but you're going
to be able to see it. you're going to be
able to see that, oh, we're spending,
you know, somebody's spending 5 hours a
day on these reports. Now, we're going
to automate it and it's going to take
five minutes a day. And so, now that
person is freed up to go do other work.
Those kinds of things. Having that
almost carrot and stick approach, I
think, will really help your
conversations with your customers.
What will also help is if you send us an
email at [email protected]
because we are towards the end of yet
another episode and we'd love to hear
from you. What do you like? What don't
you like? Where would you like this to
go? We are not done with this season by
any stretch. We've still got quite a few
more. However, we would have no problem
throwing a couple interviews in. I know
I keep teasing that, but we're going to
get there at some point. We just uh you
know, we're just having too much fun
doing this actually right now. And uh if
you want to get reach out to us at
developer.com. If you want to go to
Facebook, we have a developer Facebook.
We are out on xdevelopure.
Wherever you listen to podcast, you can
leave us a review. Leave us a thumbs up,
thumbs down, five stars, 18 bananas,
whatever the review approach is. Love to
hear from you. Good or bad. We have the
developer channel out on YouTube. Check
that out. If you're listening to us, you
can actually see us. We're not as ugly
as some may think. pretty close though.
And then if you if you're tired of
seeing our face, you can always go back
to the audio version and just listen to
this. And you can be like me and you can
cheat and you can kick it up to like
1.25 m speed or faster. And I will just
say the if you crank it up all the way,
then the theme music goes really really
quick. It's like, wow, that guy is quite
the drummer. Um, and then the rest of
us, we talk really, really high probably
the rest of the time. That being said,
we need to wrap this one up. So go out
there and have yourself a great day, a
great week, and we will talk to you next
time. Uh let's see. Bonus material. Let
me go through points four, five, and six
really quick, and then we'll see what we
want. User stories and agile process.
Stories as a currency of sprints,
estimating stories, story points,
t-shirt sizing, refinement, backlog,
grooming, best practices. I'm going to
skip the talking points. uh five tools
and techniques using tools like Jira,
Trello, Azure DevOps, but focusing on
conversation not tickets documenting
user goals and flows with user story
maps. Integrating personas into story
design. Uh six, user story smells as a
system. Uh multiple user types in one
story. Vague success criteria. And then
oh there's a seventh. Real world
experiences. share a bad story that led
to wasted time or confusion or a success
story that was uh well written user
story led to a smooth release or a
delighted user. I will just first I'm
going to just do this for pass it to
Michael. I have been on projects that
have had very wellwritten thorough user
stories. They were a long time ago was
the first time I had one of those happen
and I was amazed at how much that helped
us build a very complex system and get
it done and stay pretty much on track.
And this is I don't think we were using
agile at that time. I think there's a
waterfall kind of approach. We had
really solid stories that had written
from the start and we were able to just
like start you line them up and knock
them down. You had a whole series of
requirements for any given story. as a
developer, you could take that story. We
didn't have a huge team, but it was easy
to just take a story, walk through the
whole thing. So, it was also very um
rewarding as a developer to start with
nothing and then get done and to be able
to see that story and walk through and
it had all of the exceptions and had all
of the validations and all of the things
that make the story real and successful.
So, I do believe they're out there. It
does take work. It does take intention
and you can't shortcut it. If you start
shortcutting it, then you're potentially
going to lose some stuff. Where do you
want to go with this one?
>> So, I'll touch on the tools. So, I I
know they touched on like Jira, um
Trello, and things like that. There are
other things too which uh if it it
depends on the type of person you are.
So, like if you're visual, look at tools
like draw.io, Vizio, Miro, uh, Figma.
Use additional visual tools to try to
prototype and help you build those user
stories for what you need.
I did not expect you to stop that
quickly. I was for a second and let you
talk and you did not. So, I got busted
on that one. Thanks a lot. You're fired.
Except he does all the work. So if he's
fired, if we don't have another episode,
you know that he was actually fired. If
we do, you know that he still has a job.
The bad news is we don't get paid, so it
doesn't really matter.
>> All right, good point. I think I I don't
want to like blow through that because
it was very quick but your tool that you
use is I think very very important for
these things particularly for uh user
stories and particularly for
communicating with your development
team. So definitely like there's a lot
of stuff out there. Play around with a
little bit. Find the stuff that speaks
to you, your team, particularly if you
have um this is it's a challenge because
even if you move to a new sprint team,
if you're doing an agile approach and
you've been doing sprints for a while
and now you move to a new project, new
team, you may have different tools that
work better.
You may also have just different ways
that you use the tools that you have. So
be aware of those, work with those. And
as always, let us know how it goes. We
would love to hear your feedback. Uh
I've already preached all of that kind
of stuff. So I'm going to let you guys
go. We're going to come back. We are
going to continue the with AI approach
to this because we're really getting
some good stuff. We've been we've been
having a great time with this. We've
learned quite a bit. Uh it's added a lot
of uh a lot of extra food for thought
for some of our uh some of our ideas and
some of our points and our past topics.
I'm not even going to tease the next
one. Actually, if you go back two
seasons, you can probably see exactly.
You can watch us walking through doing
these topics again. But we will be back.
We will carry on as we march towards uh
I don't know where we're at. As we're
marching towards episode 1,000. I don't
know why, but that's like one of those
things. It's like way way back. It
seemed like that would never happened.
And now it's like it feels like it's
within reach even though it's probably
like a year or two out, but hey, let me
drink
>> 900.
>> So there you go. 900. That's like that
might as well be. You can round up to a
thousand at that point. So maybe we'll
do the thousand episode celebration at
episode 900 and just cheat like that.
No, we won't. All right, go out there,
have yourself a great one. We're going
to get out of here. Come back. Talk to
you later.
[Music]