Like most controversies these days, it seems, it all began with a simple tweet. An avid programmer by the name of Woody Zuill decided to publish his views on estimation, and just as he had predicted, stirred up an online firestorm. Since then, the battle between #Estimates and #NoEstimates has created a rift in the Agile community that rivals Brexit Britain, and is still yet to have abated.
The Argument
So what is all the fuss about anyway? Well, put in a nutshell, some programmers believe estimates to be a distraction from delivering working software, as they “create unrealistic expectations” and are “mostly inaccurate anyway,” given the unpredictable nature of software development. In this way, #NoEstimates apologists argue that providing customers with estimates of time and cost does nothing but delay actual productive work that could lead to better solutions.
In addition, Zuill’s disciples assert that being on time and on budget — the presumed outcome of relying on estimates — should be viewed as the worst-case scenario, as no serious developer should ever strive to use all of the available time and money.
A Reality Check
While this may all be well and good in theory, the cold, hard truth is the industry needs and indeed demands both speed and predictability in software development. To do away with either of the two is to ask way too much of customers, who may already feel as though they are taking a leap in the dark.
Unfortunately, however, #NoEstimates advocates seem concerned with the interests of developers only. Never mind the fact that virtually every customer and manager expects to receive reliable estimations that will help them plot out the future of their companies. Such natural requests simply fall on deaf ears. And yet, because only developers are qualified to help in this matter, it is only right that they should be willing to do so — whether or not they stand to benefit from the practice.
Our Position
For this very important reason, Software Planet Group cannot lend support to this movement. It is worth remembering, however, that no one here is suggesting that estimates will always be exact or perfect. They are called estimates, after all, not facts. A more balanced approach, therefore, is to view these as educated guesses, which act primarily as guides. It is only really when developers become fixated on estimates that trouble ensues.
Still, even though estimates may at times be inaccurate, this does not mean they will always be widely off the mark. When this does occur, it is usually a result of poor estimating skills, which fail to take into account the lessons learned from the past. Responsible development teams, on the other hand, learn to perfect their estimation skills over time by spotting familiar pain points and adjusting accordingly.
The Verdict
It would appear, therefore, that the #NoEstimates camp have thrown the baby out with the bathwater, as the benefits the practice brings to Agile teams far outweigh the possible downsides. As explained in a previous article, for instance, because producing estimates entails converting requirements into complexity points, the device gives developers an efficient method to prioritise features. This in turn also provides customers with the freedom and flexibility they need to restructure requirements as they see fit. Furthermore, estimates inherently give customers valuable information regarding the cost and time of delivery of individual features, empowering them to compare providers, and as a result, make wiser decisions.
Yet as the online battle rages on, with Zuill supporters tweeting that “planning is how we turn uncertainty into error,” we can think of no greater error — or uncertainty, for that matter — than to develop without an adequate plan. This, in fact, is #NoEstimates’ greatest weakness. By staying committed to producing reliable estimates, however, Software Planet Group are able to focus on collaboration and keep everyone on the same page, working at a steady pace towards accomplishing your goals.
