#Estimates by Example

This is a follow up on my previous post #NoEstimates by examples. This post is probably less interesting since we all know more or less how to do estimates. This post is mainly for my own "documentation", a  historical note of my own thoughts at the time - a blog post! ;-) There are also a lot of "established" techniques for doing estimates. I'm not claiming to know any of them, and I might have got names mixed up or wrong. Maybe I should learn them. But I'm focusing on this blog post right now...

I've stated before that I have really not a problem working with estimates. I think we might be able to work without them, I'm willing to try and explore that. But I think we also should improve the way we use estimates. This is only true for me and the company I work for - we need to improve this, I'm not saying you have to.

I'm not gonna describe in detail how we work with estimates, let's just say we're not using them in a really good way. In essence, we think we're agile, but we haven't really got the "customer collaboration" thing...

The approach (improvement)

For me it's all about creating options. In almost every situation. If you only do that you're halfway there. Let your customer (or whatever) have options to choose from, let them be in charge on which path to choose (in collaboration). Don't just fall in to same old habits.
In my previous post I only stated that one option is to do estimates. But even choosing this path have options in itself. This is where we need to improve.

The "easy" approach

This is mainly: do a fairly quick estimate, maybe pad it arbitrarily (by whatever experience you have) and then put a price and make a schedule based on it.
How you then handle the erroneous in this estimate against your customer is up to you. Maybe you have a fixed price and some penalties in the contract. Or if you keep the price (and/or time) open, and the customer still pays if going over budget. Or maybe some combination of the two, I don't know.
This could also be called the "rough feeling" estimate.
On the upside, the customer doesn't have to pay a lot of money for us doing a "great" estimate.
If customer chooses this option, really make sure you declare that this is *very* uncertain. If you succeed with this declaration or not is also highly uncertain...

"Level of probability"

This is one I really like, but I also think it's the one that will take most time to produce, and requires some "heavy" estimation work. I haven't done it myself, but I've applied similar approaches.
It's a way of illustrating that estimates are not about *knowing* but that it comes with some level of probability.
Think of it as: "When is it 0% change of delivery and when is it 100% change of delivery? When does it start to *not* be 100% and 0%? What is our best guess (most likely)? When is it 50%?" You then have relative probability diagram, showing something like this:

The diagram can look very different than this, it's just an example, it's up to you to create this. The "curve" is created by keeping the area under the curve the same before and after the 50% mark. Together with the customer you can then choose at what level of probability we want to aim for. And we have visualized that we aren't 100% sure, we *know* it's likely not going to happen, because we (the customer) have chosen the probability level, it's part of "the deal". "We feel a 70% probability is ok, then we probably (with 70% chance) can deliver after X weeks/days/hours/whatever." It's the area under the curve that gives us the likelihood. Thus, to get e.g. 70% likelihood we have to pick somewhere after the 50% mark. And e.g. 20% (why choose that?) is pretty close to the likelihood of 0% (looking at the graph).
I think it's a great tool. 

On the downside I think it will take some time to produce.

The Triple Constraint triangle

This is actually really not an option per se. It can (should?) be applied regardless of option chosen above.

This is a great way of showing that "You can't have it all, at least one side must be kept open. Which one (or two, or all) should be left open for adjustment?"
It's also great to show customer that reducing the length of any side will probably reduce the overall quality in some form. I think it's a great illustration for having discussions.

Others

There are lots of more options to create (and choose from). Please, let me know if you have any other ideas.

Now it's up to our customer to decide what to choose, what they are most comfortable with.

#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.

#NoEstimates is not for me..?

I'm really curious about the #NoEstimates movement, but I can't really get my head around it. What is it? Do we even need to know what it is..? I'm not sure.
Is it: "Don't estimate in any part of the project - from idea to implementation"? Or is it: "Use estimates in a way that is useful for us"?

I don't know. I've written some posts about no estimates, but I've realized I've only stated the problems, not any solutions that correlate to no estimates. Not in a sense that they are about *no* estimates, at least. I've only stated how to do estimates differently.

My issue

The root cause for me with how estimates are used is that they become promises and commitments. The problem with that is that these things easily creates pressure. Pressure that may lower creativity, new ideas, quality etc. You know how it is... I don't know what your issue with estimates are, but this is my biggest problem.

One "solution" (but not related to #NoEstimates)

I think we need to change. We - developers/managers ourselves - are the main reason estimates are treated as commitments and not what they really are: *estimates*. Note that what I will write next fits me, it doesn't necessarily have to fit you or your situation.

This is how I've been doing, and how I think many are doing:
When a customer (or whoever, in the end, are paying us) wants to know how much it will cost (or how long it will take) they usually don't what to know in detail what it will cost, they just want a rough sense. Because, they don't really care what it will cost in detail. But even so, this is how we usually respond: "We'll have to get back to you about this. We will look at it and get back to you next week with an estimated cost." And next week we come back with the figure (and usually a gantt chart): "We have looked at this and we estimated it to 1140 hours with the cost of [1140 x hourly cost]."

What is the problem with this approach? If I where to put on my customers shoes, how can this behavior be interpreted as anything else than a commitment? Someone (we) have put time to come up with a very exact number. My feeling would be: "These guys/girls really seem to know what they are talking about! How can they know this? Let's not ask, they seem professional. This is great!"

So, how should we do then? Well, this is only my opinion, I'm not saying this is the right way. But it could work.

Give them that *rough* feeling they are really asking for - straight away!: "I think this is about a couple of months of work. But it's just a rough feeling." They might actually be fine with that answer, and it can't as easily be interpreted as anything else than an estimate. And if they want a more "detailed" estimate, they have to ask for it, and then we can say: "Yes, but it will probably not be more accurate than my initial rough feeling. But if you want to pay us for doing that, we can do it. But whatever we provide, it will probably still be as uncertain as my initial feeling."

I don't know, it might work. But is it NoEstimates? No, just estimates done differently.

Other approaches

I've read other approaches, under the #NoEstimates flag, to come up with an answer to the question of "How much/How long?"
But, as we can't know in advance what something will cost or how long it will take - if we respond and how ever we came up with a respond: it's an estimate. Period. That's why I don't get NoEstimates. Can we provide an answer to "How much/How long?" without guessing the future? I can't even imagine that. That's why NoEstimates is not for me, at least not right now. But I will still follow the movement :-)