The Art of Estimation

The bedrock of planning is estimating how long work will take. Stories and
tasks are great, but eventually the rubber has to meet the road. Estimation is a
strange thing. It's guessing based on our experience. The more experience you have
in a given context, the better your estimates will be. If we've done exactly the same
thing before on the same project, we use what Beck and Fowler call "Yesterday's
Weather" to make our estimates (that is, we just assume the same estimate this time
around). If we haven't, we look for similar experiences on the same project and
estimate from them. Only as a last resort do we just guess.
That said, estimation can be tough. This is especially true when people are
working with new technologies and/or in new environments. Tell people to keep it
simple. Break stories down into very small tasks (remember the guideline of 0.25 to
two days we mentioned in The Iteration Planning Game). If the sum of the days for
the tasks in a story add up to longer than a week or so, have your customer split the
story. This exercise will help people do a better job at two things:
1. breaking down stories to make sure they know what will and won't be
accomplished
you will improve with practice. On a recent project, Ralph Johnson made the
astute observation, "There is nothing that you can't do better the more you do it."
Your estimates won't ever be perfect, but you can hone your skills. Before you
know it, people will start to take your estimates and plans seriously as they get
closer and closer to reality.
What's Velocity?
Estimating is the art of determining how big some effort is. That's not worth
much unless you also can tell your customer when they'll get it. That's velocity.
Velocity tells you how fast your team can produce the stories required by your
customers in a single iteration.3 The Planning Game and the Iteration Planning
Game tell you how much everything costs. The Tracker or the Coach or the Manager
then specifies the velocity of the team, based on past performance. No other basis
makes sense. Beck and Fowler describe this as "Yesterday's Weather": assume new
stuff that's like stuff you've already done will take just as long to do. If your team
delivered seven stories in the last iteration, assume they'll do the same the next time
around. It's that simple.
There are several ways to express velocity, but they all answer the same
question: how much can your team get done in a single iteration? The two major
candidates appear to be these:

 ideal days

 some sort of "story points"
The reason these sound different is that they are based on different inputs. The
ideal days form says that your team can produce a certain number of ideal days'
worth of stuff in an iteration's worth of calendar days. The "story points" approach
says that your team can produce a certain number of points (a simple way to express
"bigness", or difficulty) in a single iteration. Six of one, half-dozen of the other,
really. Pick one and go with it.

We express velocity in terms of deliverable units per iteration (DUPI), which is
our version of story points. As we said earlier in The Planning Game, each
deliverable unit is about one-half a week of ideal days for one developer. No story
may span more than what a single developer could do in an iteration. We assume a
load factor of 2.5. That's our starting point for all projects. We can adjust up or
down based on the individual project, once we have some experience in that
environment.Given those inputs, each developer can handle roughly 8 DUPI in a
four-week iteration, or 6 in a three-week iteration
This approach standardizes our measurements. The size of each story is a
multiple of a known quantity. There's lots of ways to express it:a single deliverable
unit, an ideal day, or "about half a person week". Load factor can vary by person, but
we usually state velocity in terms of the team as a whole. We tell the customer our
collective velocity: for example, 32DUPIs per iteration. When we start an iteration
we figure out how many days of the iteration each developer is expected to be
present, take into account other distractions they'll have to adjust their individual
load factor, and total up the days we expect that iteration. Here is an example:
Developer Days Available Load Factor Deliverable Units
Joe 15 2.5 6
Nathaniel 18 2.5 7
Ken 10 2.5 4
Amy 19 4 5
Duff 16 2.5 6
Donna 20 3 7
Totals 35
When we estimate, one of us throws out a number of ideal days for a story, we
discuss it a bit and put a number up. If the stories add up to more than the available
days, we cut some out
Beck talked about "load factor" in XP Explained. Load factor is the multiple you
use to get from ideal programming days to calendar days. If you can get eight ideal
days of work done in a 20-day iteration (4 weeks), your load factor is 2.5 (8 / 20). In
Planning XP, Beck and Martin forsook load factor somewhat, and claimed velocity
is the only measure you need. We tend to agree, but we think it's nice to be able to
derive both, just in case you have to estimate how long a short-term project will
take.

Estimation Rules?
Bill Wake says 1/3 story per week per developer and tasks should be less than 3
days . Ken says estimate a load factor… it's not that complicated. Kent says "use
yesterday's weather"? What's best?
You just gotta find something that works for you and recognize that "estimation"
will NEVER give "exact predictions".