This blog has moved. Go to SoftwareDevelopmentToday.com for the latest posts.

Friday, July 12, 2013

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: 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!

at 14:21
RSS link

Bookmark and Share

6 Comments:

  • 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

    By Blogger Will, at July 12, 2013 5:24 PM  

  • 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?

    By Blogger Unknown, at July 18, 2013 12:00 PM  

  • 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?

    By Blogger Unknown, at July 18, 2013 12:01 PM  

  • @Kevin Throughput tracking is basically counting the User Stories or Backlog items delivered (according to the Definition of Done, preferably released) in a certain period of time (a week, one iteration, etc.) I explain this a bit more in this video: http://www.youtube.com/watch?v=2PyZu1qHy_o&t=3m40s

    By Blogger Unknown, at July 18, 2013 12:24 PM  

  • @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

    By Blogger Unknown, at July 18, 2013 12:36 PM  

  • I have just posted about #noEstimates.
    http://www.akitaonrails.com/2013/10/07/off-topic-noestimates-debunked#.UlLUuGRgbsQ

    By Blogger AkitaOnRails, at October 07, 2013 6:35 PM  

Post a Comment

<< Home


 
(c) All rights reserved