Two months ago my family moved to a house one street over.
In preparation, we invited five different movers to
estimate the work. We told them that we'd do the packing, and move fragile stuff in our car.
Their representatives paraded through our house
with clipboards; only a couple appeared physically strong
enough to have ever moved furniture.
Unlike product development, a house move should be easy to
estimate. It's only manual labour, and the tasks are
obvious and repetitive: load, unload, carry, disassemble
(partially), assemble, etc. The work is additive, with one
person and sometimes two being able to do it all; there is
no magical synergy from teamwork. The drive over was
negligible and nobody had to wait for elevators.
Estimating this work in man-hours actually makes sense. In
our minds, we compared it to a recent move of friends from
down the street.
The lowest estimate was 18 man-hours (“but no more than
27”). Another was 24. The movers my wife knew from work
came in at 36 hours; as this was obviously, outrageously
high, we threw out their estimate. On a friend's recommendation,
we hired other movers whose phone estimate was for 27
hours. In each case, we would pay per hour.
Do you ever participate in a mid-iteration review, or use
a burndown chart, to assess the likelihood of finishing on
time? We did that four hours into the move, and it was
depressing. Our actual move spanned two days and took 42
man-hours. Don't even ask me what this time went to; they
barely took breaks.
I read a book once called The Invention of Tomorrow,
which argued that mankind's biggest evolutionary step was
figuring out that there's a tomorrow, and that it could be
planned for. Planning involves some sort of estimation: we
need to know what would fit when. Pregnant women receive
due-date predictions from their doctors; even though only
4-5% of women give natural birth on their due date, it's
still useful information.
More and more Agile practitioners proclaim that since
estimation doesn't add customer value, it is process waste
and should be abandoned. I'm more concerned with two other
The first problem is that we, as people, are just no good
at it. We're hopeless optimists, always assuming things
ought to work out (life would be rather miserable if we
didn't do that.) Even when we admit some risks are likely,
we struggle mightily to account for them. Our cognitive
biases run in the dozens. And for each type of problem,
there are cases and parameters in which our estimates are never right.
(Read Mindless Eating for a collection of hilarious
examples involving food and drink.)
The second problem, at least in a software development
context, is that people generally don't want to estimate
work. It's considered a necessary evil. Often, other
people discredit or modify their numbers (remember
“obviously outrageously high”?) And work estimates have a
nasty habit of turning into commitments. How else to
explain our made-up word “guesstimate”?
So, estimation can be helpful, but it has a lot going
against it. What to do? Agile/Lean approaches have some
1. Don't bother estimating the very small (i.e. tiny
tasks) or very large (big stories / epics) because you'll
be off by a lot. Instead,
consider more palatable pieces, those in the range of a
few days to a couple of weeks.
2. Don't try to predict too much. Work iteratively so you
gain data on progress. You'll learn how much you can
accomplish, and what things your detailed planning left
3. Estimate collaboratively. Rely on the “Wisdom of
Crowds” phenomenon to smooth out individuals' inevitable
mistakes and biases. For instance, don't let your tech
lead estimate big work alone. This “best practice” is
4. Switch your planning perspective. Instead of asking,
“Here is a story, when will we be finished with it?” ask,
“We have two weeks; what valuable subset of this story can
we finish in two weeks?” This is time-boxing instead of
5. Shift the emphasis from tasks to value. If your team
gets hung up on detailed sprint planning with minute task
estimates (as many teams do), focus instead on the sprint
goal and commitment. Which stories will you finish? What
value will you deliver? How will you make a difference?
With enough repetition, actual value delivery will indeed
be perceived as more important than finishing tasks.
Copyright © 2013-2016, 3P Vantage, Inc. All rights reserved.