How to estimate tasks in scrum?

Question

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?"

Answer 1

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.

Answer 2

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?)

This is a bit like asking how many raindrops are in a thunderstorm. There is absolutely no way to answer this question, even if you talk about two different storms of the same size. There is no rule of thumb, no matter what the team size or sprint size.

The point of estimating hours in tasks is so that the team can learn to better estimate their stories. For example, consider two stories that you have estimated: one is estimated to be a 2, and one is a 4 or 5. When you start tasking it out you realize that both have roughly the same number of hours assigned to the tasks. What does that teach you?

The only rule of thumb I think I can give is, if your team has a stable velocity, you don't need to estimate tasks. If you find that your velocity is unstable, it's likely because your estimation skills are weak. You can strengthen them by breaking down stories into tasks at planning time as a type of sanity check for your estimation.

In your question you say your team isn't there yet, so estimation is important. If that's true, don't worry about the time you spend doing it. It will take as long as it takes. You are making an investement in your team. Yes, it will take a lot of time at first, but hopefully you'll learn from the experience. You may learn it's a waste of time, or you may learn that you're not as smart about estimating as you think.

Remember: scrum isn't a set of rules you must follow, but a set of tools to help you plan and organize your work. Any time that these tools are getting in the way of your productivity, you should stop using them. Make sure they actually get in the way of your productivity rather than give the appearance of doing so.

Answer 3

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.

To me this means 8 developers spending 15 minutes to plan for the next 3 weeks. That's too much? That's like a daily stand up.

It's an estimate. Plan your first sprint. Take good notes and measurements. Your first sprint will probably be way off the mark. If this is a problem, put the time and necessary steps it takes to improve the next one. Are tasks taking longer than expected? Can each dev do as many tasks in a given sprint as they expected?

Be open and honest about what was really getting done and how long it took. If people are fearful, they'll just game the system. You'll be basing your planning decisions on bad data. If too many tasks take more than a day (or whatever you thought they should take), determine if they were broken down to small enough pieces.

Your devs may not have a full 8 hours a day to work on tasks or whatever that magic number management wants to hear to feel they are getting a full days work for a full days pay.

Would it be such a horrible thing to discover after 2 weeks you completed a 3 week sprint or you only completed 75% of the tasks at the end of the sprint? Learn from the unexpected (This is estimation, so let's not dwell on them and call them mistakes.).

The goal is to make the customer happy in the context of what they want done in the given time and resources. It's not to suck the will to live out of every programmer you have to complete this project.

So to answer your question: Just do your best to estimate your first sprint. Learn from it and adjust the next one. Repeat.

Answer 4

My own opinion is that the task hours estimating is wasted time in sprint planning. Generally, the estimates are wrong, and I get no value on reporting on them. However, many agile task tracking tools use these hours to generate burndown, so we need something in there.

To save time, I started following this process:

1. Set each task created to "1 hour" as soon as the task is created.
2. As developers tackle tasks throughout the sprint, if they think it takes more than the one hour on the task, they can update it to a more realistic value.
3. As tasks get completed, burndown reports update on hours remaining.

You'll still have the ability to see how progress is going, and whether you are on track, but you can use your sprint planning time for more valuable actions like understanding the stories and figuring out what tasks have to be done.

Answer 5

TL;DR

[H]ow many tasks are there in a sprint and how long should it take to estimate all of them?

Your question has no possible canonical answer. While you can certainly use some rules of thumb to calculate a reasonable upper bound for task volume, there's no universal conversion ratio for stories to tasks, or tasks to man-hours.

For example, a commonly-accepted rule of thumb is that a task should be sized between a half-day and two days so that the done/not-done feedback loop remains tight. Teams can and do violate this rule of thumb, as it is not a framework requirement, but the most successful teams I've worked with all follow the spirit of this rule.

Tasks Per Sprint

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

This is axiomatically wrong, since the number of tasks is dependent on the number of stories and the quantity and granularity of each story's decomposed tasks. Nevertheless, you can calculate a rough upper bound for sanity checking.

If you assume a priori that:

• each task requires only one developer (this is often not the case)
• 30% of your sprint is consumed by framework overhead (this number varies by sprint length)
• you aren't applying any fudge factors for the fact that productive work hours are generally <= 6 hours per work day

then you have 10.5 "days" available for tasks per developer to allocate to tasks in each sprint. Further assuming:

• 8 developers
• all developers are interchangeable
• there are no queuing activities or dependencies between tasks
• you are including Definition of Done activities as explicit tasks

then following the recommended task-sizing rule would give your team a capacity between 21-148 tasks per three-week sprint.

Avoid Estimating Tasks in Man-Hours

The simple solution here is to avoid estimating tasks in ideal man-hours and toss all the problematic (and often inaccurate) assumptions overboard. By simply not accepting stories into the sprint that exceed your sustainable velocity, you solve most of your sprint planning problems without estimating in hours.

By ensuring that your stories are decomposed into properly-sized done/not-done tasks of no more than a couple of days, you can quickly see if you mistakenly accepted a story that is more complex than your story-point estimate, or if there was hidden work that needs to be documented and re-scoped with the Product Owner during Sprint Planning.

Healthy teams dedicate about half a day to decomposing tasks for the Sprint Backlog. If you don't take the time to do this in the second half of Sprint Planning, then you are much more likely to uncover entanglements, unexpected dependencies, or unplanned work later in the sprint.

A four-hour Sprint Backlog meeting represents less than 3% of your three-week sprint length, and is where most of the design and architectural analysis is done within the Scrum framework. Is shaving that down to 2% by short-changing the task analysis really worth the risk to your project? I'd say no, but your mileage may vary.

Answer 6

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.

Your assumption isn't right because not all team members participate in planning each task. In fact for stories, all members participate in estimating all stories but for tasks, usually a couple of team members estimate each task.

So if in your example, each two members estimate a task, It just takes about half an hour for estimating all of them.