The #NoEstimates How To

The #NoEstimates How To 5 ratings with average of 4.80/5

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:

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!

8 thoughts on “The #NoEstimates How To

  1. Thanks Vasco – it’s a good write-up!

    What I like a lot in this approach is the lean software approach – test hypotheses, fail fast, and use that data to make the next product decision.

    Now if I understand correctly, what you’re saying is essentially:

    * You have an idea of an MMP, based on your product vision
    * Pick from the MMP the parts that add the most user value, and start with those
    * Break them down into the smallest pieces of work – ie, 1 person-day chunks
    * Every day, keep finishing 1-day units and picking the next most-valuable units
    * Support the decision of what’s valuable in parallel with hypothesis testing, etc

    In this way, you build the backlog as you go.

    My question: how can you predict at all when an MMP might be ready? You say that #NoEstimates accepts that the market determines the release date often (I completely agree) – so how can you link throughput to MMP release date?

    You would need to compare your throughput against some known quantity of units – and if you haven’t broken down your whole MMP into these units (because you’re building the backlog as you go), how can you estimate when the MMP will be ready?

    Thanks again for the write-up
    cheers
    will

  2. Hi Vasco, thanks for this clear post. I have one question: What form does your throughput tracking take? In other words, how do you count how much “stuff” has been done in a given time?

  3. Hi Vasco, thanks for this clear post. I have one question: What form does your throughput tracking take? In other words, how do you count how much “stuff” has been done in a given time?

  4. @Will
    * Yes, we should pick the MMP based on the product Vision, but always with the idea that *you* define how to achieve the goals with the MMP. Don’t just assume that the MMP Features are not negotiable
    * Next we should pick the Features that are either linked to our Leaps of Faith (#LeanStartup) or key risks and implement those (i.e. test the assumptions)

    How to estimate when MMP will be ready: this is a bit longer answer. The short answer is you have a backlog that you constantly update and plot the Throughput rate against the size of the backlog (# of items).

    The graph will look something like this: http://bit.ly/12XaCi8

  5. Hi Vasco,

    I like the ideas expressed and the pragmatic approach to implementation. I would love to implement them. There is one huge issue though. No client I know will enter into a contract with a Software Development shop without having some idea of what they are paying for at the end.

    I would love to hear how you solve the problem that the CFO will not sign off on development without knowing what he’s getting. What does the commercial contract between a development shop and a customer look like if you’re using #noestimates. How does each side ensure that they are sharing the risk and not carrying it all?

    I really want to use this technique but I can’t see how to get it past commercial concerns? Thoughts?

    @agile_geek

    • Hi Chris,
      What you are referring to is commonly referred to a “tender process” or “bid process” for a fixed price, fixed scope project.
      I have one advice for people in that situation: Propose a “subscription” model for the project. In other words, this would be a “time and materials” contract where the client pays for what they get, and when they are happy, they stop.

      The fixed/fixed contracts are bad for both parties. The vendor will be punished for not knowing the future (even if that is a very common situation), and the client will be punished for not understanding what they need up front (which is also very common).

      Requirements change, understanding of the problems change, therefore the contracts should allow and support that fact.

      A subscription model for software development would allow this to happen, and potentially be a better fit for both client and vendor.

      One more note to say that @diegocenzano has been using #NoEstimates in his own work as a development agency. He explains that in a video that I’ll publish soon 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *