The #NoEstimates Movement

maxresdefaultI’ve already read quite some of the articles published by Woody Zuill, Neil Killick and Vasco Duarte. A logical consequence is you’ll become familiar with the concept of #NoEstimates. #NoEstimates is a movement that encourages to build small chunks of work incrementally, leading as rapidly as possible to a desired shippable product, without spending endless hours on trying to predict the future.

Woody Zuill describes #NoEstimates as follows:

“Quit estimates cold turkey. Get some kind of first-stab working software into the customer’s hands as quickly as possible, and proceed from there. What does this actually look like? When a manager asks for an estimate up front, developers can ask right back, “Which feature is most important?”—then deliver a working prototype of that feature in two weeks. Deliver enough working code fast enough, with enough room for feedback and refinement, and the demand for estimates might well evaporate. Let’s stop trying to predict the future. Let’s get something done and build on that — we can steer towards better.”

Somehow only recently I discovered the related whitepaper, although it’s already been published a year ago. While studying the whitepaper, I’ve simultaneously taken some notes that I’ll share in this blog post, combined with some of the – in my opinion – ‘must-read’ articles. 

#NoEstimates Must Read Articles

The website contains an overview of most of the articles and videos that have been published around this topic. The material I found most interesting is:

The #NoEstimates Whitepaper

#NoEstimates in 4 steps:

  1. Select the most important piece of work you need to do (highest value first). Have a clear vision and decide what the most important piece of work is. Prioritise your work but be ready to change priorities.
  2. Break that piece of work down into risk-neutral chunks of work. Each piece should be small enough that failing to deliver it at first attempt will not jeopardise the project objectives.
  3. Develop each piece of work following the Definition of Done. Work is only done when it is ready to be used by real customers.
  4. Iterate and refactor. Learn from the previous implementation and improve it until it reflects your definition of a high-quality product.
  • #NoEstimates is the natural way to implement two of the four Agile values:
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan
  • When struggling with predicting the output of a project, ask the question “Is the system of development stable enough to make predictions?”
  • Try this experiment. Consider counting user stories (#NoEstimates) vs estimated story points (Estimates), which metric is more accurate when compared to what actually was delivered during the project?

Intro Post by Woody Zuill

  • Estimates are NOT a deliverable. Regardless of how we define “estimate”, it is not a deliverable in the world of software development.
  • We discovered the needed features. Most of what was thought to be needed was not actually needed.  Doing the work of writing the code in small pieces and getting it into real use made it possible to steer the work.  This is the “requirements emerge concept”.  I urge you and encourage you to think about it and experiment with it.  It is GOLDEN.
  • Estimates are part of the “comprehensive documentation” that we value less than “working software”.

Estimates? We Don’t Need No Stinking Estimates

  • #NoEstimates was intended as an invitation to a conversation.
  • “With problems we’ve never faced before, the usual techniques of estimation don’t always work.” – Aaron Santos
  • “The work of estimation, however frustrating, is a valuable part of the research-and-discovery effort that all software projects must make. Sure, you learn as you build; but you also learn as you estimate.” – John Allspaw

The #NoEstimates Movement by Ron Jeffries

  • The Kanban and Lean principles don’t have any need for estimates about how long something will take. Instead, they measure how long things take, in “cycle time”, and use that to make such predictions as are necessary.
  • Working in continuous flow, without story estimates, is a great way to work.
  • Estimation is very difficult, perhaps impossible, and often misused.
  • When requirements are vague — and it seems that they always are — then the best conceivable estimates would also be very vague.
  • Estimates are often misused as a bludgeon to try to get programmers to work faster. This leads to unhappy programmers and to poor software. No one wins.
  • How to apply #NoEstimates isn’t entirely clear. Does it really mean that all estimates are bad? If not, which ones are OK? How can we tell the difference between an estimate that’s useful enough that we should do it, and one that is pernicious and never should be done?

Jason Gorman About #NoEstimates

  • The problem with estimation stems from us asking the wrong question: “What software would you like us to build?”. This naturally leads to a shopping list of features, and then a request to know “How much will all that cost and how long will it take?”
  • If we asked instead “What problem are we trying to solve, and how will we know when we’ve solved it?” we can set out on a different journey.
  • Software development is R&D. The honest answer to questions like “What features are needed?”, “How much will it cost?” and “How long will it take?” is I Don’t Know.
  • Pretending to know the unknowable is what lands us in hot water in the first place. Than the fairy tale starts. Once we’re in the fairy tale – where we know if we deliver this list of features, it will solve the customer’s problem, and we can predict how long and how much it will take – it’s almost impossible to get out of it. Budgets are committed. Deadlines are agreed. Necks are on chopping blocks.
  • The only way out of the estimating nightmare is to call “bullshit” on it, and publicly accept – indeed, embrace – the uncertainty that’s inherent in what we’re doing.
  • By all means offer a guess, so the customer can budget realistically. But you must be absolutely 100% crystal clear with them that, at the end of the day, we don’t know. We just don’t know. It’s a punt.


If the topic of #NoEstimation has your interest, I hope this blog post can act as a good starting point. As you might have noticed, I haven’t included my personal opinion yet, I’ll give this material some more time to digest and probably will write a separate post the upcoming period.

3 thoughts to “The #NoEstimates Movement”

  1. Barry, do work where those paying you let you spend their money with no idea of how much it will cost to deliver the value you are developing, when that value will arrive, or even if that value is the right value?
    Yes? then #Noestimates is the solution for you.
    No? then someone in the organization needs to learn how to estimate

    1. Glenn, take a look at Actionable Agile Metrics for very practical alternative that doesn’t need traditional estimates.

Comments are closed.