As I’ve said in a previous post, I don’t like estimating. So I decided to have a look at Vasco Duarte‘s No Estimates book.

While reading this book, I had 4 questions in mind:

1. Why are estimates waste?
2. What questions do estimates try to answer?
3. What to use instead for story estimation?
4. What to use instead for project estimation (e.g. for bids)?

So, let’s first have a look at the book and then we’ll see how it helped me answer these questions.

Summary

No Estimates is, in part, a business novel (like Eliyahu M. Goldratt‘s The Goal). It follows Carmen – a Project Manager – who needs to estimate and manage a large and complex project. Let’s see what each chapter teaches us.

The #NoEstimates Premise

In The #NoEstimates Premise we are reminded of how we can identify waste by asking a simple question: Do we want to have more of it? Clearly, clients don’t want more estimates, so estimates are waste. But estimates are just a means to an end. So, what is that end? It could be: plans, reduced uncertainty, forecasts, financial projects. #NoEstimates aims to deliver that with the minimum amount of estimation. And this is important: #NoEstimates is not about no estimation ever, it’s about minimizing it.

The Problem with Estimates

Vasco highlights some of the main issues with estimates in The Problem with Estimates. First, it reminds us a definition of good estimates: “within 25% of the actual result, 75% of the time”, which isn’t that good to begin with. A single mistake in a big contract could wipe a company. Then it goes over some of the reasons why estimates don’t work: Hofstadter’s Law, Parkinson’s Law and Accidental Complexity. Also, software systems have an annoying property: non-linear causality. This means that a small change can have a large impact. You can’t integrate with an essential 3rd party because of a change in their Terms and Conditions. You hit a framework limitation when you’ve already completed 50% of the work.

But what are the questions that estimates try to answer? Depending if you have fixed scope or fixed date, it could either be “given the rate of progress so far, when will we finish the agreed scope” or “given the rate of progress so far, what can we achieve by date X“? To answer these questions you need to use past data.

What are estimates?

What are estimates? emphasizes the difference between estimating and forecasting. Estimates are guesses. Forecasts rely on actual (past) data. Another approach for dealing with uncertainty in estimates is to use buffers: time, cost, or scope buffers. Many times estimates are needed for prioritization. But, you can have prioritization without estimates. If you know what’s the top priority for your company right now, maybe you don’t need estimates for the other items. But I think that, in reality, few companies know this. So how can we ignore cost (estimates) then? By making features of roughly the same size.

Rethinking Estimates

In the next chapter, Rethinking Estimates, Vasco discusses why we need estimates, especially in companies that follow a Project Driven Development approach. In this approach, the most important thing is to achieve the time, scope and budget targets. Following this goal makes people ignore more important things like: customer value, time to market or market share. (By the way, Allan Kelly has a good book about this: Project Myopia.) Vasco’s advice is to focus on prioritization over estimation. After deciding what’s the most important thing, find a way to deliver that value as quickly as possible. So, fix the hardest constraints (time and people) and manage uncertainty through variable scope.

How NoEstimates Can Help You Manage a Project in Crisis

In How NoEstimates Can Help You Manage a Project in Crisis, the author goes into the how of NoEstimates: slicing stories. Stories should be independent and small. Ideally, a story should not take more than a day to develop. A good rule of thumb is to deliver 6 to 12 stories in a 2 week period. Good stories follow the INVEST acronym, where E stands for Essential, not Estimable. This will allow you to track the progress of the team.

The Fast Track to NoEstimates

The Fast Track to NoEstimates gives us a few pointers of how to to slice stories:

• Slice along functional dependencies (e.g. move the complex UI to a different story).
• Slice to separate quick from time-intensive functionality (e.g. use a temporary DB at first, if integrating the DB changes requires a lengthy approval process; move to the real DB later).
• Slice along user/role separation.
• Other techniques: slice following user journey steps, slice according to input/output data, etc..

It’s important to have hierarchical backlogs. Features should not take more than 1-2 months. If you set a maximum duration for a feature to 1 month, then you can deliver 12 features in a year. Stories should not take more than 1 day. If you have features and stories of roughly the same size, you can forecast. In order to have enough data, Vasco recommends using 3 to 5 iterations.

But how do you move to NoEstimates? Vasco recommends following these 7 steps (depending on where you are on your journey):

1. Move to Story Points.
2. Stop estimating Tasks.
3. Limit the calendar duration of Features and Stories.
4. Remove some Planning Poker card option (e.g. keep only 1, 5, and 8).
5. Build Histograms.
6. Use the average cycle times for Stories of different size to start producing Story-­based forecasts.
7. Finally, work with Stories as if they all had the same duration.

The First Step to Deliver a Project on Time is to Recognize That We Are Late

In The First Step to Deliver a Project on Time is to Recognize That We Are Late the author gives a few pointers on how to recover from a late project. The most important is to focus the conversation on value.

Gain the Customers Trust With Rolling Wave Forecasting

The last chapter, Gain the Customers Trust With Rolling Wave Forecasting, presents how rolling wave forecasting allows you to adapt your plans.

Conclusion

This books makes you think about why we use estimates and challenges you to find alternatives. I like Vasco’s focus on Value. I do think that sometimes we work to achieve an agreed target (be it scope, cost or deadline) in the detriment of real customer value.

So, how can you minimize the amount of estimates? You should timebox features. Working within this boundary should encourage the team to come up with creative options. As for user stories, timeboxing them to 1 day is a great target, but I find it hard to achieve. There are some useful tips on how to do that, but it requires hard work to get there. It would be really interesting to see a realistic 1 month feature split into 1 day stories.

I enjoy business novels, but, somehow, the blend between business novel and regular textbook seemed a bit off in this book. I also think Carmen’s story jumped over an essential part: how did she come up with a bid for the project? And this was one of the questions that I was trying to answer. But it did answer the other three questions:

1. Why are estimates waste?
   • They don’t add business value.
   • A black swan could potentially wipe you out.
   • Time after time estimates have been proven wrong.
   • You can’t estimate what you don’t know (e.g. unknown unknowns, change requests).
2. What questions do estimates try to answer?
   • Can you predict when a particular project will end
     • Given the rate of progress so far, and the amount of work still left, when will the project end?
     • Given the rate of progress, how much of the work can be finalized by date X?
   • The answer to this question is important because of: plans, comfort, uncertainty reduction, financial projections, sales proposals.
3. What to use instead for story estimation?
   • Forecasts based on past data
   • Prioritization based only on value

All in all, a good book, that challenges the way you think about estimates.