#NoEstimates

Context

I first heard of the #NoEstimates concept in an interview on the Scrum Master Toolbox Podcast. Intrigued by the concept, resonating with my daily practice, I decided to investigate.

I inspected various resources, including the NoEstimates book by Vasco Duarte. It is the most comprehensive reference I encountered.

The topic is gaining traction in the agile community. Is it only a buzz that will vanish abruptly, or is there any wisdom in it?

Estimates

What are estimates

The first thing is to understand why traditional estimates don't work and what they strive to accomplish.

Estimates are guesses, not facts. They are ineffective.

Some reasons why estimates fail:

• Hofstadter's law
• Parkinson's law
• Accidental complication

In a more extreme approach, estimates are waste (as defined by Lean).

• They don't provide business value
• They don't add value in our process

Being waste, they should be reduced or even eliminated.

Why are we using estimates

We believe we use estimates for:

• Prioritization
• Forecasting
• Budgeting
• Dealing with uncertainty

Experience reveals that they don't reach those goals.

The problems with estimates

Many companies follow a Project-Driven Development paradigm. This evokes the classic Iron Triangle. The downside of this approach is that we neglect the most crucial things: competitiveness and value delivered to the customer.

For a better focus on value and time to market of the product, we have to change the paradigm from scope-driven to value-driven development.

A better way

Focus on value first, and then figure out how to deliver that value as quickly as possible. Don’t estimate your way into excuses. Deliver it, bit by bit, incrementally.

This is nothing new, just following the basics of the Agile Manifesto.

This requires writing User Stories that obey the INVEST set of criteria with a little twist: the E becomes Essential and not Estimable. Most of all it requires small User Stories (ideally <= 1 day).

Features should be limited to a maximum duration of 1-2 months. They are composed of Stories respecting the principles above.

The measure of progress is simple: how many Stories deliver the team every day / every iteration?

If we have Stories of roughly the same size, we can forecast.

5 iterations are generally enough to have historical data to perform efficient forecasts.

We use both these metrics to forecast the progress of our project:

• User Stories velocity: How many User Stories can the team deliver on an average week/iteration?
  • Assess when a certain Feature might be ready
• Features velocity: How many User Features can the team deliver on an average week/iteration?
  • Assess when the project might be ready

Moving to #NoEstimates

Vasco Duarte recommends a step-by-step approach:

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 sizes to start producing Story-­based forecasts.
7. Finally, work with Stories as if they all had the same duration.

Conclusion

The #NoEstimates approach is following the values and principles of the Agile Manifesto.

Simplicity--the art of maximizing the amount of work not done--is essential.

If estimates can shift to the work not done category, sounds good!

It requires an experienced team and in particular an experienced Product Owner to manage the Features and User Stories correctly. But if done properly it allows an efficient and frictionless way to monitor progress and forecast the work.