Wednesday, 26 February 2014

#NoEstimates by examples

The best way to learn something is by examples. You know when you read documentation, you always skip to the examples. Examples are a great way of creating understanding. You can never have to many of them either (well, maybe not entirely true...). Gojko Adzic has, for instance, written an entire book on how to specify requirements by example: Specification by Example.

Anyway, I thought I would give an example on how I understand the #NoEstimates approach. I'm not saying this is the "right" way (is there?) or it's the only way. I'm not saying this is the shared understanding on how #NoEstimates are done - this is my interpretation. I'm gonna be honest as well, I haven't done this in practice. But I would certainly be able to try it, and I probably will.
Enough of disclaimers, here it goes.

The example

This is actually a quite real example (regarding the customer's need). I'm working on a similar project right now.

A customer wants to update the design for their public web site. Their existing one looks quite old and needs a visual update. They don't expect the update to generate more or other types of visitors. They just feel they want to make it more attractive and look "newer". I don't blame them for that.
As a customer I think the first question that comes to mind is "How much would it cost? Roughly." And it's a fair question. I would want to know that as well, if it was my site.
The way we do this (and I think it's the usual way) is to stall that question and ask "Let's look at what you have in mind and what can be done first." We then arrange some meetings (e.g. workshops) to create a better understanding of what the customer is expecting. The customer even accept to pay for it. But when the workshops have been held, the question still remains: "Roughly, how much is it?"
We respond to this by gathering some developers (that have done similar things before) and estimate each page type and other things we've said in the workshops. Basically going through the "product backlog" and estimate each "item". Then we sum them up, pad the sum with some time for meetings and demos and some corrections (changes and bugs) and other "unknowns" - and there you have our estimate (and price). Then we have a meeting with the customer to go through the project plan, the schedule, our estimate, the cost etc.
You all know the drill.

An alternative (the #NoEstimates) way

This is how I understand #NoEstimates. And this is an approach I could use. Again, I'm not saying this is *the* way to do #NoEstimates - it's how I understand it. I might be all wrong...

We could respond "This looks quite big. It's actually impossible for us to know the exact cost and time for this. We could do an estimate, but the only thing we know for sure is that the estimate will be wrong. So, I have an alternative suggestion. Let's see what you think of it. If you like it or not. Otherwise, we can do an estimate if you like that approach better?"
"I think what you feel right know is uncertainty. I believe there are something you don't know right now that you want to learn? My suggestion is that we start with perhaps the start page or maybe some other page you are most concerned about. Do you think it's worth to just do that page and see how long it takes and how much it is? Then we can stop or continue, based on what you know then. Is it possible to create a budget for just that little thing? Then you don't have to spend a lot of money up front. We'll create this in small steps instead, or how large steps you like. But let's decide how large steps you want to take when you know more about all this. What do you think?"
There's probably a lot more questions we need to answer here. It's impossible for me to write down every possible question a customer might have. But one instinctive question would probably be "How much do you think we should budget?" My answer would be: "How much are you willing to spend to gain this knowledge? The more you spend the more knowledge you will get. But we won't spend the entire budget if isn't needed. We'll stop when you have the knowledge you need. And whatever we produce it will be usable, how small or big it is."
It might work, it might not. But at least we have let the customer decide which path to choose. They know what they have chosen. And we have declared that the "estimate" path is just as uncertain as the other. Or maybe even more uncertain?

"But I REALLY want to get a sense of what it will cost!"

My answer would be: "Ok, your biggest problem here seems to be that you want to know what this will cost. How can we help you learn what all this will cost? First, I must say that you probably don't want all the things you think you want today. But there are ways to help you with this. One way is we can take some time to estimate all this. Another alternative is that we can start working on something with biggest risk or highest value or whatever you are most concerned about. Then we can see how long that takes and we then have a feeling for what all the other things will probably take. What do you choose?"
There might be other alternatives as well, but it all boils down to create options. Let customer decide what he/she likes the most - don't just fall back on what you have always done.


  1. this is actually estimating and a style done in places where incremental updates from existing products. So if this "estimating" is called "No Estimating," OK.

    This leaves open

    1. the total budget needed for the capabilities
    2. the "final" updated capabilities

    This approach is found in early stage development contracts in many domains from architecture - give me sketches, to biopharma - show it "can" be done, to incremental (R&D) DOD/NASA/DOE programs - pre Milestone A (early exploration).

    But you ARE estimating, just on a higher level, with wider variances.

    1. It might be. I'm not really sure. But at least I think it's not estimate-driven or estimate-focused.

      But I'm not really talking about making experiments in that way - but to actually create something useful, something that will be used as is.

      Once again, my goal is not to stop doing estimates. My goal is to create options, give alternative ways to solve a problem. And to use learning as a tool for gaining knowledge instead of only use estimates as a tool.