5 Things You Can Do to Fix Your Sprint Planning

Hey, my name is Dave Pryor, I'm a certified scrum trainer. This video is going to feature 5 things you can do to fix sprint planning. In every class that I teach, I get people on teams who are dragging work from one sprint to the next, not finishing it, and over committing every single time. This is a huge issue. The whole point of working in a sprint is to get something to a finish state by the end. You get it, you show it to somebody, you get some feedback, you figure out how to make it better, you move on. That's the whole point of scrum. If your team's not delivering, you can't inspect and adapt. If you can't inspect and adapt, you can't improve. You're not going to delay your customer. So this video is going to feature 5 things you can do to fix that problem. Here we go. Number one, make sure the work that your team is bringing into the sprint is actually small enough that you can finish it in a sprint. It seems like a no-brainer, like we shouldn't have to talk about it, but all the time teams are bringing in work that's like bigger than the whole sprint. I mean, maybe they think they can squeeze it in. The scrum guide actually says it just has to be small enough to finish in a sprint, but I don't think that's enough. I think you should go a step further. My suggestion would be any product backlog item you're going to bring into a sprint, break it down into vertical slices that could be delivered in three days or less. So that's going to take some work. It's not an easy thing to do, but if you break it down into really small pieces, you can track your progress throughout the sprint. You're going to know much sooner if you're not going to make it, and you'll be able to tell if you're bringing in something that's just like this massive thing, that there's no way you're going to get it done. Your team's job is to finish their work by the end of the sprint. So make sure the work is not too big for that to happen. Number two. Number one kind of leads directly into number two. Make sure you protect time in the sprint for product backlog refinement with the developers. At every sprint, the PO and the dev should be sitting down together and looking at all the stuff that the PO thinks they're going to ask for in the next sprint and making sure that it looks like it's actionable. The team will be estimating it. They should be talking about the scope of it, talking about the acceptance criteria, doing everything they can to make sure that this thing is in a state where they could take action on it right now. But all the time, teams get overloaded with work because they brought too much stuff into the sprint, and they don't do backlog refinement, and they just commit to stuff they don't understand. It's really important if you're on a development team that before you say, yes, we can do that, that you figure out if you can do it, because that's what the company is depending on you for. So make sure you protect time for product backlog refinement. Here comes number three. Make sure you have a definition of ready. This isn't technically part of Scrum, but it's one of the things I have found to be the most helpful in making sure that you can actually follow up with number two, the one we just went through. A definition of ready is kind of the mirror image of a definition of done. It's how you make sure you know that the stuff that you're going to work on is actually in a state you can work on it. So you could have a checklist with things like the team has estimated the work and determined that it's small enough to finish in a sprint or maybe less than three days. The team believes they have the skills they need to get the work done, and there's no external dependencies. That's a really important one for me. I don't want the team to work on anything that is in a state where the only way they can deliver it is if another team who has other priorities gives us something in the middle of the sprint. It should have clear testable acceptance criteria. You can add as many things in here as you want, but basically when the team and the PO look at the stuff in the product backlog during product backlog refinement, and they know what the PO wants in the next sprint, they're going through these items one by one trying to make sure they meet the definition of ready. Now there's going to be exceptions. Stuff will come into sprint planning that doesn't meet the definition of ready, but you want to try to avoid that because when you bring in work that hasn't been sized, that the team hasn't taken the time to figure it out, you're going to have to do that in sprint planning. That's exhausting, and it's going to lead to decision fatigue, and by the time the team gets to a place where they're ready to make their commitment for the sprint, they'll be fried. They'll make bad choices. So you get the stuff ready before you go into sprint planning, and in sprint planning you can focus on making sure the work you're planning to do is stuff you can actually do. All right, number four, track your team's average velocity and plan accordingly. If you know about how much work your team can get done in the sprint, do that much. Ask for about that much. It seems like another no-brainer, but it's not, especially for the teams doing quarterly planning who seem hell-bent on proving to themselves one quarter after another that they can't do the amount of work they're committing to. If you're using something like story points and your average velocity is 32 story points, then the PO's probably going to ask for like 30 to 35 story points, not 50 because that would be really dumb. Now if you're using flow metrics, you're already rolling your eyes, so you can just move on to the next one, but tracking your historical velocity is a really important way of trying to get a sense. It won't be right all the time, but a sense of about how much work you can do in a sprint. All right, here we go. Number five, this is the big one. This is something I have helped a lot of teams with, both in coaching and in the classes that I teach. Understand your capacity for work. I see people come into class all the time that talk about how they're going to tell the team what their velocity is going to be or tell the team what their capacity should be. It doesn't work like that. We're all human beings. Stuff gets in the way, right? If you're in sprint planning, let's say you've got a product backlog item, a thing you want to deliver. You break it down into a series of activities required to produce that thing. I'm going to call those things tasks. If you're estimating the product backlog item in something like story points, maybe you're estimating these tasks in ideal hours, which is somebody at their desk uninterrupted just cranking stuff out. How long would it take? We come up with an estimate for all the activities required to produce all the things we want to deliver in the sprint, and we can total up the number of hours of work we're looking at. That's what we're trying to do, but capacity is different. Now, I had a team that couldn't deliver in a sprint, so I built this little calculator. Everybody had to fill it out before they came to sprint planning, and I asked them a whole bunch of questions. You start out with maybe potentially 80 hours in a two-week sprint, but nobody's productive for eight hours a day. Let's say you decide you're going to take it down a few hours, and then you subtract for all the scrum meetings, and then you subtract for all the other interruptions you have, some of them driven by work, like other meetings you have to go to, or administrative stuff you have to deal with, all the kinds of hidden and gorilla whip that are sneaking around sucking up your time. You have to account for that. Then you probably have to account for the fact that you have a life, too, because that also gets in the way of work. What typically happens is people that start out with this capacity calculator thinking they have like 70 hours to work in a two-week cycle end up with like 13 hours of work. Now, everybody would fill this out before they come to sprint planning, and we can total up the number of hours of work we can all do, and that's our capacity, which we can then compare to the number of hours of work we're looking at doing, and suddenly you're like, oh, we have 700 hours of work and 200 hours of capacity. Maybe we should fix that before we commit to stuff in the sprint, because the most important thing here is that it's not about the number of hours you work. It's not about the number of story points you drag across the finish line. It's about did you meet your sprint goal? Did you meet your commitment? Did you fulfill the promise you made to the business? You have to do whatever you can to make that work, so five quick tips to help you with sprint planning. If you're interested in learning more, you can click the link below. I'd love to see you in a CSM or CSPO class. My name is Dave Pryor. Thanks for watching. If you learn to work the old way, but the new way's what you need, my job's to make that switch from old to new. Something less for you than it did for me. Here on Drunken PM Radio, whoa! Here on Drunken PM Radio, whoa!