At the time of writing (last updated 3rd June 2015), the beta of the No Estimates book is still available for free on the condition that you provide feedback on it. The final edition may end up significantly different to the version currently available. So instead of reviewing the book from a “should I buy?” angle, I’ll provide you with summary information so that you can decide whether or not you want to read the whole book.

The main misconception about #NoEstimates is that it forbids the company from ever doing any estimates at all. Rather, it is a strategy for reducing an organization’s dependency on estimation as much as possible and instead managing projects using a forecasting approach.

The book tells the story of a project manager, Carmen, who is tasked with estimating and later managing a fictitious, but fairly plausible, large project that needs to be delivered by a fixed date. This project is plagued with unrealistically high expectations.

Over the course of the book she learns about No Estimates and starts using them.

Chapter 1 We Suck At Estimation

The chapter amounts to a comprehensive battering of estimation as a practice in software development, featuring the following sections:

Why don’t estimates work?
Hofstadter’s Law
Parkinson’s Law
Accidental complication
More than meets the eye: why estimates are actively harmful for your project and your company
How complexity destroys predictability
Change requests, change everything
All or nothing: death-march projects
Is there hope for software projects?

All in all a pretty damning indictment, but another point as explained here is the covered in the book that I’ve now lost count of the many times I’ve mentioned, Steve McConnell’s Code Complete, which is the wicked problem.

Chapter 2 What Are Estimates

This chapter explains that estimates are just guesses, never facts. It points out that estimates are personal and gives some examples of psychological aspects that affect estimation.

It covers Estimating versus Forecasting, two terms which are often used interchangeably, but are actually significantly different.

It covers the concept of the Iron Triangle, and stresses the point that the start of a project is the worst time to estimate its length or cost.

It also discusses uncertainty and buffers, and explains why buffers can be dangerous.

It gives a short summary of the estimation techniques that are covered fully in A Guide to the Project Management Body of Knowledge (PMBOK Guide).

These techniques are Expert judgement, Analogous Estimation, Published Estimation Data, Vendor Bind Analysis, Bottom-up Estimating, Parametric Estimation and Group Decision-Making Techniques

(In my own experience the most overused and dangerous of all of these estimation techniques is expert judgement. Worryingly it is still the dominant technique used for estimation.

It probably deserves it’s own post to explain fully, but to give just one of many example scenarios, the expert gives an opinion on how long he thinks it would take him to do it, unaware that by the time the project gets the green light, it will be given to a couple of junior developers who have never seen the existing code-base before. Group Decision-Making Techniques usually give significantly more accurate estimates, if the group is willing to listen to everyone’s opinion and manage any disagreements in a democratic way.)

It rounds off the chapter covering Estimating in the Agile World.

Chapter 3 Rethinking Estimates

Subtitled “The (alleged) need for estimates: deadlines, costs and scope”, this chapter asks the question “why do we need estimates?” and gives some common answers.

This chapter covers the concept of “Project Driven Development”, where the important goal is to meet the established deadline, within the defined budget, with all scope included.

Also discussed are:
Set Based versus Point Based Design
Variability
Estimation vs. Prioritization
The Predictability Paradox

Chapter 4 No Estimates Can Help You Manage A Project In Crisis

This chapter stresses the importance of visibility to progress, and always implementing independent stories. The RTS acronym is introduced: Running-Tested-Stories.

The INVEST acronym is described.

Chapter 5 The Fast Track To No Estimates

Slicing User Stories to assess progress and manage scope
Determining progress from historical data
Multiple levels of granularity
How do I mandate the size of a Feature or a User Story?
Why should I mandate the size of a User Story or Feature?
Extrapolating from User Story to overall project progress

1-2-3: step by step towards #NoEstimates – For me, this bit is the highlight of the book.
It’s a 7 step plan for gradually moving from a traditional estimation-based-plan environment to the full #NoEstimates approach.

Chapter 6 Flexible Requirements Management

The first step to deliver a project on time is to recognize that we are late.
How to recover from a late project?
Flexible Requirements Management for maximum scope visibility
Creating options by slicing features
How to communicate progress?

Chapter 7 Gaining the Customers Trust with Rolling Wave Forecasting

The never-ending pool of ideas
Reporting progress with NoEstimates
Rolling wave forecasting allows you to adapt your plans, constantly
Presenting the rolling wave forecast to a client

Is this the future for Agile Software Development?

Estimates are something that has always been liked more by project managers than developers. Back when Scrum and Extreme Programming were new, the idea of using story points instead of man days was controversial. But over the years it has risen in popularity up to the point where it is now mainstream. Up until fairly recently it was common to break stories into tasks and estimate on each task. When it was put to my team that we scrap that system in favor of points only, and later scrap the tasks altogether, that was again controversial and prompted me to write an article on it.

However over time we found that we were saving a lot of time and energy by not having repeated arguments over 3 hours vs 4 hours and 4 hours vs 5 hours. However we did still regularly find the planning poker game resulting in half the team displaying 2 points and the other half displaying 3 points. Big 2, Small 3 we used to say.

When I first found that my new company was only using 1 point (small), 3 points (medium) and 8 points (large), again it seemed wrong to me, because it was a less precise way of estimating. But again, I’ve found that is all that we really need, and it makes the process of estimating so easy it can be done almost instantly.

So it’s certainly true in my case, but based on discussions with various people and many articles I have read, there does appear to be a general trend in the industry towards spending less and less time on estimation and using a more broad brush approach.

So perhaps a full No estimates approach is the next logical step? Perhaps. Certainly it will be controversial and many people will disagree.

I invite you to give your own opinions using the comments below.

Further Reading
No Estimates Book
Story Points vs Hours
The False Notion of We Haven’t Seen This Before
Doing Scrum without Estimates
Story Points considered harmful
Estimating by Percentages
Lean Development and the Predictability Paradox by Mary Poppendieck
Ron Jeffries: Estimation Is Evil
Dinwiddie’s Estimation Blog Posts

Follow me on Twitter