Sprint planning is often the longest meeting teams have each sprint. But it doesn't need to take all day, or even half a day! In fact, a two-week sprint can be planned well in just 90 minutes, without rushing.
The sprint planning meeting, when done well, is energizing for teams. When team members leave with a plan for how to approach the work of the sprint and a sense of purpose for how to achieve the sprint goal, there is a palatable excitement in the air.
And when sprint planning is done well, teams achieve their sprint goal most of the time (but definitely not all the time).
So what are the danger signs that sprint planning is a struggle for your teams? And how can you turn it around? Find out in this video. (If you'd rather read about it, I've included the full transcript below.)
Danger Sign 1: Sprint Planning Meetings Are Long and Painful
Danger sign number one is that sprint planning meetings are long and painful, and team member are complaining about it. I can almost hear some of you are telling me that all meetings are painful. Perhaps. But while you may not enjoy being in a meeting, team members should at least find sprint planning meetings valuable.
I don't enjoy going to the dentist twice a year to ever scrape the barnacles off my teeth, but I do acknowledge it's valuable.
Danger Sign 2: Teams Miss the Mark Most Sprints
Teams don't need to achieve the sprint goal and finish everything every sprint but they should finish everything most of the time.
Too many teams miss the mark every sprint. If people think of planning meetings as long and painful, those feelings are going to be compounded when the meetings don't lead to successfully completing sprints.
Danger Sign 3: Sprint Planning Doesn't Generate Excitement
A third sign your team is struggling with sprint planning is that team members fail to leave the meeting enthused and energized about the work of the coming sprint. When sprint planning is done well, team members should be fired up excited about doing the work they just spent time talking about. If you and your teammates finish a planning meeting and aren't excited to do that work, it's a sign that sprint planning could be better.
Tip 1: Keep sprint planning meetings short
Now, let's talk about how to stop struggling with Sprint planning and do it better. I'm going to share three tips.
First, keep your sprint planning meetings fairly short. You don't want to rush through a planning meeting, if you do that you're almost guaranteed to overlook too much work and then not finish all the backlog items needed to achieve the sprint goal. The advice be quick but don't hurry applies here.
The meeting should be fast paced but with no feeling that discussions are being rushed or cut off. I like to target about 90 minutes to plan a two-week sprint. If you're planning a two-week sprint in 30 minutes you're almost certainly not thinking through the work in sufficient detail. On the other hand, when a two-week sprint requires a three-hour planning meeting, people are within their rights to complain that the meetings are long and painful (Danger sign number one).
Tip 2: Minimize Time Spent on Estimates
The second tip is to create a sprint backlog that includes a list of tasks and a rough estimate for each task. But don't spend much time on the tasks or the estimates.
A software team working on a relatively simple feature may, for example, come up with one or two coding tasks, a testing task, a design task, and maybe a task to get the user's opinions on the design. The estimates can be rough—little more than quick guesses. The team should use them solely to gauge if they're bringing the right amount of work into the sprint—not too much and not too little.
Coding Task 1: 6 hours
Coding Task 2: 6 hours
Testing Task: 6 hours
Design Task: 2 hours
User Review: 3 hours
Keep each estimate under a day of effort. If something will take longer than a day, encourage team members to turn that into more than one task instead, each with its own estimate under a day.
The estimates should include time for everyone involved. The task design review shown previously has a three-hour estimate, but it's not going to be a three-hour meeting. Instead, it's probably going to be a one-hour meeting and three team members will participate.
Coming up with these tasks and estimates shouldn't take much time, certainly not so much that your sprint planning meeting crosses over into that long and painful category. Remember, they're really just quick guesses plus you won't need to do this forever.
Once your team has gotten good at planning sprints, try skipping the estimates. Just create a list of tasks and see if team members can decide if a sprint seems appropriately full using just the list.
Tip 3: Don't Try to Think of Everything
Here's a third and final tip and this one will really save you time in planning meetings: Don't try to think of everything.
I know I just told you to make a list of tasks for each product backlog item. But teams don't need to think of every task during sprint planning.
To keep things moving, have team members yell out what needs to be done: Code this test, decide how we'll handle such and such, and so on. You'll notice that very quickly, people run out of ideas.
When that happens give the silence perhaps 5 or 10 seconds to see if anyone thinks of any additional tasks. After that, move on and start talking about the next product backlog item and creating its list of tasks and estimates.
When you do this I can guarantee that some tasks will be overlooked. And that's OK
If you'd given the team five more minutes to think about each product backlog item, maybe played some Mozart music to help their brains think, they would have come up with a few more items. But it's not worth it! Quickly identify the tasks the team can immediately name and then move on.
For this to be successful, make sure you don't fill the sprint too full. The team will identify new tasks during the sprint so make sure you've left time for that.
For example, suppose you have a six-person team doing a two-week or ten day sprint. You think team members can productively work for five or six hours per day. (The rest of their time goes to meetings, discussions, corporate overhead, and so on.) A six-person team with a 10-day sprint and five to six hours per day will complete 300 to 360 hours in a sprint. So perhaps this team should target identifying 250 hours of work during the planning meeting.
Team members will work the full 300 to 360 hours of productive time during the two weeks. The 250 is just the amount that can be identified up front at the start of the sprint. The rest will be discovered as the team gets into the work.
