A couple of weeks ago, I participated in a painful sprint planning meeting. You might have been in the same type of meeting. The team was going to great lengths to identify every task they'd need to do in the sprint. And they were debating endlessly over the precise number of hours each task would take.
That level of detail is not necessary.
The purpose of sprint planning is to select a set of product backlog items to work on and have a rough idea of how to achieve them. Achieving this does not require the team to know every task they'll perform. And it certainly doesn't require the team to know if one of those tasks will take four hours instead of five hours.
The Answer Is Not “It Depends”
I’m frequently asked how long teams should spend in sprint planning. Rather than give some crappy answer like “It depends” or “Just enough that your sprint is well planned,” here’s a practical way to determine if you’re spending the right amount of time in sprint planning ...
From looking at planning meetings over many years and at teams I consider successful, my advice is that teams should identify about two-thirds of a sprint’s tasks during sprint planning. That means one-third of the tasks that will be done during the sprint will be left to be identified during the sprint.
An Example
Consider this as an example: At the end of a sprint, a team has finished 60 tasks that delivered some number of product backlog items. My recommendation is that about two-thirds of those tasks (40, in this case) should have been identified during the sprint planning meeting. The remaining one-third (20 tasks) should have been left to be discovered during the sprint.
Sure, the ScrumMaster could have locked the door on the planning meeting and made the team think harder and longer, and they would have come up with perhaps another 10 tasks. But at what cost? It’s not worth it. The goal in sprint planning is to select a set of product backlog items to deliver during the sprint. The secondary goals are to get in and get out of the meeting as quickly as possible.
If your team is accustomed to filling your sprint extremely full, you may need to back off of that a bit. Leave the sprint a bit less full. In Agile Estimating and Planning, I’ve referred to this as “unplanned time.”
The idea is that your team is going to plan a sprint by more quickly identifying all the big things they need to do. Some little tasks will remain unidentified. Some could be identified if the team thought harder and longer--but it’s not worth it. They’d never think of every task, anyway.
Get in. Get out. Get started.
Leave Space for Unplanned Work
Leave room in your sprint plan for the tasks the team hasn’t thought of. Leave room for the tasks they have thought of but that might get bigger. How much room? Take a guess. Next sprint, adjust that guess up or down and iterate to about the right amount over a few sprints.
Note that I am referring to the number of tasks, not the hours within the sprint. The tasks that a team does not think of during sprint planning will tend to be smaller tasks. No one forgets “program the thing.” They forget the smaller tasks associated with that.
