Methods applied in the #NoEstimates book

Users reviewing the #NoEstimates book talk about how it might better explain how to apply #NoEstimates in their project. Here is a review from Rod Hilton on goodreads.com touching on this:

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.

So let's identify methods the main characters in the book are applying to understand better what methods #NoEstimates is all about.

Methods applied in the #NoEstimates book

Here are the methods applied in the #NoEstimates book and associated links for further reading:

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

Send me a comment if you notice something important is missing from the list!

So the methods the #NoEstimates book is advocating for are nearly all well-known Agile practices. When the book was released in 2016, some methods were even known as Agile best practices. To mention a few best practices at the time:

• working software is the primary measure of progress
• user stories, story splitting, story slicing
• visible progress (i.e., tracking velocity)
• tracking multiple levels of granularity

The book doesn't go into details about the methods. So to learn more about them, the links above can be helpful. However, the book has a chapter outlining how to transition a team towards #NoEstimates. The chapter is called 1-2-3: Step by Step Towards #NoEstimates and covers 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?

There isn't a lot of discussion about new methods in the book, as it's mostly about applying Agile best practices.

What I thought was new and interesting was the part that has to do with Limiting calendar duration of Features, i.e., timeboxing. Timeboxing each feature to two months. Then working towards completing the work within the timebox, yet realizing the impact, is a brilliant approach. By focusing on impact, teams can use their wit, experience, and knowledge about the work at hand. Discover solutions that deliver the impact yet have room to adjust the scope and make it fit within the timebox. I didn't notice any other new ideas in the book, so please let me know if I missed something important.

So the book is not written to be a concrete step-by-step guide towards #NoEstimates, as some reviewers mention. This raises the question; Why is the #NoEstimates book written?

Why is the #NoEstimates book written?

Many reviewers notice the book only covers cases where estimates don't work. As an example, the following review from Mark Mzyk's on goodreads.com explains that:

[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.

And it does this by claiming near the end of the first chapter

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

But the example taken in the book is the worst practice for software estimation and not the best practice as the book claims. So the author is using a Straw man fallacy, showing readers examples of how estimates don't work when applied using a worst practice approach. Here is a post covering how few of the key #NoEstimates proponents repeatedly use the Straw man fallacy to depict the use of estimates in a negative light.

So based on this, it seems the author is writing the book to dismiss the value of estimates and present #NoEstimates as the solution. In these few examples here, are we seeing evidence of propaganda used to support the case for #NoEstimates? Let's look into this question in Did you get caught by the #NoEstimates trap?

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.