Chapter 10
Agile Estimation: The Good, The Bad, and The Ugly

Estimation is about setting expectations. When I drive somewhere, I want to know how long I should expect that drive to take. You might say, “It will take me about 30 minutes to get from Point A to Point B.” That’s because you know from experience that it should only take you 20 minutes. And depending on road and weather conditions, it might take you closer to 40 minutes. You split the difference and call it 30 minutes.

That’s a gross estimate, an order-of-magnitude estimate. That’s the kind of estimate your managers want when they ask you for an estimate. Those estimates are accurate, but not necessarily precise.

The team might need estimates, too. If people work alone, not pairing, swarming, or mobbing on the work, the project team needs to understand when this part of the work will be done so that each team member knows when to expect the work. That’s a more precise estimate.

Every team estimates differently from every other team. There are good reasons for that. Sometimes the team members are not stable, so the team has no idea who will work on the story. The team doesn’t know if it will have the necessary expertise to fly through the story or if it will be a slow slog.

Sometimes the team timeboxes an experiment (an MVE or a spike) and after that experiment, the team will know more about the feature set so it can assess the complexity of it.

Sometimes the team doesn’t know about the complexity of the code base. While the feature seems straightforward, the last time someone touched this code was years ago and that person has since moved to Fiji and is enjoying an umbrella drink on the beach.

Teams can provide an accurate estimate if they understand their current reality (what the code looks like), their typical speed (velocity and/or cycle time), and how much work they think this feature will take. If any one of those things is unknown, their estimates will not be accurate. In addition, if the team members are supposed to multitask on features or projects, their estimates cannot be accurate.

In this chapter, I’ll discuss using velocity as a way to guide relative estimation, using cycle time to create rule-of-thumb estimates, and what a team could do if it chose not to estimate at all, the #NoEstimates movement.