Estimating: How Hard Can This Be?

One of the most difficult aspects of working with velocity is convincing developers to estimate consistently. The velocity factor includes all the variable parts of team performance: experience, knowledge of the problem domain, team size, adding and removing team members, interruptions, and so on. If the planning game is to result in realistic schedules, stories should be estimated consistently in terms of their relative required effort. Developers should not try to adjust their estimates.

The coach asks the players to estimate by comparing with other stories. If a story looks twice as difficult as another story, estimate it at twice the difficulty. The mix of stories proposed in the documentation contains stories that are suited to demonstrating this. For example, folding eight boats will probably take twice as long as folding four boats. There are also several stories that have the same complexity. For example, throwing a six five times is obviously exactly as difficult as throwing a four five times.

But it's not always that easy. Building a two-story house of cards is more than twice as difficult as building a one-story house. And finding two missing cards from a full deck is about as difficult as finding one, if you sort the cards.

Estimating how long it takes to perform these little tasks is difficult. Developers already know estimating is difficult. For some customers, it might come as a surprise to learn how hard it is.

One way to improve the estimates is to do short experiments, called "spikes." You could implement these simple stories completely as a spike. With real stories, this is not possible, so we give the players only a limited time (for example, 15 minutes) to come up with their estimates.