Defining 'Done' in Agile - How to Stay on Track and Avoid Scope Creep

Welcome to Building Better Developers, the Developer Noir Podcast, where we work on getting better step by step professionally and personally. Let's get started. Hello and welcome back. We are continuing the journey of a developer as we're talking about being building better developers and this is the Developer Noir Podcast. I am Rob Brodhead. I'm one of the founders of Developer Noir and also a founder of RB Consulting where we help you tame technology through simplification, automation and integration. We take all of that crap that's out there and find ways to put it all together in a nice pretty bow on it and all that kind of stuff so that you can use these things and not have 15,000 logins or having to do a lot of manual imports and exports and all of that stuff that is a headache. Now, one of the things we do is we talk about what's good and bad that's happened since the last time we talked. So from a good point of view, I'm going to start with, I actually have a couple of customers right now that there is the budget, the bandwidth to do it right. A lot of times we get this stuff and they're like, it's got to be done today. It's got to be done with it. Like, cut hours, cut testing, cut this, cut that. Documentation can be done later and things like that where they keep cutting corners to try to hit their deadlines, but they're really sort of hurting themselves and they get to the end and they're like, well, I've got something that's completely, you know, it's not done. And you say, correct, it's not done because we didn't put the time in to get there. And I've got customers that are able to allow me to do that. And it is so fulfilling to be in a situation where you can actually apply all your skills in doing things, though, we'll say in quotes, the right way, but being able to do that. The bad thing is, the bad thing, I guess, is my kids, I've got like, I'm going to be an empty nester soon. And one of the empty nesters, one of them that are flying the nest is going to be like this close. And for those that can't see it, which is some of you, a lot of you, maybe very close. I've got my fingers all the way together, this close to being out of money. And so it's already like, he's going to be able to get in and he's going to have to grow some vegetables in the backyard or something, wherever he's at, because it's like, dude, your budget is like your runway. You're going to you're going right off the runway. So we're going to have to work on that. Bad news. Too long on that. So I'm going to pass that on to you. Let you introduce yourself. Hey, everyone. My name is Michael Milos. I'm one of the co-founders of Develop Nerve, Building Better Developers. I am also the founder of Envision QA, where we help businesses analyze their software to identify basically workflows that are either not in the system or find better ways for their software to work for them instead of against them. So with that, I'll go into my good. The good is one of the projects I'm working on. While we are in a bit of a time crunch because of the necessity for their change, we are taking the time and they're willing to work with us to define these requirements correctly. So we avoid a lot of the things that we're going to be talking about today. On the bad side, my wife bought this wonderful TV at Christmas last year, and it's gotten to the point now where we've tried moving it around the room a couple of different times. Because of where they put the speakers, we can't hear people speak at all. So I had to buy another external speaker. More cost. Hopefully this thing works. Right now, I'm not holding my breath. That is my favorite. I ran into that just the other day with some I'm trying to remember what it was, but it's one of those words like you have to use closed captioning because the speakers and such are just not where they should be. Or they have bad audio. It's like one of these things where all these soft talkers and there's loud stuff going on and when you put in closed captioning and suddenly you see it's a whole different show. It's a whole different story because that's stuff that you miss because they don't get the audio right. That's for another topic. We can have like a we can have a venting session. I want to talk about agile this time. And with respect to done now, one of the things that we have talked about in the past in both for career and for projects are the idea of roadmaps. And it is in the agile world you have these like epics and things like that. There are things that span multiple sprints, but an epic doesn't necessarily get you a product. What I think you need to really have and I found that has worked the best when you're going into an agile approach is that you have an MVP, which is a minimally viable product. And that's from the start from sprint one. You have an MVP, which is very hard to say together, but you have that. And yes, it will it will be adjusted basically as you're going from sprint to sprint to sprint. But what you should be able to do then is show progress towards that product that you're going to release. Now, of course, in a sprint, technically, if you're doing them right, you have a usable deployment of software at the end of every single sprint. Now, we all know that that does not always happen. Where usable is I've got a login screen and I can log in. OK, great. That doesn't really help me a whole lot. They're going to be situational or maybe you have to go to sprints. You don't release this one because it's just too many things in flux. I get that. But that should help because you're going to show some usable things along the way that are and usable is obviously it's a soft definition of what usable is. But those should be marking you towards your MVP. Your MVP is your why. That is why we are going through these sprints. We're getting to this thing that is what helps us define done. Because if we have all the features that we decided were going to be the minimally viable product in that, yes, we can continue. But at least at that point, we know that we are done, we'll say that we have completed that project. Now, that doesn't mean that you set it up on sprint one and you don't think about it It does mean that that is a living thing just like everything else. But it gives you it gives you like an anchor. It gives you a foundation. It gives you a core because you can look at that as you're going from sprint to sprint to sprint. And I'm going to let Michael talk a little bit about some of the the things about agile that may help you with this. But what you're going to do is you're going to have conversations effectively about this is a big change to the MVP or this is a minor change to the MVP or I'm going to go on mute for a second because I'm about to sneeze. Oh, wait, maybe not. Wait. Apologies, you can always edit that out or not, because, hey, that's how we roll. As you're getting to that MVP, there are going to be changes maybe that are made to it that are big, they're substantial. And those are the things that you want to communicate back to the product owner to the customer that we have now made a big change. So it may be a big change that says we are effectively back to sprint one or this is now going to add multiple sprints of functionality. And even within that, as you're going from sprint to sprint to sprint, there should be there's if it's done right, you're always also looking ahead. The product owner, the scrum master are looking ahead. And if you're starting to look ahead and you're seeing nothing but we're just adding, just adding, just adding, we're not really getting closer to that, then those are the kinds of things you need to bring a heads up to say, hey, this is going beyond the scope of what we originally talked about. This is going beyond what we talked about as a comfortable runway to get this thing Because those, those require, those are like meta or core requirements to the project. It's not requirements when we're talking about software requirements. These are requirements like we only have X amount of dollars or X amount of resources or X amount of time, or there are, you know, maybe there's regulation authorities or stuff like that where we have to have certain stuff by a certain time period, which become, yes, that's your MVP. That's your why. Those are the things that if you're moving off of that MVP, if you're pushing back that, those should always be discussions. That's a great communication point to say, hey, we're making some changes and we just want to all agree. Like when you first make them, we want to all agree that that makes sense and that's going to work. So we don't get in a situation where we try to bite off, essentially bite off more than we can chew as part of that. I'll toss it over to you and let you go, you know, sort of step into that from your point of view. Yeah, so typically either when you're first starting out or if you're already in a release cycle system with Agile, one of the key takeaways with Agile, which is supposed to help avoid some of this scope creep and some of this bloat or unforeseen requirements is your daily stand up. You know, you meet as a team, you talk through what you're working on. Are you blocked by anything? Did you run across something that is in of itself requiring a requirement from something else that either wasn't thought of or another piece of work that's being done that is behind holding you up or did you just get ahead and so on. So we moved our tickets through the process of, you know, we're working on it. It's in progress. We're blocked testing and so on. The other thing is when you move it to testing, did the tester run across a scenario that wasn't thought of? You know, did you have a special character that was supposed to work that's not working as expected? So there are other things that at least within the stand up process you catch daily and these things can get flagged and hopefully addressed quickly, either individually with one on ones or as a team as a whole. The other thing is you're going through the process at towards the end of every sprint, you're going to have a backlog refinement where you're going to sit down as a team with the product owner, the business owner and go through the requirements for the MVP that you need to work on for the next sprint. You know, what are the next batch of features that we need to roll in or what tickets from the current sprint are potentially going to roll over because we're running into some difficulties or it's taking more work or we we get some type of blocker that caused a little bit of time, you know, scope to be added to the ticket. And then when you get to the end of the sprint, you should always do some type of sprint burn down, go through your tickets that you just completed in the previous sprint and identify, you know, what went well, what didn't go well, what requirements, you know, did we miss and make sure all that gets put in two tickets. If that is either not communicated to the business or not in tickets, it's going to be missed. You're going to run into situations where, you know, someone could go on vacation for a month, come back, meet your manager, product owner, and they think everything's going to be done based on the timelines. And then you come back and it's like, yeah, it's ready to go. We missed a feature. So now it goes out and you have an unhappy customer or the product doesn't even work. It breaks. So now you have more deadlines. Are more delays trying to get this software out the door. So by doing the kind of burn down and end of sprint review, you collectively as a team hash out what you can do to make things better. What can you do as a team? What essentially is your development agreement to keep things moving forward, to get these tickets done right, get the right requirements into these tickets, and also make sure that as a team, you have a collective understanding of what the definition of done is. So as you work on these tickets, you're not just throwing the ticket over to test with one line of change that doesn't address all the issues that were in the ticket. So you don't want to miss things that you should be doing, causing tickets to go back and forth through different phases that are happening because you didn't do the work right the first time. Now, the other side of that is don't sit on a ticket for days trying to make sure it's 100 percent right. Because again, we're shooting for that MVP. But if you run into blockers, if you run into situations where this ticket should have taken like a day or two, but now you're on day three, maybe day four, maybe it's time to bring it up and stand up or collectively have a team huddle and say, let's hash this out. I'm stuck or something's just not right. So you kind of have to communicate, work together to get back on track. So again, your sprint moves smoothly. You're going through the right peaks and valleys and your software is continuing to move down that MVP towards your deliverable at the end of the sprint. Two things that are really important there, one that's probably a little bit off of the scope creep thing, but I do want to touch on when you pick up a ticket, there is an estimate attached to it. And that is often that is a huge part of what you should have in your mind of like what level of coding of what is the scope of this? What is it that I should be addressing? If it's a if it's something that roughly should take you half a day and it's into a full day and you're still not done with it, those are like those are little flags to say, hey, let's raise that up in the sprint or in the stand up or ideally before you get into it, if you think it's going to take longer than that, that should be part of the estimate discussions. So it should be clear on what really is the what is really contained within this ticket. And again, it also helps you define what's in it. It helps you write a better ticket because if somebody says, you know, if you're scoring on a scale of one to 20 and a bunch of people say one and a bunch of people say 20, that's a good point to say, OK, we need to talk about what does this mean? Because obviously we have a very different picture of what this project is. Now, I really want to. Look at the the burn down, the retrospective kind of piece of a sprint, because that is also something where we can very easily get into the mode of we get a couple of tickets done, but we push a couple into the next sprint and into the next sprint and into the next sprint. And very often when you've got a team working to get in that retrospective, like what went well, what didn't. Usually what you end up finding is somebody's going to say, hey, we keep like punting stuff to the next sprint. This is going to bite us at some point. We need to figure this thing out. We need to estimate better. We need to project better, whatever it is, because if you're still kicking stuff forward, then that technically means you're probably somewhere down the line pushing out your release dates. You can't keep doing those things. And those should be a heads up. If if we're seeing this, that may be something that you say, OK, in the next sprint, one of the things we're going to do is we're going to walk through and look at what are we doing? Why are these slipping? And then make those adjustments, because it could be that it could be from almost anything. It could be that the tickets are not being the requirements are not deep enough. And so we're spending too much time kicking those back. We're in a cycle trying to flesh those out. It could be something where nothing's being marked done until the last day of the sprint. And then QA doesn't have time to test it all. And then all that stuff gets kicked into the next one. It could be anything in between those as well. And it could be things like scope creep. It could be things where we originally had this picture of what the MVP was. But as we're getting clarification from sprint to sprint, it's changing what that MVP is. And maybe we haven't looked at that enough to say, hey, we are now expanding on that or we're shifting it in some way, form or fashion. That is now something we need to communicate back to the powers that be the people that sign your check, the customers, people like that to say, hey, this is not where we started. What we talked about and where we thought we were going to go, we're not going there. It would be stuff like, you know, you start in Washington, D.C. and you're like, oh, we're just going to go to, you know, Cincinnati. But along the way, you realize you have to go all the way out to San Diego. If you guys don't know geography, Google Maps. But, you know, it's one of these things is that those things can be. And we've had those kinds of situations. There are projects that are so much like that, where it's like, we're going to go to this little place that's not that far away. This is like, it's easy. That is the worst thing to hear in software development. This is going to be easy. That's easy. That's no problem. Just use that piece of cake. That is should always be a red flag. There's what if it's not? Just ask that question. What if it's not? What if that doesn't work the way you think it is? Those are the kinds of red flags that should be. Even if we're heads down in development, those are things that we should be thinking about when we get into our reviews and our retrospectives is we really should be looking at what is the feedback that we're getting from the customer when we're going through that demo, that review process? Are we seeing things that are concerns to us that maybe we're not hitting the mark? And then in the retrospective, are we repeatedly bringing up something along the lines of we're kicking stuff down the road too often and that we need to make that our priority in the next sprint? More thoughts on those, because I know I did open the can of worms a little bit more. Oh, yes. So I'll take on a little bit because I didn't talk about the points before. But as you're reviewing the tickets and defining the requirements and the definition of done as a team, collectively, you want to agree on a pointing system or we use points to kind of figure out, OK, who thinks it's easy? Who thinks it needs a little more work? And then you kind of flush out an average to use as a team for the ticket. This helps kind of define the deadlines or how long that work's going to take so that they can plan out release cycles. Unfortunately, though, and I like you touched on this, but sometimes you run across a bug that is a major bug or. You have like medical laws change or financial laws change, and you have to do something because of regulation, but you have to do it quickly. Well, sometimes that gets thrown in, but they don't take something out. So if you start seeing a lot of things, not necessarily just being kicked down, but if you see more and more work coming into a sprint after it started and stuff is not being taken out, you're never going to reach the end. You're going to kind of be in that crunch firefighting mode. And you're kind of on a death march until you get to a point where you can say, cut. Now it's start over. Let's begin again. But unfortunately, you're going to probably be in a situation where you're three, four, five, six sprints down the road. And your team is in crunch mode, firefighting mode, burned out. These are other signs that you need to revisit your sprints, these tickets to make sure that things are moving smoothly. If you see a lot of people dropping. Burnout, PTO, revisit your plan, revisit your schedule, because something that is another indicator that something is wrong and you may not see it right now. But very quickly, you will start seeing that scope creep or you're going to see that release cycles being missed and tickets that should take a day or two, probably going to take longer just because the mental capacity is not there for your team. Yeah, I guess we'll we'll continue on the discussion another time because there's a lot we can go into this. I do want to mention that there's going to your point there is to think about and that you may not be able to as a developer, but if you're a scrum master in particular, think about sprints that are and as a product owner, even that are performance tuning sprints that are bug fixing for sprints. And it's really hard to sell a technical debt sprint. But it may be one of those things. And a lot of times I think I've seen it best done where there are technical debt tickets that get pushed into each sprint. And maybe it's only one or two, but it's something that hopefully you can. You know, and they're almost they're never going to be the we got to have it or almost never. But try to have somebody like if you can just tackle one or two of those from sprint to sprint to sprint, it at least is moving the ball forward. And we talk so much about, you know, momentum and moving the ball forward in our careers. And it's the same way in software, because as Michael suggested, you get this burnout, you get all this stuff when we don't. If we as developers don't feel that we're done, then we're going to end up stressing about it. So we need to help the customer and ourselves by saying, what does done mean? And this can be down at even a feature level is like when this feature is done, what is it going to do? What do we need to take care of? Now, if we're writing buggy code and stuff like that, that may be on us. It may be partially because of stress. But if we should be able to, you know, go through, test it, verify it. And then if it's a bug, maybe it's an integration bug or something that we can come back. And usually then, hopefully, it's not critical. So we can say, I'm not going to I'm not going to push it into this sprint. I'm going to we'll put it on the backlog. We'll make it a high priority. We'll tackle it in the next sprint or maybe two or three sprints down. And if you talk to your customers, if you sell it that way, as we call it, refer to that way and say, hey, we're we're not we're focused on this other work right now. It is not effective. And this is true. It's probably going to be not effective to go chase down those bugs. Instead, we're going to get this feature thing that we're working on done. And then we'll come back in another sprint and we'll go through those bugs because that makes more sense. And that in particular saves you one. If you do that, the customer trusts you to say, OK, we're going to come back and fix it to it saves you from those most annoying things where it's like, this is just going to take me a minute. It's things like, you know, this color isn't right or this isn't spelled right or this button needs to move or this this field needs to go from a date to a date time or those things that are. Yeah, we can probably fix them really quick, but it takes us out of our groove. It takes us off of whatever the main track is. And if we're not doing those in bunches and in a batch kind of approach, it really hurts us as far as like switching gears mentally as that time goes. I was going to pass it back to you, but I'm not, because I think we've run long enough on this. We're going to run this. We will wrap this one up. We're going to make it a two parter. This probably will actually be sort of a three parter, maybe even. And we'll see where we go with the next episode. Apologies if we run a little bit long, if we've gotten a little long winded, but these are the things that are near and dear to our heart and should be to you as well, because these are where we win and lose the battles for building better software. Is it making sure that we are communicating, making sure that we understand what we are building? What does done mean? What are the requirements? What is the goal line? What does that MVP look like? That is why we go out to you all the time as we are looking for our requirements via email. So send us an email at info at developer.com. Check us out on developer.com and check out all the different content there, which is a lot over a thousand articles out there on a wide range of stuff. Leave us comments. You can leave them on the article. You can there's a contact us form. You can use that. You can check out school.development.com. There's also comments in all kinds of sections in there that you can go check that stuff out, see a little bit different way to consume. All the content we have there. Any of those areas, including this one, leave us comments, leave us ratings, whatever you want to do and include, please. What would you like to see? What are some things that we could do more of, do less of? What are the things you like? What are the things you don't like? Sort of like a retrospective in a sprint. What do we do right? What do we do wrong? What do we do more of? What do we need to stop or do less of? That kind of feedback is what helps us help you and it will help us give you a more entertaining and educational, we'll say, dare I say, educational podcast. That being said, go out there and live your better life as a better developer until we meet next time. Grab there and have yourself a great day, a great week, and we will talk to you or at you next time. Thank you for listening to Building Better Developers, the Develop-a-Noor Podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.