8

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

|improve this question
  • 2
    Your question is based on a misunderstanding of what "should" means – Dave Hillier Nov 7 '13 at 15:18
  • 3
    You're talking about 120 man-hours of work per developer. You don't want to spend 2 hours per developer to plan that work? – CodeCaster Nov 7 '13 at 15:28
  • 3
    A lot of the numbers (1 minute to estimate tasks, 1 task takes no more than 1 day) are rules of thumb. If it's a task you've never done before, it'll take longer to estimate. Some tasks will take less than a day while others take more than a day. More complex stories might be broken down into more tasks than simpler stories. I don't think there's a good answer for the number of tasks in a sprint or how long it'll take to estimate them. – Thomas Owens♦ Nov 7 '13 at 15:40
  • 3
    This is not a duplicate, that other question has an entirely different direction. I tried to clarify the question. – Cephalopod Nov 7 '13 at 16:44
  • 3
    Definitely not a duplicate of the question on record. This question is about tasks, the other is about stories. They are about as similar as functions and programs. – Bryan Oakley Nov 7 '13 at 23:55
9

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.

|improve this answer
  • I think its generally (not horribly) useless for experienced scrum teams, but a valuable tool for new scrum teams that are still learning how to estimate stories. – Bryan Oakley Nov 8 '13 at 12:17
  • 1
    Do you wish to elaborate? I feel that estimating in hours is wasteful, because people are bad at estimating in absolute numbers and there is no meaningful cost-effective way to get better at it. We are relatively good though at estimating how much bigger one story is than another (relative numbers). So the sooner people get rid of the tendency to estimate everything in hours, the better. I also feel there's far to much emphasis on estimation and not enough on creating a pull-based flow system (essentially doing as much as possible in a timespan and stopping when the client is satisfied). – Stefan Billiet Nov 8 '13 at 12:29
  • 1
    In my experience, we are really good at estimating in hours, when the work is well known and small. "Rebuild the database index" - 1 hour. "Add new icons to the toolbar and menus" - 2 hours. If tasks are so large that they can't be estimated, they are too large or too poorly defined. The exercise of estimating helps young teams make sure they are thinking about all of the work: did we remember to add tasks for testing? Did we think about adding it to the installer? etc. The goal isn't to be good at estimating tasks, but at estimating story points. Estimating tasks is a learning aid. – Bryan Oakley Nov 8 '13 at 13:07
  • Fair point, but is rebuilding the DB index really going to take 1 hour? Because saying so implies some absolute time limit for that task. It creates expectations and can lead to all sorts of nasty blame games when it winds up taking half a day. That's the difference between points and hours: "hours" implies absoluteness, "points" doesn't. Besides, how often is knowledge work really known and small? I can imagine it being easier for the team to use hours as a learning aid, but you risk them plateauing on a suboptimal way of working. – Stefan Billiet Nov 8 '13 at 14:03
  • Re "... Saying so implies some absolute time limit for that task". No, it doesn't. The task estimation is just an estimate, not a contract or promise. The individual estimates really don't mean anything at all. In total, however, it should become clear whether your story points are in the ballpark or not. I have seen cases where the initial point estimate of two stories was equal, but one ended up with more than twice the hours of the other. The mere act of trying to estimate tasks brought new information to light. We learned from this, and our story estimation got better. – Bryan Oakley Nov 8 '13 at 14:08
1

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.

|improve this answer
1

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.

|improve this answer
1

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.

|improve this answer
1

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.

|improve this answer
1

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.

|improve this answer

protected by gnat Oct 20 '16 at 10:01

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.