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.
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.
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.;