11 Laws of Agile Estimation

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