In this episode we review an article published by Maarten Dalmijn called the 11 laws of Agile estimation:
- The work still takes the same amount of time regardless of the accuracy of your estimate.
- No matter what you do, estimates can never be fully trusted.
- Imposing estimates on others is a recipe for disaster.
- Estimates become more reliable closer to the completion of the project. This is also when they are the least useful.
- The more you worry about your estimates, the more certain you can be you have bigger things you should be worrying about instead.
- When you suck at building software, your estimates will suck. When you’re great at building software, your estimates will be mediocre.
- The biggest value in estimating isn’t the estimate but to check if there is common understanding.
- Keeping things simple is the best way to increase the accuracy of estimates.
- Building something increases the accuracy of estimates more than talking about building it.
- Breaking all the work down to the smallest details to arrive at a better estimate means you will deliver the project later than if you hadn’t done that.
- Punishing wrong estimates is often like punishing a kid for something they don’t and can’t know yet.
Past performance is not a guarantee of future results, especially when it comes to software estimation. In 1943, at a casino in the USA, the color red won 32 times in a row. It’s easy to fool yourself that there’s some kind of pattern, but this is a classic example of the Gambler’s fallacy