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.
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.
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.
No comments:
Post a Comment