Although #NoEstimates is one of the latest Agile hot topics, this question reminds me of the “Hell no” harmony from an episode of “How I met your Mother”. Having said that, it doesn’t seem to be a bad idea, considering the only projects that meet deadlines are the ones that have fixed deadlines and flexible requirements. Oh wait! Aren’t all Agile projects supposed to have fixed release dates and flexible scope? Theoretically, yes! Then #NoEstimates must fulfill all Agile projects? Hell no!
Source: Twitter
The way Agile projects are supposed to work involves having a backlog of requirements and frequent releases. In order to achieve this, projects usually fix release dates at regular intervals (if they don’t, they should), and have a list of user stories that fulfill the MVP for each release. The secret lies under that fact that since user stories follow the INVEST principle (if they don’t, they should) it’s easy enough to adjust the scope of the release and deliver a working increment to your customers on the day it was promised. Your project follows this right? Hell no!
Okay, that “Hell no” was unnecessary; there are a number of projects that follow this principle. Examples may include SaaS based applications like Salesforce.com or software upgrades provided by Apple. But this seems to be a trend with product based organizations that are responsible to continuously innovate and fix their existing products (and customers have paid for it). #NoEstimates seems to be a good fit for these projects, whether they do it or not is a different question.
#NoEstimates may also be a good candidate where projects are executed under pressure of uncontrollable factors; for example, when support for a content management system is to expire, it’s time to upgrade your applications. It doesn’t matter by when, or how much it’ll cost, it has to be done. But consider consulting engagements where project costs are fixed; will it make sense to begin a project without assessing the risk of not completing it under the given costs? Or consider engagements where you have to make a choice between two alternatives; will it make sense to choose one without a cost-benefit analysis? Or consider engagements where you have convinced a customer to begin with #NoEstimates and the customer runs out of money in the middle of the project; how will you sleep at night knowing that you’re partly responsible for someone’s bankruptcy?
As with every aspect of Agile Coaching, #NoEstimates also has a special place and it completely depends on the situation. There is no one-size-fits-all solution (even if there is one, it’s definitely not #NoEstimates). But even when we do estimate, we are hardly ever correct, so why do it? Most of our customers are non-software, non-agile, and they rely on us to provide them with a ray of hope (doesn’t matter how hopeless it is) to guide them with their investments. It seems to me that the topic of estimation places us in a classic Catch-22 situation, we don’t want it, but we can’t live without it. Even the supporters of #NoEstimates (including me) will some day, unknowingly, sub-consciously, ask a developer – by when will this be done? But that’s just being (a curious) human.
In her article titled “The Case for #NoEstimates”, Johanna Rothman rightly explains that #NoEstimates is not the goal; better product development is the goal. What troubles me is that Agile has been so widely misunderstood that the moment we see an opportunity to get rid of something we want to make that a rule without understanding the science behind it. This is one of the reasons why #NoEstimates has hundreds of followers whereas the trail for #BetterEstimates dies a slow and painful death. It’s Agile (a science), not ad-hoc. So even though I love the idea of working without estimates, I would love to explore #BetterEstimates before I kneel down to #NoEstimates, but more on that next time.
P.S.: The most popular myth still stands “Working software over (read NO) comprehensive documentation”.