Why use No Estimates? Focusing on what matters

As I sit here with my red-wine glass and contemplate the #NoEstimates discussion on Twitter for the last few days I can’t help but think that there is a key difference in how I look at Software development when compared with some of the Agile Pioneers like @RonJeffries, or @TOtherAlistair. And I want to explain some of those differences. They are too important to our profession to go undiscussed.

Tired of the same old house

First, I’d like to state that I don’t think that the construction analogies are of use anymore. It was ok to use that in the beginning of software development. Those were the most well-researched projects at that time. However, today we have a sufficient body of knowledge to warrant research and analogies from within our domain.
Also, while I know some will claim this is a gross generalization (and it is), construction is not in the Complex domain, while software is. If you follow any of the #Cynefin discussions you know that approaches suited to the Simple domain are not suited to the Complex domain. In my view most construction projects are in the Simple domain (not all), and most software projects are in the Complex domain (again, not all).

Change the context, or your project will fail

One other thing that makes me focus on the #NoEstimates approach to software development is my realization that the existing context is not well suited to software development. The context where Estimates are mandatory, and you will be held accountable for years to come; the context where teams are asked to “commit” to a plan that they know very well may not be possible to achieve; the context where we base all of our approaches on our belief that predictability is easily achievable in long term software development efforts.
I want to promote the #NoEstimates approach because I want to change the context surrounding software development. I’ve learned enough to know that software estimates don’t work, and I know a better alternative!

It’s the customer, simply!

My approach to implementing #NoEstimates is centered on discovering value, because I assume that I don’t have all the answers up-front. Since I recognize that I don’t have all the answers, I’m ready to accept that the definition of the work to be done will change (not might, will!). So I focus my energy on discovering that most valuable work to be done. This requires that I focus on defining small increments of customer-value (instead of large chunks of “work”). I use User Stories (and Epics and Features) to help me build a vocabulary that leads to a constant dialogue around value at all levels in the company. And I’ll let you in on a secret: Sales people don’t like estimates either! Why? Because they want something out ASAP and if you tell them that they need to wait another 6 months they will hate you. Estimates or no estimates. Sales people understand something intuitively: they need value to sell. The longer they wait the more uncertain they are about that value. It is that simple.

I believe #NoEstimates is a better way to manage software projects

It is this simple. I’ve used #NoEstimates, I recommend #NoEstimates and I use #NoEstimates in my own work. Discover the value, deliver the value in the thinnest slice possible, rinse and repeat.
There are many concrete ways in which you can generate dialog around value, and ways in which you can enable very thin slices. Some have been published (Naked Planning by @arlobelshee being one example), others are just being discovered and experimented with.

Estimates have failed, are you looking for alternatives?

The Estimation approach to software development has failed us for too long. It never really worked in the projects I participated in (and I used it a lot) and we always ended up using the only available tool to us to meet our deadlines: manage scope.
So I recognize that an approach focused on helping companies and teams zero-in on the valuable parts of the their projects and delivering those first, helps in Risk Management, focuses on welcoming the changes we know are coming instead of sticking to the plan (estimates *require* a plan, otherwise what are you estimating?), and more importantly it requires customer collaboration for it to work. Unlike Estimates that focus on contract (the estimate) negotiation.
How to use #NoEstimates to manage your project? Take a look at an example I published a few months ago, and the data that supports this approach. After all, #NoEstimates is firmly grounded on empirical data collected over many (22 at last count) projects. Again, unlike estimates which by definition are not based on data. Estimates are rather guesses about future events.
Have you experimented with some form of #NoEstimates? Leave a comment below. Let’s keep the conversation alive.

2 thoughts on “Why use No Estimates? Focusing on what matters

  1. If you’re being “held accountable” for “estimates,” they’re not estimates. They might be a commitment or a negotiation or a blame-shifting tool. But they’re not estimates.

    You also seem to be talking about the lowest levels of software development, here. There is relatively little need for explicit estimation there. We can often trust our gut-level estimate for the short term of a week or two.

    Estimates do not require a plan. Maybe you’re accustomed to doing it that way, but it’s not a requirement.

    Working in small slices and delivering value frequently is orthogonal to the question of estimation. In fact, I’d say that working that way is almost essential to be able to track progress in a meaningful way.

    As for estimation failing you, it sounds like you have different expectations for what it can do than I do. It’s not going to guarantee the future. It can only give you a picture that represents your current understanding. That picture can be valuable for testing your understanding as you measure your progress.

  2. Good stuff Vasco!

    I can see how story estimates can be wasteful and possible harmful in other ways too.
    At the heart of Scrum is the sprint time-box. Often, the team ‘commits’ to do a certain amount of work within a sprint based upon the sum of estimated story points.

    When doing complex things, there is a very good change that the estimates are not accurate and reality does not fit into the sprint time box.
    When that happens, the team will be under some pressure to cut some corners, which can cause technical debt. A better solution would be to drop some stories from the sprint backlog, but this way the sprint might be considered as ‘failed’ because people had higher expectations based upon estimates. (I am not talking about blame.) This might be harmful for the team motivation, because after all they did their best and delivered
    as much value as was realistically possible.

    Estimates could be too high as well. This can happen especially when the estimates are made too early on and the team has learned better ways to implement the already estimated stories. This can all happen easily within a single sprint as well.
    In this case, the sprint will be perceived as a ‘victory’. The team delivered all or maybe even more than what was agreed on. Everybody feels really good about themselves,
    which will cause expectations based upon estimates to be even higher for the next sprint.

    I have been following the #noEstimates discussion with a lot of interest.
    Some of the questions I still would like to see answered are:


    How does #noEstimates change the sales process? In reality, scope is only partly flexible; typical customers will want software that solves a certain problem (=scope)
    and they will want to know how much it will cost them and when it will be done. How do you sell to those customers without high-level estimates?


    Is #noEstimates on the team level any different from using #Kanban focusing on cycle-time rather than story-point velocity?

Comments are closed.