The idea of #NoEstimates
An introduction to #NoEstimates
Probably the most controversial of the agile movements recently celebrated a milestone birthday: #NoEstimates turned 10. Long after it was launched through a series of blog articles and conference talks in 2011 and 2012, it is still far from the mainstream and will not arrive there anytime soon, also because of its provocative name for many managers. However, since #NoEstimates knows many passionate supporters and advocates, it can be assumed that the movement will continue to exist in its niche for a long time, especially since other sectors have taken up the idea in the meantime.
#NoEstimates as a response to WAG
In order to understand the idea of #NoEstimates, one has to be aware of one thing: despite its name, the movement does not explicitly oppose all estimates of effort. It addresses projects that develop so unpredictably that useful estimates are substituted by random guesswork. Woody Zuill, one of the masterminds of #NoEstimates, referred to this in November 2011 in his article “Estimate a Game of Chess “1 as “Wild Ass Guessing” (WAG).
In the day-to-day practice of organisations, there are always projects in which framework conditions exist that make a realistic estimate almost impossible. One example is the development of a new type of online product, where the intensively used new features are to be continuously developed, while the less used ones are to be expanded later. Another is the repair of an ancient system with hundreds of undiscovered bugs.2
Any attempt to provide these or similar projects with effort estimates only ends in a pile of data rubbish, since the knowledge base on which the effort estimates take place is constantly breaking away and forming anew in a changed form. This cannot be prevented; after all, neither the usage intensity of a feature that has not yet been built nor the repair effort of a bug that has not yet been analysed in detail can be predicted. And there are many such examples.
Effort estimates as an antipattern
However, it is not only the case that effort estimates in the examples described do not add value, they can even have damaging effects. Most obviously by preventing the time spent on them from flowing into implementation, but also by increasing administrative burden – missed estimates lead in many organisations to attempts at correction in the form of even more estimates, planning and reporting, which ties up yet more working time.
Even this is exacerbated in many companies by the way in which inaccurate estimates are handled (even when they are actually invaluable). Where anyone who “misestimates” is publicly exposed or experiences career disadvantages, unnecessarily high “protective estimates” are often created. It can also often be observed that additional efforts in the form of bug backlogs or technical debt are postponed to the future, where they acutely occur at the most inopportune moments.
In the end, the effect of effort estimates turns into the opposite of the desired one: instead of work processes and planning being
- more structured,
- more stable and
- more predictable,
they become
- more bureaucratic,
- more error-prone and
- more unpredictable.
This phenomenon (the destabilisation of a system by forcing effort estimates at inappropriate points) is what Vasco Duarte, one of the other #NoEstimates thought leaders, calls “borrowed fragility”.3
In such a scenario, it is more goal-oriented to simply continue working until the goal is achieved, for example until market saturation or positioning is reached (in the case of volatile product development) or until all major bugs and performance problems of the critical systems are fixed (in the case of repair work on the legacy system). Of course, only within the framework of an available budget, but this can always be extended until the goal is reached (or until re-prioritisation).
#NoEstimates on a small and large scale?
What is important about this picture, which is worrying from a classic management point of view, is that it describes the conditions at a global level, i.e. it is about entire projects or products. At the implementation level, where the work packages are broken down much smaller, the question arises again – are effort estimates possible at least here? The answer: Yes, but (in the context of #NoEstimates) differently than one would initially think.
The problem of estimation also occurs at the operational level. Even with relatively small work packages, it is not possible to reliably estimate how much time they will take to implement, even if they are broken down to the point where they (presumably) fit into sprints, weeks or months. Whether it will ultimately take five days, four or seven, cannot be reliably said; here, too, the lack of clarity is too great.
What can be said about such small tasks (not for all, but most cases) is only whether they fit into a sprint or month at all. Usually, work packages at this level are only a few days in implementation, so with a delivery cycle of 14 to 20 working days, one can be fairly sure that completion will be on time, and even leave time for further work. This insight was contributed to #NoEstimates by Vasco Duarte in January 2012.4
The key to more predictability lies in a slight restriction of the basic idea: instead of no estimates at all, there are simply no estimates below a certain granularity. As described in the last paragraph, this can mean that the implementation team is only asked whether a task fits into a sprint at all. For the resulting three possibilities:
- yes,
- no and
- no idea
there are even separate planning poker cards.5
Source: https://twitter.com/pawelbrodzinski/status/493730902241861633
The plannability results from the experience values that are possible at this point. With a constant implementation team and a constant technology, there are two stabilising factors that are usually missing in different projects or products, so that the average quantity of work packages completed in the last sprint (the throughput) usually corresponds to what is realistically feasible in the next sprint.
As a side effect, this variant of (non-)estimation and planning is also less manipulable than others. While teams are often pressured to be more “optimistic” in their hourly or story point estimates, this is possible to a lesser extent with this coarser estimate. And the average value of work completed in the past, is not manipulable if one does not want to commit an obvious “falsification of history”.
Conclusion
Without a stable knowledge base, it is counterproductive to carry out effort estimation. The idea of #NoEstimates addresses projects where effort estimates do not add value and instead have the potential to do harm, which is why it is better not to use them at all.
Interestingly, the approach of operating without effort estimates and basing planning on the throughput of the recent past can now also be found far away from #NoEstimates, among others by
- Ron Jeffries, a co-inventor of Extreme Programming,6
- Troy Magennis, one of the most well-known representatives of agile forecasting7 and
- even SAFe.8
In a way, #NoEstimates has made it into the (agile) mainstream after all, albeit without its provocative naming. Ultimately, however, this is also less important than the idea behind it, so that should be an acceptable price.
Notes:
Of course, there is another, destructive kind of “No Estimates”, which is the fundamental denial of all estimates of effort, that is, even when they would be possible or useful. To distinguish it from this, since 2012 it has been written in one word and with a hashtag.
[1] Estimation is Easy and Useful: Estimate a game of Chess
[2] No Estimate Approach For End-Of-Life Legacy Support
[3] Borrowed Fragility
[4] Story Points Considered Harmful – Or why the future of estimation is really in our past…
[5] Planning Poker Karten
[6] Some Thoughts on Estimation
[7] Story Point Velocity or Throughput Forecasting – Does it matter?
[8] SAFe: Estimating Work
Felix Stein regularly publishes articles in the justifiably very well-known and popular German-language blog On Lean and Agility. Definitely worth more than one visit!
Felix Stein has published another article in the t2informatik Blog:
The idea of chaos engineering
Felix Stein
Felix Stein was once one of those project managers who constantly asked why everything was taking so long. His decision to find out what the problem was and to look for ways to improve it had greater consequences than he thought at the time – he has now been working as an Agile Coach, Lean Coach, Scrum Master and in various other roles in the agile environment for more than a decade.
Felix Stein is co-founder and co-owner of Agile Process GmbH, a company that supports agile transitions and is also organised internally according to principles such as openness, transparency and eye level.