Ignore rather than respect estimates
This is the 15th post from my sincere dev manifesto series.
Estimates are more or less elaborated guesses. They are not commitments or indicators.
They can be about cost, risk, expected benefits. They are the best we can get about these three properties of a task. For example, we can estimate:
- The date a feature might be ready.
- The cost of a task.
- The expected value of a feature.
- The opportunity cost of not doing something.
- The risk of adding one more feature or line of code.
- The risk of missing a deadline.
Estimates are everywhere. For example, even if you don’t use man.days or story points, deciding whether a ticket is small enough is an estimate. If you use lead time, you estimate that the tickets in progress look enough like the ones in the past. Discussions about refactoring are only about estimating cost, benefits, and risk, even when they contain actual stories.
Estimates can have several benefits:
- The act of estimating helps understanding the problem and its constraints.
- Estimates help taking go/no go decisions, or prioritizing.
Once these decisions are made, the estimates that helped take those decisions are useless, if not harmful. Knowing we are three times slower than estimates while developing is useless. Doing better than estimates is a waste. Past estimates are now obsolete, and considering them when discussing future decisions is like planning a trip to the moon from a flat earth.
Once we committed, knowing we don’t progress at a rate that would allow meeting our commitment is useful. It is a signal for the need to discuss or renegotiate commitments. But this is a new estimate, based on the current context.
I commit to ignoring estimates once they are communicated and digested.
AAAgile 
One comment