Recently, new Scrum teams in one of the world's largest healthcare
companies decided to measure burndown in their sprints only by story
points for the companies most critical project with a hard delivery
date that was one year earlier that the predicted waterfall date. They
only burned down when a story was done and done meant fully tested at
the functional level, not just unit tested as at many companies. And
they met the date, one year early.

Why? Because they understood that tasks complete with stories
unfinished just means a lot of work in progress with potential major
integration problems when you really test the code in a global build
of the system. Also they know that one hour of work for one developer
could be 10 hours of work for another developer, that research shows
that hours have no relationship whatsoever to quality and that one
team may be disrupted and take 10 hours to do what another team might
need 250 hours to do. Hours are completely useless as a measurement
except when you have to cut a check to a consultant whether he
delivers anything or not. You certainly don't need them to pay
developers since they are paid the same amount every month independent
of hours they work (or stuff they have delivered).

Published research shows that hunans are terrible at estimating
anything in hours. However, they are pretty good at relative sizing.
They know roughtly what S, M, L, and XL t-shirt sizes mean even if
they can't guess the weight of th people. And their brains are wired
for a growth pattern seen everywhere in nature that can be described
by a Fibonacci series.

Therefore, you will get better estimates for anything using Fibonacci
whether they be stories, t-shirts, tasks, or when dinmer might be
ready.

Nevertheless, new teams often have management that demands hours, just
like they used to demand waterfall. It doesn't work but it's familiar
and they are addicted. So it is easier to just give it to them. That's
why I agree with Mike Cohn that new teams might be best at estimating
stories in story points and tasks in hours.

However, at Google in Trondheim recntly, where they are doing
everything in Scrum and the typical developer has been head of the
Internet task force for the last five years, my recommendation was to
forget hours. That would just slow them down. Don't even estimate
velocity as these guys know roughly what they can do and can get to
accurate velocity by measuring it from Sprint to Sprint and use
"Yesterday's Weather" as a best practice pattern for pulling stories
into a Sprint. Only estimate stories in story points and only burn
down completed stories.

Of course, at Google, they have no managers looking over their
shoulder that are addicted to hours, so they do not have the
impediments that most organizations have so they will go faster out of
the gate.

Scrum was designed for extreme performance through inspecting and
adapting. Most high performance teams I have worked with have used
hours in the early days as training wheels and they abandoned them as
their velocity went ballistic.

Last year I asked my Chief Product Owner if he felt uncomfortable that
we were no longer keeping track of hours. He said yes, that some
nights he had knots in his stomach when he went to bed. I asked him if
he wanted to go back to the rigorous hourly measurement that we had
used for several years. He said "No!" When I asked why not, he said,
"It will slow the teams down!" So our Product Owner has inspected and
adapted and decided to accept a "perceived risk" in exchange for
velocity and maximized business value.

Fear not. I still teach how to estimate sprint backlog by measurng
tasks in hours in Scrum training since most of those new to Scrum need
it. In fact, until they can demonstrate they can pass the Nokia test
for doing Scrum they should not think about anything else. But that is
another whole discussion.

--
Jeff Sutherland
jeff.sutherland@...