Effective Sprint Planning meetings have three conditions: a well refined Product Backlog, an understanding of the team’s capacity for that Sprint, and good facilitation and focus. In this episode, we’ll share how to do all three.
In this episode, Richard and Peter dig into the 3 conditions for an effective Sprint Planning meeting. While this is explicitly Scrum-focused, it’s really about how to have a good team planning meeting, whether you’re using Scrum or not.
Related Episodes
Why Scrum works when it works
How To Have a More Effective Daily Scrum Tomorrow
Effective Sprint Reviews
Two Key Moves for Better Sprint Retrospectives
Episode Transcription
Peter Green
Welcome to the Humanizing Work Show. Today’s episode is part of a series we are doing on the core components of the Scrum framework. The series explores the way that Scrum, while it emerged from software development, is, at its core a natural set of practices for collaborating on complex work, no matter the type of work you’re doing. If you haven’t already checked out the first episode in the series, “Why Scrum Works When it Works,” you may want to get that overview first, since this episode will dive into more detail on the first Scrum event, Sprint Planning. Make sure you subscribe to the channel if you’re watching on YouTube, or the podcast if you’re listening there, to get notified on future episodes.
In our “Why Scrum Works When It Works” episode, we shared the three conditions for an effective Sprint Planning meeting–- a well refined Product Backlog, an understanding of the team’s capacity for the Sprint, and good facilitation and focus. In this episode, we’ll give a bit more detail on each of these conditions.
Richard Lawrence
To start, let’s talk about the well-refined backlog. When it comes to Sprint Planning, we’re focusing on the top of the backlog—not all the backlog needs to be refined the same way. Check out our earlier episode on the PO Board to see how we recommend structuring a Product Backlog, so it has different levels of detail on different time horizons.
First off, the items on the top of the backlog should be small enough to fit well in a Sprint. And not just 1 or 2. That’s risky. We recommend slicing them small enough so that 6 to 10 could fit in a Sprint. This makes us most likely to get a set of items that fits well in a sprint, allows us to add or drop an item later if we learn more about how long things actually take; but they’re not so small that we’re spending excess time slicing and managing backlog items. If you have a hundred items going into your backlog, they’re just way too small. So there’s a sweet spot in the 6 to 10 range.
For software teams, we like something called a user story for the items at the top of the backlog. A user story is a change in system behavior described from the perspective of a user: in other words, a user being able to do a small new thing with the system they couldn’t do before. This keeps the team focused on user value every day, which is both motivating and increases the team’s odds of building the right product.
These stories should have enough detail in them so that developers can estimate them with some confidence and so they know enough to get started. The stories don’t need enough detail for the team to go off and build them without collaborating with the product owner. Especially in the Complex domain, it’s not possible to specify work to that level of detail. And teams that attempt to, either get stuck in analysis paralysis and never start complex items; or go into sprints with the illusion of knowing more than they actually do. Expect your stories to pick up more detail during the sprint. We learn what to build by starting to build it.
We don’t think backlog refinement should happen in a big all-team meeting. It’s better done incrementally with smaller groups. Every day, the Product Owner should look at the PO Board and ask, “what needs attention today?” What needs refinement today? Then they should use the daily scrum to coordinate with the team who should work together to refine those items and when and how that should happen. It’ll sound like, “Hey, I have a new story coming up in the backlog about such and such. I think it’s probably too big. Can a couple of people spend 20 minutes with me today slicing it into small stories?” And so you plan that, you go off and do it, then the next day, “Yesterday, we split that story into 3 smaller ones. Can we all spend a few minutes after the scrum today to do a quick round of estimating on those?” In this way, backlog refinement is calm, collaborative, and sustainable instead of a big, painful meeting no one wants to be at.
Whatever you do, don’t wait for Sprint Planning to get your backlog refined. That’s like a developer waiting to finish coding or testing until everyone sits down for the Sprint Review at the end of the Sprint. “Hey, let me just hack this together in the meeting here real quick.” Don’t do that. Product owners, get your backlog refined, get the help you need before you get into Sprint Planning.
Peter
Next, let’s talk about capacity. For teams that have been working together for a while, we can look at past Sprints to see what, on average, they tend to get done in a Sprint. This, by the way, is one of the reasons it’s important to keep a standard Sprint length for a while. If, for example, a team is working in two-week Sprints, once they’ve done a few of them, the team starts to get a sense of what two weeks of work feels like. They can look at the top of the Product Backlog in Sprint Planning, and intuitively say “Yeah, these 8 items are about two weeks of work.” If we vary the Sprint length either to get that last item done before the Sprint Review, or because during planning we had a big feature and wanted to try to accommodate it by the Sprint Review, we lose that regular cadence and a sense of what a common Sprint for us feels like. It’s also why it’s important to have clear alignment on what “Done” means. If in previous Sprints, some items are sort of mostly done, others are fully release-ready, and some are only partially done, this makes it really tough to know how much we can actually get finished in any given Sprint.
There are entire books written about how to do math to figure out how much, on average, a team should expect to get done. A word of caution about these techniques: they may work well if everything a team works on is what Cynefin refers to as in the Complicated domain, meaning that, with good analysis, we can predict exactly what to build, how to build it, and how long it will take. If that’s not true, as is the case with almost every team we’ve worked on or with, we need to take all of that math with a big grain of salt. Good refinement, as we mentioned above, is one way to reduce the variables and make the math more reliable. But it doesn’t completely eliminate the Complex domain. So, feel free to calculate average velocity, if you’ve got a stable team that regularly meets the definition of Done, and use that as one input to Sprint Planning. But keep in mind that even averages aren’t a perfect predictor for this Sprint. As our friend Mike Cohn says, average velocity is kind of like the average number of points scored per game for a professional sports team. It’s useful to know, but if that team happens to be playing a game against an opponent with the best defense in the league tonight, and two of our star players are injured, I’m not going to bet on the team getting the average number of points tonight.
So, consider averages, but then have a discussion about this Sprint. Are there holidays? Are people taking time off? Is someone out sick? In training? That will tell you your capacity for this Sprint.
Richard
Finally, the third piece of a good Sprint Planning meeting is good facilitation. Typically, this is done by the ScrumMaster, but we’ve seen a few teams where the Product Owner takes the lead here. Our favorite flow is pretty simple.
First, confirm that the backlog is well-refined out to a bit beyond a typical Sprint worth of work. If it’s not, you’ll need to pause Sprint Planning and catch up on backlog refinement. If it is, you’re ready to actually get into Sprint Planning. By the way, we recommend actually making that move, saying “the backlog isn’t ready, we’re not going to start Sprint Planning yet, let’s do some refinement. Then, “We finished refinement, maybe let’s take a short break and come back and start Sprint Planning. This keeps the Sprint Planning meeting from feeling like it’s taking forever, because it really wasn’t just Sprint Planning. So, you confirm that your backlog is refined.
Next, talk a bit about your sprint capacity. This, as Peter just described, means looking back at the team’s historical velocity. But also look at what’s different this sprint: PTO, holidays, training, etc. Some of this can happen before Sprint Planning, and often ScrumMasters take responsibility for pulling together some of this data, but I recommend, when you’re together at this point in the meeting, you talk about it and confirm that your understanding is aligned about it.
Now, it’s time to build the Sprint Backlog. We like to go item by item from the top, asking, “Does this fit?” until the answer is, “no.” If you have a well-refined backlog and a good sense of the team’s capacity, this should go pretty quickly. If it doesn’t go quickly, note what that’s telling you about your backlog refinement and capacity planning in the future.
From here, some teams take another pass to plan how they’re going to work on each Sprint Backlog item, maybe splitting them into tasks and maybe even estimating tasks and starting to assign them to individuals. We don’t recommend doing any of this in Sprint Planning. It’s too much detail too soon.
Instead, once you have a Sprint Backlog using the “Does this fit?” method, look at the whole Sprint Backlog and use a group decision-making technique like Fist to Five to confirm the whole Sprint Backlog makes sense together.
At that point, Sprint Planning is done. If it’s not the end of the day, you’re into the first day of the Sprint now, so we recommend immediately starting with your first daily Scrum where you plan that first day together, and you’re off and running!
Peter
Sprint Planning should be a “pull system,” not a push system. A pull system is one where the people doing the work pull the work in, deciding how much they can do given everything they know. A push system is one where some amount of work is pushed into the Sprint by someone else. In Scrum, there is no “pre-assigned” work to a Sprint. We don’t map out everything in the Product Backlog to its assigned Sprint and then assume that’s when it’s going to happen. Similarly, no one outside of the team can say “Hey, I really need this to be done by next week, so add it to your next Sprint, OK?” They can discuss how important something is with the Product Owner, the Product Owner can refine that item and move it to the top of the Product Backlog, but the team still considers their capacity when choosing to pull it in or not. Pull systems increase motivation and engagement, since the team has some autonomy in how much they pull in. Push systems decrease quality, since if work is assigned to fit in a Sprint and the team doesn’t actually have the capacity to finish it, they’re likely to try to do it anyway. If they don’t have capacity, they only have two levers to pull to get the work done: work overtime or cut quality. Working overtime might succeed every once in a while, but it messes up the team’s understanding of what they can get done in a normal sprint, and if it is a pattern, it’ll lead to burnout and a drop in both capacity and quality. Check out the episode page for a link to our episode called “How to Deal with Unrealistic Deadlines” for a description of what we call the “But we Must” approach to management, and what to do about that.
Richard
For your next Sprint Planning meeting, be sure to get those three conditions in place: Make sure your Product Backlog is refined before the meeting, do the work to get a handle on your team’s capacity, and have a plan to facilitate the meeting well. With these three conditions in place, you can go into the Sprint Planning meeting with confidence—this one’s going to be a good one!
Last updated