Using Hours Instead Of Story Points

Industrial Logic used hours for our estimates while building our Refactoring to Patterns Interactive (http://www.industriallogic.com/rtpdata/index.html) product. At the time, we used a spreadsheet (we now use ProjectCards) to keep track of our iterations. The spreadsheet contains copious details about our hour estimates during the project.

During the early days of the project, there was significant push-back to using hours. I thought that we had to experiment with hours, since we have to experiment to keep learning. The group agreed so we kept the experiment going.

We kept track of everyone's Available Hours (e.g. I'm at a conference Monday-Tuesday and can work on the software Wed-Friday, so my available hours are 3-days worth of work, or 21 hours).

We summed individual Available Hours to get a number for the group's Available Hours.

We estimated all Iteration Stories using hours. We summed all the estimates to see that they did not exceed our Available Hours.

We then kept track of what we called Achieved Hours. That means how long did the work actually take us. We initially did nothing with the Achieved Hours number. That is, it did not effect our planning for the next iteration. Over time, people on the project insisted on adding in a "load factor" based on our history. So a load factor was multiplied against our Available Hours. When that happened, the hours started to feel less like hours and more like points.

Here are some real numbers from the first 15, 1-week iterations of the project:

Iteration # -- Available Hours -- Achieved Hours.

01 -- 34 -- 21

02 -- 15 -- 25

03 -- 31 -- 24

04 -- 25 -- 00 (slammed by other work, couldn't work on the software)

05 -- 16 -- 00 (ditto)

06 -- 47 -- 39

07 -- 74 -- 37

08 -- 50 -- 43

09 -- 49 -- 46

10 -- 76 -- 53

11 -- 59 -- 47 (load factor introduced)

12 -- 27 -- 33

13 -- 43 -- 43

14 -- 33 -- 35

15 -- 77 -- 77

Throughout the project, we did iteration retrospectives. During those retrospectives, I recall many many discussions about points vs hours. There was a lot of discomfort. Ultimately, the guys felt compelled to add the "load factor" into the Available Hours equation at iteration 11.

During our end-of-project retrospective, conducted by the wonderful III, it became clear that folks truly disliked using hours for estimates.

So we are now back to using points. We continue to accomplish a lot of good work and the points give us a good idea of what we can expect to get done from iteration to iteration.

Speaking for myself -- I did not mind estimates in hours. However, I really disliked that others were so uncomfortable using hours. So since the vast majority of folks on our projects prefer points, I'm more than happy to use points. Furthermore, this experiment has helped me to see the wisdom in continuing to recommend points, instead of hours, to the majority of our clients. --JoshuaKerievsky

Some folks asked me what the people on the above-mentioned project specifically didn't like about using hours. Here is a summary:

Hours didn't feel elastic: Its too easy to break down an hour into minutes, and too easy to get too granular. Where a point is vague enough that it offers some elasticity.
Hours often ended up feeling like hard time commitments rather than estimates, as the end of an hour approached I would get stressed if there was still more work to do. I didn't feel that with points.
Discussions about hours often made me feel micromanaged and not trusted.
I never witnessed any planning advantage over StoryPoints.
Humans suck at estimating time, but we are pretty good at estimating relative difficulty ( e.g. X is twice as hard as Y). Using points forces everyone to think relatively. And (bonus) there's no need to recalibrate all our estimates when it turns out we're going slower than we planned (which sometimes happens, I hear).
With hours, we measure our progress and declare something like "we're doing 22 hours per week". This can annoy (why aren't we going faster?), confuse (wait, is this in actual hours or ideal hours?) or even anger (this is a team of slackers!). But a statement like "we're doing 22 points per week" doesn't generate these same emotions. It may elicit initial confusion (what's a point?), but that's just an opportunity to explain what's really going on.

--JoshuaKerievsky

I only use time when there is a problem with divided attention: people having multiple projects, for example, or being pulled off to go to company meetings on a large scale. In that case, though, I track the time as time and don't necessarily use it to make estimates. Example:

We estimated we could complete 10 story points in a one week iteration, but only completed 5. We estimated that we would have time for 14 pairing sessions in the week, but due to time pressure we only got to use 7.

So... we paired for 50% of the expected time and got 50% of the estimated points done... that means our estimate is off due to our failure to spend the amount of time expected rather than other factors like not understanding the scope of the stories.

In the next iteration, we could

Use 5 points if we expect the drain on our time to continue
Use 10 points if this seems to have been a one time thing
Revise both the time and the point estimates, if that seems appropriate

A couple of "points" should be mentioned: 1) I use pairing sessions rather than hours because hours are harder to track and give more of a sense of precision than is justified 2) I typically do this for two weeks, as problems arise - it's intended to deal with a specific problem and not as a general approach.

-- CharliePoole