To Estimate or Not to Estimate—That Is the Question
There’s a movement in the agile community called “no estimates” (Twitter search: #noestimates), where people are challenging the value and validity of estimating the work required to develop software. The challenges come from several different perspectives.
As a reason to avoid estimation, Ron Jeffries focuses on the likelihood that estimates will be misused by the organization. One area in particular that Ron discusses is that creating an estimate sets an expectation—not only of delivery date but of fixed scope in the organization—because the estimate is a prediction of the amount of effort and time required to deliver something specific.
Once the estimate exists, it is harder for the team to change what they are going to do or even how they are going to do it because the estimate is an artifact that now carries a set of expectations.
Michael Dubakov has an excellent article about the unpredictability of effort, which essentially points out that all estimates are wrong. What Michael gets exactly right is the idea that estimates are reflections of probability distributions, not specific numbers. He also shows that distributions often skew to the right; the actual effort is more likely to be higher than your estimate than it is to be lower than your estimate.
Michael's example of estimating the coding of a simple user login really drives home the point that there is significant underlying complexity in even the most seemingly simple stories. My experience has been that a team learns this very quickly, and their estimation approaches adapt to match the mean while the aggregation of multiple estimates reduces the size of the distribution of estimates within a sprint.
Estimation, however, exists for a reason—so that the sponsors of a project can get a projection of the potential reward of investing in that project, relative to the size of their investment. How many projects get a blank check? The closest I’ve seen is a startup who is given a specific burn rate—dollars per month, or effectively, head count—with the hope that they can “do enough, fast enough” where risk is mitigated by investor perceptions of the people on the team.
While not a blank check, there is no specific target—specific enough to estimate effort credibly—because the expectation is that the targets will be discovered along the way. Large companies I’ve worked with require a projected return and an estimated cost—inputs into a business case.
Estimation carries a lot of risk. The estimates can be wrong, the estimates can be expensive, and the estimates can be reused. Risk is not necessarily a reason to avoid estimating. Estimates can have value—informing rational top-down investment decisions, allowing for efficient investment of team effort by getting the most bang-for-the-buck, and providing motivation, feedback, and learning to team members.
An alternative to not estimating is to mitigate the risks of bad estimation—improve the accuracy of estimates, reduce the effort required to estimate, and fix organizational bad-behavior surrounding estimates.
