Agile Manifesto, Scrum, Sprints, Sprint Planning

This is Building Better Developers, the Develop-a-Noor podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge, and embracing life. Let's dive into the next episode. Well, hello and welcome back. We are continuing our season where we're looking at the Agile Manifesto. We have looked at the principles, we've looked at the values, and now we've sort of moved forward into Scrum and Sprints. And we're trying to figure out, you know, essentially the best way to implement these things in modern software development, picking from best practices and also some of the original guiding principles of Agile. In this episode, I want to dig a little deeper into the Sprint Planning portion. This is where we actually look at what are we doing? How do we build a Sprint? How do we put things into a Sprint? Now, we've talked about assigning values, estimating tickets, and getting some sort of an effort there. And we've talked a little bit about velocity. But the key here in putting together a Sprint and building on a Sprint is to remember that one of our goals is to deliver software, to deliver working software. So if that is our end objective, let's back up a little bit from that. Keeping that as our beacon of a target, and then let's build towards that. The first way to do this is to have a story. And this actually fits really well with the Sprint review portion as well. You end delivering working software, but right before that, we do a Sprint review where we walk through the things that have been completed and what these new features are, or these expanded features are that we have delivered in our working software. The best way to do the review is to have some sort of a story or common thread among the tasks that get done so that you can see that usually it's that use case or that story being built out as you go through the tasks that are completed on that Sprint. It just makes it a little easier for people that are not deep into the code to understand what's going on. But also it helps with the overall acceptance and testing of the application because you've got related areas or there's something along those lines where you've got, think of a large application, you've got all these, if you think of a diagram of it, maybe you've got all these little squares or circles that make up this large application. Well, if you're touching all of those squares or circles in a given release, it's going to be very difficult to test because you're going to have a lot of loose ends. If instead you're building all those features are within a single square or circle or section, then you're going to have a more complete, a more fleshed out story for the testers and for the users. So try to go with a theme at least, if not a story that is sort of going to drive, essentially going to drive that each Sprint. And how you get to that story, you may back into it or you may start with that. And by that I mean, take a look at what's in the backlog and you may see several related issues that just looking at them at a glance, essentially you say, you know, here's a batch or a group of issues of tickets, of work that makes sense to get done at the same time, essentially within a Sprint. And maybe within, when you look at the estimates and the time and what your velocity is, you say, oh yeah, these are well suited and we've got a hundred points that we typically hit. This is 90 points of tickets, you know, something like that. Then you say, okay, well, here's the stuff we're going to do. So at that point you build a story around that. Say, okay, well, we're doing these things in this section. So we're going to, since we're working on whatever the primary category stuff is, let's say it's all these tickets are related to, let's pick something, financial reporting. So this becomes a financial reporting story, whether it's a single report or multiple reports, however that work works out, however it comes out on the other end of the Sprint, you can have a story where you say, okay, well, this is our focus. And that's what I mean by the story. It's not, you know, long time ago when a galaxy far, far away. Instead, this is the, it's a natural flow. It's a way to talk through the features that have been added. So ideally you'd have something where, you know, this is some sort of a financial piece of the application. So the story is, you know, with these new features, now a user can come in and they can select this data entry or they can enter some data. It's going to validate stuff. It's going to show them what they entered and generate a report. Maybe that's your story for that given release is that you, you know, you're focused in that, in that bubble, in that square. And you want to talk about that use case, that user, that user experience. Because in doing this, you, in this case, even though you've sort of backed into it because you picked the issues essentially first, the story is what's going to drive your sprint. That's your focus for the sprint. And that becomes important as you get further into it when you're looking at either adding or removing tasks. Because inevitably that's going to happen. You know, there's going to be some sort of, something's going to come up and you're going to have maybe a task or two that isn't going to make it. We'll talk a little further about these. But then the other thing is maybe you've got some tasks you didn't think you were going to get to, but it worked out that you did. And so you're going to pull some in, but you, your story is what helps you with the decision of whether, you know, what goes and what stays. And that leads us to, I think probably the most important part of putting together sprint is to have what's typically considered three categories of tasks. There are the have to haves. We've got to get this done in this release. The, you know, maybe the need to haves, you know, or would like to have, want to haves where they're not critical. We could live without them, but we really, really would be better off if we could get them done. And then there's just the, you know, yeah, it would be nice. It's just sort of the nice to haves. So maybe have to have, want to have, nice to have. So that's your three levels, which is basically, yeah, if you look at them at one, two, and three, number one, stuff you cannot judge. Stuff that has to be done. These are the tickets we have to get done to make this release successful, to tell the story. The, at the other end, the number threes are the things that, yeah, if we need to throw something else, these are the first guys to go. These are the first ones that we say, ep, we don't really need them. They don't necessarily contribute to the overall story. And then the twos are the ones that help make it a better story, I guess, for like, you know, if we're trying to keep that analogy, then those are the ones that really flesh it out. It's minimal requirements. So your MVP for your release are the, you know, category one tickets. The things that you want to do to really, to satisfy the customer, to make people happy, is going to be get your twos in. And then the threes are icing on the cake. If you can get those in, great. Now that doesn't mean that if you don't get all your twos done, that you also don't get your threes done. And I'm going to talk about that in just a minute, but, you know, let's start with the ones, the twos and the threes. That story is what gives us where it's going to really help drive what falls into each category. And that's why we don't actually have to start with the tickets. We can instead start with the story and say, okay, which is not uncommon. You say, okay, we haven't touched this particular area of the application yet. And we really need to so we can get that in front of the customers. We can start getting some feedback. We can start giving them more of a feel of the total application. And so you say, okay, that's going to be our stories. We're going to talk about this functionality. And that could be whatever, like for example, reporting. We haven't touched reports yet. Let's have a reporting sprint where we're going to put some, you know, a couple of key pieces together and get that going. Well, to do that, you know, some of your ones are going to be, well, you're going to have to have the navigation to them. You're going to have to have some sort of a reports homepage or ability to select a report. You're going to have to have, depending on what you've built, you know, you're going to have some way to store or access reports, some way to define reports, some way to display reports, all of that. Now, depending on your resources and your timeframe, you know, how long is a sprint, that's very minimal at this point where you just, maybe you throw up a, just like an HTML static report that's not even dynamically generated. You know, so almost like a clickable demo, just to start getting some of the design pieces in place, you know, things like that. Or maybe you are able to do something more complicated, but you start with the story. And so you take that story, you look at your backlog and say, okay, here's a lot of the things we have to do that are related reporting. So that's, that's already taken the backlog and reducing its size. We're throwing a lot of stuff out. We're not going to worry about right now because we've got this reporting story. And so then with those, we're going to get a list of tasks and we've got estimates hopefully with them, or, you know, maybe as part of this, we're making sure that we get estimates on them. And then we look at, well, with the story, what would be the ones? Can we go through there and grab the ones? And where does that fit with our velocity? Have we already blown up velocity? And we are we very light? Do we have a lot of extra time? You know, how does it fit? If we've already blown out the, the, the sprint, if it's way more work than we can do in a sprint, then we can refine our story and refine our tickets as we can say, okay, well, here's some features that we can leave for another sprint and we'll adjust our story. Maybe this is part one of the story and part two is, is going to be a later sprint. However we, we get to that at some point, we're going to get to tickets are number ones and we're going to get below our velocity. Ideally, and this is just, this is personal kind of stuff. I think ideally you want your ones to be probably no more than 60 ish, 60 or 70% of your, your burn rate of your velocity. So if you can crank through a hundred points per sprint, then your ones probably should be more than 60 or 70%, you know, 60 or 70 points in total. And I say that because things go wrong and we need, we've said, this is where we started. The ones have to be done. We built our story counting on all of the number ones being done. So if we have any kind of slippage, we still have to be able to get those ones done. So if we, you know, if we were to put, you know, in a hundred point velocity, if we were to put a hundred points worth of tickets, how often are we going to make those? And maybe we're really good with our estimates and maybe we, we always hit our estimates, but that's rare. Maybe something comes up and you're going to have issues. So that that'll slip stuff. And then you miss tickets and then you're, and then you're also in that situation, you're always only going to get your ones done unless you happen to get everything done early and you're able to squeeze in a two or three. Now, then the next thing is once you've got your ones, which I said, if you figure 60, of your sprint is your ones, then probably another 20 to 30% would be your twos. And again, you don't want to fill it all the way up. You probably want to, between your ones and the twos be, you know, in that 80 to 90% range. Again because you want to have some buffer because ideally you have to have the ones, but ideally you'd like to get the ones and the twos. That would be a win. And if you, you know, between your ones and the twos are at 100% or more of your velocity, then you're not going to have that happen. And that is why we have the threes is because if we're on schedule, if we're on track and we've got 80 to 90% covers our ones and twos, that leaves us, you know, maybe 10 to 20% that we can hit our threes. So we can actually work our way through threes on average because you figure regardless of how we estimate stuff, that's really, really bad, particularly as we get multiple sprints into a solution. We're going to get good enough that we're going to be able to, you know, we're going to have some sprints that we do hit. If it's that kind of scheduling, we do hit all the ones and all the twos and we're going to have a little bit of time. So we can pull a couple threes in and we're going to make progress on all of those levels of tasks, those levels of work, that types of those types of work. And that's critical because a lot of times the threes are things like technical debt and things like that, that if we aren't careful, if we're not making some progress on those, then we end up in trouble. We end up either having to do maybe a technical debt release or we have to update the priorities on a lot of those things so that we have a story that basically addresses technical debt, where those are the tasks. And it's also just demoralizing basically. Developers typically have a feeling that if you say, we'll get it later, we'll fix it later, we won't unless it's burst into flames. In documentation and things like that, that we always say we want to get to, we want to it needs to be done, but it's too easy to push that off to another release to some time in the future. If you can set yourself up into a rhythm and have a habit of at least chipping away at that technical debt, then in those low priority tickets, then I think you'll find everybody will be happier and you'll have a little more confidence that putting something into the backlog, it will eventually get done. It just may take a while to get there. Now when you get to those threes, you're also, and this is sort of a key thing, as we get into those threes, you're sort of limited. Like I said, if you've got 100 points that you're cranking through per sprint, you only got maybe 10, if you do it like I just suggested, you got maybe 10 to 20 points left to knock out a couple of threes. Now if they're all one point tasks, okay, we can push those in, but you're going to get a few that are going to be four, five, 10 point tasks. So that's where you want to, you take a look at where you can, you maybe mix that up a little bit when you're looking at the, when you get into that, the tier three of tasks, is see if you can find something that's a little bigger and you squeeze in a couple smaller ones around it so that it's tempting to grab the small ones to say, well, okay, this won't be much so we can either get it done or we can easily reject it, but it's more likely we'll get it done because it's small. But that also then means that you end up with the bigger stuff sort of gets pushed back, pushed back, pushed back. So instead where you can see if you can squeeze in some of those bigger, closer to the remaining time item threes, unless you've been doing that a lot and you've got a lot of little ones lying around, but that's, it's usually the other case. So you get towards the end when you're looking for, when your dev team's looking for some additional things to do, don't start with the smallest tasks. Start with stuff that's closer to the reasonable amount of time that you could maybe get them done in this release, but it's maybe just that one ticket. So it's almost a quality over quantity, I guess. Get the larger blocks first because then the smaller blocks can almost always get fit in. If you think of that example where people, they start filling a bucket and you start with very large softballs and then there's some space left over so they start throwing some marbles in there and they end up, they get down to sand and they get down to water. Well, you think about it the same way is that those bigger tickets, those bigger items are going to be tougher to fit in. So where we can, let's grab the small ones. And that also should apply to the level two and level one items as well is that, you know, we may have a story where there's a lot of big block, big sized tasks that we're doing, but see if there's maybe a couple of little ones that you can fit in as well. And usually in doing so, these are going to be, they may be part of the story you're telling, but maybe these are a couple of little adjustments from a prior story or maybe it's a lead into a story that you want to tell in a sprint or two in the future. Which brings me to one more thing I want to cover before we move on to other topics from sprint planning. And that is ideally you should be planning your sprints, a couple of sprints ahead. You should have time that you should be able to craft a epic, a multi sprint story and be putting things in place and be looking at tasks that need to be done. Now you don't have to fill out the sprints completely, but I think you should be putting a focus at least, or at least a story idea for future sprints. And you want to stay a couple of sprints ahead because this is going to allow you to do some additional research, requirements gathering, design, and some other things that just need to be done in order to really keep the team moving. You don't ever, you know, this is you as a scrum master. You don't ever want to be the blocker. So every sprint you should be, as a scrum master, you should be ready to go. You should have the sprints should start. You should have the tickets in place, everything in place and get going. Trust me, I've been in situations where we've done it right. And I've been in situations where we're scrambling and it is much more frustrating to deal with the sprint when you don't have it. When you're not able to get the tasks in place until the first day of the sprint, or maybe the day before the first day of the sprint, there's just too much. It just becomes too challenging. There's too many things that can go wrong. For example, where you need additional, you need clarification, you need requirements, you need, maybe there's some prerequisites, things like that that you have to do that can derail you. And then the next thing you know, you're a day or two into your sprint and you really don't have it fleshed out yet. And so the developers, you can maybe get them working. Maybe the next thing you know, the developer is floundering a little bit, waiting for you to give them a pile of tasks to work on. Challenge of the week. Think about whatever sprint style you're going in and how do you, do you know? And if so, that's this question. But if you don't, maybe ask some questions. Figure out how does the sprint get populated? Who are the people or what process actually pulls tickets forward to say, okay, this is what we're going to have as the scope for the sprint. And is there a story? If not, can you maybe, even with the current sprint, take a look at what's going on and craft a story so that when you get to the sprint review, which hopefully you do, you've got something that's a little more memorable, is a little more, I don't know, a little more theatrical value or whatever it is. But it's so that you can actually get something that's not a dry, we have this function, we have that function, navigate here, click that. Instead, it's something that gives the users, the listeners, an idea of the use case. Maybe to the point where they can picture somebody sitting in front of a computer and doing exactly these tasks. That being said, I can get back to my computer and do the whole bunch of tasks I've got. And hopefully you can do the same. But as always, go out there and have yourself a great day, a great week, and we will talk to you next time. The end of today is still progress, so let's keep moving forward together. Hi, this is Rob from Building Better Developers, the Develop-a-Noor podcast. We're excited to be on Alexa now. You can enable us by simply saying, Alexa, enable Building Better Developers. And we will be there ready for you every time you want to listen to your now favorite podcast. Whether we are your favorite podcast or not, we would love to hear from you. Please leave a review on Amazon.