http://bit.ly/1DLPa5D (original) http://bit.ly/1dsePQq (license)

Photo by Lars Plougmann

A discussion popped up on a Scrum / Agile forum I frequent on the subject of estimating tasks on Product Backlog items, specifically estimating them in hours. The poster had a straightforward query:
“Do you all who estimate User Stories in story points also estimate tasks in hours?”

He is likely deciding if he should champion this sort of estimation on his team(s). I answered that, on my teams we estimate both user stories and task hours. The PBI’s get pointed relatively as is pretty normal with Fibonacci numbers. During Sprint Planning, we create tasks as small, cohesive bits of work. They are small enough for one day of work and embody a single, conceptual chunk of effort. We estimate time in hour chunks of 1, 3 or 6 hours. The coarser granularity helps us avoid wasting time pursuing phantom value in precision and gets us out of planning fast! For a 2-week sprint, we are typically done with planning in 1-2 hours. We re-estimate the hours on tasks as needed after the Daily Scrum and use them as metrics to visualize our progress and to sum remaining effort in the sprint at any time.

Some of the other responses made sense, yet others shocked me.

Some volunteered that they also used hourly estimation but that as teams grow in effectiveness, it becomes less needed. Alternately, as the complexity of the domain or the technology decreases, the work of estimating tasks also becomes less valuable. Some said that they use capacity tracking to gather metrics on what their developers are doing and for how long work actually took. Some even took a hard line stance that, not only should effort never be estimated in hours, but that there is no POSSIBLE value in doing so.

That last one got my hackles up…but I had no idea why.

These days, when I get worked up over a drastic difference of opinion, I go through the following cycle:

1) State my Opinion
2) Hear a Rebuttal
3) Get Angry
4) Keep my Mouth Shut for a bit!
5) Wonder why I’m Angry
6) Settle down
7) Learn something

On my team, we don’t estimate our PBI’s tasks in points. Points are a relative estimation tool for estimating effort. The Scrum guide mentions that Product Backlog items are items that have description, order, estimate and value. During Sprint Planning, the team produces a forecast for how many PBI’s they can accomplish in the Sprint. Next, the whole team creates a Sprint Goal after which the Dev team forms a plan for how they are going to accomplish the Sprint Goal.

We create tasks with hours. Except for a brief stint without hour’ed tasks, we have always done this. In contrast, Andrei and others see little or no “possible” value in estimating hours. I think angrily, “Has my team wasted all the effort we have expended over the past couple years on these task hours? Surely not! What kind of idiot would do that. There has got to be some value…right?”

And there it was, the reason I had gotten so angry.

I will grant detractors that hours won’t always bring value as a team matures, especially if that team is committed to improving itself and its processes. In doing so, it will get better at estimating, dicing up PBI’s, etc. until eventually, they will transcend the need to specify hours on tasks. Unfortunately, this takes time and rigor and is frankly beside the point. If a team decides it wants to use hours on tasks to self-organize and even marginally improve a process, then value will be realized, though it may only be in the form of a team affirming its commitment to improve; if tracking hours turns out to be a terrible idea, this continually improving team will retrospect and figure out why it failed and throw it out.

Like Edison and his 10,000 attempts at the light bulb, the optimistic, ever-progressing team is held back not by its mistakes, but by their capacity to resist the urge to give up.

Back to hours on tasks, I have seen teams gain value by using hours to estimate tasks, and I have seen teams waste effort doing it as well. A team struggling in a Daily Scrum to consistently form an accurate plan for the next 24 hours may well be helped by the additional rigor that thinking through work enough to estimate hours will require. A team struggling internally with trust may need the exposure that having their unfinished or impeded work exposed as an ice burg of remaining work will bring. I could go on listing counterpoints, but the point is clear to me: estimating hours on tasks can absolutely bring value and safely, so long as the team has a need for it and a pattern of improvement.

What the OP needs to hear is, “It depends, and here is what I have seen…”. If this rebuts your opinion and makes you angry, then consider keeping your mouth shut for a bit, wondering why you are angry, settling down, and hopefully learning something.


Jason is a developer, Scrum Master, writer, teacher, coach, husband, father, and community leader out of Tulsa Oklahoma. He's been delivering software since 2007 and absolutely loves the values and principles of agility especially as given form by the Scrum framework.