#Noestimates – Confused by an Unfortunate Hashtag

Having gotten interested in the #noestimate conversation on twitter, I spent some of last week watching youtube videos on the topic to understand the perspective.

Lots of things to watch but the one below is a pretty good in that its short but representative of some longer talks by Vasco Duarte and often referenced by other speakers on #NoEstimates.

No Estimates actually has Estimates

So, here is the confusing part.

No Estimates actually has estimates.

Vasco uses historical velocity on story cards completed (not story points) to predict future velocity. He has a database which shows it to be more accurate. He differentiates it from estimation by calling it a prediction but it still provides a way to budget. It’s a different way to answer the question of “how long will it take?”

How useful is it?

I think there are a lot of things to like about the No Estimate approach.

If you have a large team and a stable development process, then naturally story cards will be start to become a standard size and layering further estimation methodology on top is probably a waste of effort (Muda, for the lean folks). Vasco is at pain to discuss how you need to control scope to deliver value across large teams on yearly delivery cycles.

If you remove the “no estimate” label and the emotion it brings, everything he suggests is sound working practice in project delivery.

But, I wonder how many people work in that environment.

I certainly don’t.

On many of my projects, the whole team is only 3-5 people and we only expect to need 3 or 4 sprints to complete the project. In that time frame, we want to deliver value to our customer and, to win the deal, we need to estimate the work. There is just no way around it but I do manage most of our projects much more around story cards than story points. I actually never calculate velocity unless asked by the customer because the key is always to solve their problem. The code is coincidental.

As a closing thought, perhaps, we should be looking to reduce our project sizes rather than change estimates to predictions. But, that feels like a topic for a different day.

2 comments for “#Noestimates – Confused by an Unfortunate Hashtag

  1. Henrik Ebbeskog
    July 28, 2014 at 5:39 pm

    Great post! I agree with you that Vasco’s work is just a variant of estimation. That’s my opinion. But I still support his work 🙂

    You write: “we should be looking to reduce our project sizes rather than change estimates to predictions.”
    I think that’s exactly it. Imagine a time (far from now) where every project in the world is less then 1 month. I don’t think we will estimates then 🙂
    And, until then we should focus at switching to “smaller”. I think that reduces the need for estimates, or at least makes them less sensible if “wrong”.

  2. Glen Alleman
    August 3, 2014 at 10:58 pm

    Reducing project size is a noble goal, but unlikely in many domains, ERP being one. partitioning projects into incremental deliverables is one approach we use, with the notion of increasing maturity of the overall systems “capabilities” http://goo.gl/QglVk
    The example is for an insurance provider network enrollment system, where specific “capabilities” can be rolled out to start receiving the business benefits. But the end-to-end “plan” needs to be executed for the firm to “make its numbers” on the entire system. A partial completion of the enrollment system will not meet the strategy for the business.

    Vasco’s approach is Open Loop, with not steering guide by which to measure progress to plan. Just measure progress no target outcomes for cost, schedule, or technical performance. This means he may know when he’s going to be done,but not when he’s needed to be done and at what cost. Setting the budget is not the same as managing the cost toward that budget.

    So the #NoEstimates paradigm ignores the microeconomics of writing software for money principles http://goo.gl/wVBfC1

Leave a Reply

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