Scrum Planning – How to Estimate Tasks in Scrum

planningscrumuser-story

Let's say we have a backlog of User Stories, each with an estimated number of Story Points, and now we're doing the Sprint Planning.

Now, the Stories should be broken down into tasks and many Scrum resources suggest that each task should be estimated in person-hours. Since all questions have been discussed by the team at this point, estimating a task should not take longer than a minute. However, since a task should not be longer than a day, assuming a three week sprint with 8 developers means 120 tasks, and taking two hours only for estimations seems to be a bit much to me.

I know that experienced teams can skip or short-cut task estimations, but let's say we're not at that stage yet.

In your experience, how many tasks are there in a sprint and how long should it take to estimate all of them? (Estimating only half of them doesn't make much sense, does it?)

Clarifications:

I know the answer depends on sprint length and team size, so let's assume 8 developers and three weeks.

The numbers mentioned might be rules of thumb, but even if they are off (eg, more tasks, less time needed to estimate each) we will end up with about 2 hours for the estimation. So maybe the question should be "What percentage of the planning meeting should be reserved for pure task estimation, and don't we have better things to do?"

Best Answer

Frankly, I think that if you're asking this question, you're indeed not entirely convinced of the use of sprint planning.
The point of sprint planning is to get the team into a state where they feel comfortable committing to a given set of user stories, where they feel they know enough to get started. Wether that takes one hour, or 2 of 4 or the whole day is completely beside the point; it will be done when it will be done.
Say you want to shorten it and limit it to 2 hours. The fact that they need information will not change, so you will inevitably wind up with portions of what used to be sprint planning, smeared out over the rest of your sprint.
In the end, all that matters is that the team can commit to some work and actually deliver that work to the satisfaction of both themselves and the other stakeholders. All the rest doesn't matter. Focus on what actually delivers value, don't focus on vanity metrics.

P.S.: no matter how much literature indicates you should estimate tasks in hours, I still find it to be a horribly useless and counter-productive idea and I know I'm not alone in this.