#NoEstimates – Difficulty in Software Estimation

Estimation ToolsIf you’ve heard of the #NoEstimates movement but aren’t clear on what it really means then you aren’t alone. There’s a broad spectrum of opinions about how much estimation is necessary when it comes to software development and the #NoEstimates camp obviously lies at one end of the spectrum. It’s an ideal scenario in which no effort is spent on estimating development effort and all work is done at a maintainable pace. The other end is full break down and estimation before even starting to write a single line of code. I’m going to explore just how realistic the #NoEstimates ideal is and what we can learn from this movement.

Background

First I’d like to address what I believe are the reasons for this movement resonating with software professionals. Software development estimation is hard, every time you build a piece of software it’s something you’ve never built before, otherwise you’d just use the existing software. Generating an estimate must be done by applying your previous experience with writing similar software and your own instinct. There’s no checklist or algorithm you can apply and just add up the numbers to analytically determine an estimate. So it’s really a guess, based on your own experience and knowledge of the problem to be solved.

In my experience if a developer can maintain an average accuracy on estimates to within 2x actual time then they are doing VERY well. Meaning if they estimate four hours for a task and it actually takes between two and eight hours then that was a good estimate. Estimating a large software project involves breaking it down into smaller, bite sized, tasks which can be estimated with this same level of accuracy. So for a one year estimate on a project it could take anywhere from 6 months to 2 years of actual time with this level of accuracy.

I believe a disconnect occurs once a developer gives an estimate to a manager, the estimate means different things to each group. The manager sees this number as a commitment, something that the developer has promised to deliver on. While the developer has come up with a number which they do not, and can not, have perfect confidence in. Both groups are discouraged when invariably the actual time and effort differs from the estimate. The manager because they’ve made commitments based on the estimate and the developer because they missed their own self imposed deadline.

 

#NoEstimates Extreme

Given that software estimates are generally inaccurate, putting effort into generating estimates is a waste of time so why bother going through the motions? Developers should start working on the project immediately and continue until some stop condition is met. It doesn’t mean that progress is not measured. It doesn’t mean that engineering processes shouldn’t be constantly reviewed and improved. Quite the contrary, a piece of development work is going to take the same amount of time to complete whether or not an estimate was made beforehand, however by eliminating one step in the process it can actually be finished sooner.

For a company developing its own product, which needs to release quickly or when dealing with legacy software this concept does make sense. Where this ideal falls flat is when dealing with external dependencies. For example a company may be bidding for a contract with a specific finish date, they want to know if the software team can deliver by that date. In this situation the company requires an estimate, or at least a measure of how confident the team is that they can meet that deadline. Without an estimate the company can’t make an informed decision about whether or not to pursue the contract.

 

A Better Way

Estimates are useful in some contexts, but really only to agents external to the development team itself. Once estimates leave the confines of the development team and work their way up through management they will eventually filter back down as commitments which the company makes to those external agents. Those commitments are certainly meaningful to the development team since they will affect deadlines, resource requirements, project scope, etc. But commitments are now divorced from the estimates they were originally based on.

Some education does need to happen on the management/customer side of the equation to help them understand that software estimation is an inexact process. Longer range estimates are always less accurate that shorter ones. An estimate for a single new feature will be significantly more accurate than an estimate for an entire project. So whenever possible defer estimating until absolutely necessary. Only the next 2-3 sprints worth of work are estimated out for velocity planning in the scrum world. Try to work with customers to understand that they won’t get an estimate for full project completion but they can get an estimate for the next feature or the next release.

By involving customers and continually communicating the progress on the software project they can make adjustments to the direction that it is taking. Instead of bidding on an entire contract as a great monolithic construct, propose a scheme where you build it up one component at a time, providing estimates for the small pieces as you go. Give the customer value at regular intervals and demonstrate that their money is being used effectively. It will help your developers feel better about not being tied down to commitments based on imprecise estimates and it will help your customers to see the value for their dollar faster than in the past.