Sprint Planning NOT Sprint Marathon - Mike Cohn

Do your sprint planning meetings drag on and on? Do you joke that the team must be trying to plan a marathon rather than a sprint?

You are not alone.

Some teams struggle with planning because they aren’t taking the time to refine. You can read about some ways to tackle that problem in this blog.

But today let’s help the teams that struggle with planning because they are just trying too hard to get it perfect. There’s no need to be perfect. Going into too much detail with each product backlog item or trying to estimate too precisely wastes everyone’s time without adding value to the sprint.

Perfect sprint planning does not mean the team has thought of every task. Perfect sprint planning means the team has perfectly figured out what set of product backlog items they can do during the sprint.

Think about that for a moment and let it sink in. Being perfect is not thinking of every task. Being perfect is knowing the right set of product backlog items that can be delivered in a sprint.

In my experience, a team doing a good job of sprint planning will identify only about two-thirds of all the tasks its members will do during the sprint. So the team leaves the meeting having failed to identify about one third of all the tasks they’ll do that sprint.

And this is a good thing. The team could spend more time planning the sprint and identify more of the work, but it’s not worth the extra time. Teams typically don’t miss the big to-dos, just the little ones. That’s why there’s no need to try to think of every small task.

Here’s something to try next sprint to see how you’re doing. Start by measuring the percentage of tasks your team identifies during sprint planning.

This is an easy metric to collect. Simply count the number of tasks identified during sprint planning and then count the number of tasks that have been identified by the end of the sprint. Divide, and you’ve got the percentage your team is identifying during sprint planning.

Did you find your team is identifying more than two-thirds during sprint planning? First, congratulate them on doing such a great job of identifying work that needs to be done. Then try shortening their sprint planning meetings. They can probably get by with spending a bit less time in sprint planning.

But if you do the math and find your team identifies only half of the eventual tasks during sprint planning, your team will probably benefit from spending a little more time in the sprint planning meeting. The team is underestimating the effort required to complete the product backlog items, which means they are probably bringing in more work than they can deliver.

By knowing the percentage of tasks your team identifies during sprint planning and by remaining focused on the true purpose of sprint planning—selecting the right set of product backlog items to bring into a sprint and discussing them just enough to successfully implement them—you can help your team succeed with agile,