This is the fifth and last of the 5 Laws of Software Estimates. I expanded on the fourth law of software estimates in my previous article.

Like all things, how you view estimates is heavily context-dependent. If you're a developer who wants to maximize the amount of value you provide by building software, estimates do little to support this directly. As already covered by the previous 4 laws of software estimates, there are a lot of limitations to estimates. However, if you're a business owner or a stakeholder in a software application, you may rely on estimates in order to plan. You may have a release schedule you need to coordinate, or an inflexible deadline you need to hit, and since you can't reliably gauge the amount of effort or time needed to build things, you need someone to provide you with information, flawed and costly as it may be.

Estimates may be used as the basis for bids for contracts. In this scenario, it's very easy to confuse an estimate for a commitment because once it's part of a signed SOW, that's often what it is! If this is the case, it's probably worth taking extra effort to ensure you don't significantly under-estimate the scope of work that's being committed to by the team. However, it's also worth remembering that time and materials estimates are only one approach to bidding for software work, and that value based pricing is often an option that may be more attractive to both the buyer and seller. Jonathan Stark has a lot of great content on this topic if you'd like to hear more about how it's done.

Sometimes estimates feel necessary but really aren't. For instance, it's frequently the case in Scrum teams that estimation is needed as part of backlog grooming so that the product owner can prioritize the backlog. Ultimately this determines what does or doesn't get planned for a given sprint. A small user story of equal value to the business with a large one is likely to be prioritized higher, since its ROI is potentially better. However, due to the inaccuracy of estimates and the fact that frequently multiple stories end up depending on one another, it's not always that simple. In fact, if you're spending much time on estimates just so you can fit this or that one story into this sprint or the next one, or so you can fine-tune your velocity measures, consider not estimating as an alternative. Instead, break down every story as small as you can, and prioritize them by importance to the user or business. Your average number of actual stories completed becomes your velocity metric, and as long as you're keeping stories down as small as you can this average will work just fine for this purpose. And the extra time you saved by not estimating means that instead of deciding if this or that story on the cusp of the sprint makes it, you can do both because you just saved a few hours of developer time by not estimating. Win-win.

When they're really necessary, estimates should be treated as actual deliverables, not just a number to drop into a task tracker. Make sure it's clear what assumptions are a part of the estimate, who made it, when it was last reviewed and revised. Don't estimate as a matter of habit, but keep in mind the goal. What decision is the estimate going to improve? How can you make the estimate better such that the risk of making the wrong decision based on it is lessened or mitigated? Estimates aren't free, but sometimes are necessary, so be sure you're getting your money's worth out of the effort that's put into producing them.

Learn more about the 5 Laws of Software Estimates, and share your own experience in the comments below.