The #NoEstimates How To

You’ve probably seen a long, recursive discussion on twitter about #NoEstimates.

Some of you, like William Gill may be even interested in a more concrete description that you can apply in your own projects.

So here it is. This is my first attempt at a #NoEstimates How To, first presented at Turku Agile Day 2013, the coziest conference in the Agile circuit.

Before you continue, a disclaimer: #NoEstimates is not a one-size fits all approach. I have my own approach (see below) based on my own experience, but there are other views. Follow Woody and Neil for different approaches to the #NoEstimates ideas.

Here it is: the what and why of #NoEstimates...

Rule 1 - Focus on value, manage the risk

The biggest concern in my approach to #NoEstimates is Value. By value I mean “concrete functionality that we can test in the field”. My approach to #NoEstimates is to create conversations around what matters for our customers (like Product Vision) and prioritize that work around one single parameter: Value. If you don’t know what constitutes value in your context you should do small experiments (safe-to-fail experiments) that are designed to put you on the right track to define what is valuable in your context.

After you sorted out what is most valuable the next step is to manage risk. In Software, risk management is best done by breaking down your work into small enough chunks that you can implement and test (functionally and with users) quickly. These chunks I call “risk-neutral” chunks of work, i.e. if you fail to deliver those in time, your project will not suffer a major set-back. As an example of “risk-neutral” I use the rule of thumb: “one person can complete this workin one day”. Why? Because if you are wrong about that assessment, you will know about it already tomorrow! No need to wait for a long time before you know you are late/developing the wrong thing.

Rule 2 - Discover the product, measure the throughput

In order to define and select the right work-items (for example, the right User Stories) we need to create an environment where discovery is encouraged. In the Agile community several people have developed and written about concrete methods to “discover” the product (BDD or Impact Mapping being but 2 examples). The important aspect in the process of Discovery is that you define the product from your Vision to the Goals and develop the backlog as you go. The alternative (defended by Story Point enthusiasts) requires you to write down the whole Backlog before you can estimate the project. I don’t believe that works and advise people not to do that. Use Story Mapping, or BDD from a Vision and develop your product as you go. Set the target for your MVP and start measuring throughput.

The second aspect of this rule is that you don’t focus on estimating when the development will be finished, instead you let the rate of development (Throughput) inform your view on when the MVP will be ready. Then you skillfully manage the scope (after all you do have a Vision and a set of Goals for the product, right?) to meet the relevant market release deadline. In many products the market dates are set by the market, not you. #NoEstimates accepts that. For example: consumer products in China need to be launched before Chinese New Year’s.

Throughput becomes your GPS-navigation system that helps you manage the content and the Product Vision becomes your map that helps you deliver a coherent, beautiful product.

Rule 3 - Use the data you have, measure continuously

Finally, once you have set-up the system of development you can then continuously measure where you are (how many features left to be done? How many - on average - do we do per week?) and adjust (reassess MVP and backlog and continuously update it to reflect accurately your Vision given the time you have until release).

Share your experiences, read more

I hope this helps you to get on the way to experiment with #NoEstimates. Please share your thoughts, experiences and questions below.

You can read more about #NoEstimates in the following blog posts:

• Story Points considered harmful, why the future of estimation is really in our past
• A better way to predict project release date
• Focus on what matters, a #NoEstimates advocacy post

I am not the only one writing about #NoEstimates, you can find Neil's posts on this single page. Woody also has quite many posts here.

Happy reading!