The Methods Behind #NoEstimates: What the Book Reveals (and Omits)

Users reviewing the #NoEstimates book often mention that it lacks clear guidance on how to apply #NoEstimates in real projects. One such review from Rod Hilton on goodreads.com highlights this concern:

I don't think I came away with what I wanted. The book plays a lot of lip service to the notion of predictability without estimates, but I felt like it largely does what I keep doing, which is kind of deal in vague terms and assure the audience that it's possible, without really making someone understand exactly how.

Given this, let’s identify the methods used by the main characters in the book to gain a clearer understanding of what #NoEstimates actually entails in practice.

Methods used by the #NoEstimates book characters to get their project on track

Below are the key methods described in the #NoEstimates book, along with links to further reading. Send me a note if you notice something important is missing from the list!:

1. Independent stories - Invest in good stories and smart tasks article published on www.xp123.com by Bill Wake in 2003
2. Apply "User stories" rather than requirements is something Mike Cohn talks about in User Stories Applied published 2004.
3. "Multiple levels of granularity" from the book is something Mike Cohn talks about in User Stories Applied published 2004.
4. "Visible progress" and "Extrapolating from user story to overall project progress" from the book is something Mike Cohn introduced in his book Agile Estimation and planning back in 2005
5. Story splitting - Twenty ways to split stories article published on www.xp123.com by Bill Wake in 2005
6. Story slicing - Slicing functionality: alternative paths article published on www.xp123.com by Bill Wake in 2006
7. Running Tested Stories from the book is the following principle from the Agile manifesto: "Working software is the primary measure of progress", published back in 2001
8. Presenting progress as a Rolling Wave forecast - this is something Craig Larman talked about in his book Agile and iterative development: A manager's guide back in 2003. Also is part of Project Management Body of Knowledge - PMBOK
9. Reduce variability by having smaller stories. An idea introduced by Leffingwell in the whitepaper "User story primer" published back in 2009
10. Flexible Requirement Management" from the book is something Jeff Patton introduced in his book User Story mapping back in 2014
11. Limit calendar duration of Features (Epics) and stories. Track progress by counting the number of stories completed (i.e., user story velocity) and the number of features completed (i.e., feature velocity). Mostly covered by Woody Zuill's original blog post back in 2012

The book does not provide detailed explanations of these methods. To gain a deeper understanding, the linked resources above offer further insights.

The only section that offers step-by-step guidance is a short chapter titled “1-2-3: Step by Step Towards #NoEstimates.” This chapter outlines a structured approach, consisting of the following steps:

1. Move to Story Points
2. Stop estimating tasks
3. Limit calendar duration of Features and stories
4. Remove story points options, i.e., only keep 1, 3, and 8 cards
5. Build histograms
6. Use the average cycle times for Stories
7. Work with stories as if they all had the same duration

For more information, the #NoEstimates book is available on Amazon.

What is new in the #NoEstimates book?

So the methods the #NoEstimates book is advocating for are almost all well-known Agile practices when the book was released in 2016.

As covered in the post Rise of #NoEstimates the #NoEstimates concept itself is not new—it originated with Woody Zuill in 2012. What is new in the book is its proposal to limit the calendar duration of stories and use average cycle time to forecast delivery dates.

While this approach is valid in theory, it relies on the assumption that all stories can be treated as if they have roughly the same duration. However, in practice—especially at the start of a large project—it often doesn’t make sense to spend time upfront breaking every story into implementation-ready or uniform-sized pieces.

However, there are ways to work around this challenge. One approach is to standardize the backlog to just a few story sizes—such as two or three. By tracking the average cycle time for each size, teams can forecast the total duration of upcoming work without the need to break down every story upfront.

Why is the #NoEstimates book written?

The #NoEstimates book is not intended to be a concrete, step-by-step guide for adopting #NoEstimates, as some reviewers on Goodreads have pointed out. This raises an important question: What is the book’s actual purpose?

Many reviewers note that the book focuses only on cases where estimates fail, rather than offering a balanced discussion. For example, Mark Mzyk's review on goodreads.com highlights this issue:

[the book] lays out why it says estimates don't work. And certainly, what it says is true for the many ways estimates can fail, but it isn't a good-faith argument as presented in the book. It has an underlying assumption that estimates are bad and doesn't try to grapple deeply with how they might help, so it comes off as disingenuous.

Supporting this, #NoEstimates author Vasco Duarte claims at the end of the first chapter that the following chapter, “What are estimates?”, will:

..review some of what the software industry today considers best practice methods for software estimation.

This brings us to a key issue with the book—its argument against estimates is built on a logical fallacy. While the author claims to review best practices for estimation, the book instead presents worst-case scenarios, reinforcing the idea that estimates don’t work.

The Core Argument in the #NoEstimates Book Relies on a Logical Fallacy

Rather than offering a balanced evaluation, the book misrepresents estimation by focusing only on flawed approaches. This is a classic Straw Man Fallacy—where an argument is framed around weak or misleading examples to make estimates appear ineffective. This tactic is commonly used by key #NoEstimates proponents, as discussed in How the #NoEstimates Movement Uses the Straw man fallacy.

Given these examples, the #NoEstimates book appears to be written to dismiss the value of estimates and position #NoEstimates as the only viable alternative.

What's next?

Are we seeing evidence of propaganda used to strengthen the case for #NoEstimates? Let’s explore this further in How Propaganda Shapes the #NoEstimates Movement in Agile Development.

About Smart Guess We help teams educate stakeholders by providing actionable answers to common misconceptions about estimates. So more teams can use estimates to their advantage, and fewer are held accountable for delivering on impossible deadlines.