You can't put ten pounds of shit in a five-pound bag. | ||
| --Anyone who has tried | ||
As the basis for your planning, assume you'll do as much this week as you did last week.
How big is the bag? This shopping metaphor is all well and good, but what is the budget? How much do you commit to doing in the next n months?
If you commit to too much, development proceeds under a cloud. The programmers know they are doomed. They don't do their best work. They don't communicate clearly. The political sophisticates play Schedule Chicken, where the first person to point out the impossibility of the task ahead is labeled a loser, not a "team player."
Okay, we don't want to do that. Neither do we want to undercommit. If it turns out we can go twice as fast as we thought we could, the business will take a while to catch up. The press releases won't mention half of the cool new features. Sales won't understand what all is in the product. And it is a matter of pride for programmers to put out 100 percent.
How can we navigate such an emotional and business minefield? How can we come up with a complicated rule-making apparatus that accurately captures and balances all the technical and emotional information that is available?
We don't—surprise, surprise. Instead we opt for a simple rule that works pretty well in most circumstances:
Say you'll do as much tomorrow as you actually got done today.
Here is an apocryphal story. Some country's weather service (not yours, but perhaps ours) spent a bazillion dollars on a sophisticated new weather prediction system. Lights flashed, cards spewed, tapes spun, and out came predictions that were about 70 percent accurate. The people who authorized spending the bazillion dollars were quite impressed.
Then one day someone noticed a simpler way to get the same accuracy. Every day predict that tomorrow's weather will be exactly the same as today's.
That's why we call our rule Yesterday's Weather.
Assume for the moment that each feature you are going to implement takes the same amount of effort (see Chapter 12 for what we really do). If we did five features last month and we're asked how much we can do this month, we say "five." If we have gotten three features done every two weeks for a while and we're asked how much we can do in the next six months, we say "3 features/iteration × 2 iterations/month × 6 months = 36 features."
Here are some of the emergent properties of this rule:
We won't habitually overestimate our abilities. We have to use actual accomplishment. If we overestimate once, we won't be able to the next time.
If we are overcommitted, we will tend to try to finish some items in any given time period instead of half finishing them all. It is so embarrassing to tell the customer they can have zero features next time.
On the other hand, if we have a disastrous period, we are guaranteed a little breathing space to recover.
Everyone learns to trust our numbers because they are so easy to explain.
Our estimates automatically track all kinds of changes—changes to the team, new technology, dramatic changes in product direction.