#NoEstimates and #ImpactMapping - The goal is not to stop doing estimates

The #NoEstimates topic is a bit "infected" and my theory is that it's all about the hashtag - the word. Just like TDD got focused on tests, but the tests doesn't have most value in themself, the tests are just used as a tool for a higher purpose. And that's why the term BDD was invented. But this is another topic...
The same thing with #nosql. The "no" got focus, so the no was changed to "not only". Well, some may disagree about that, but it's unimportant in this post what nosql means.

What I'm trying to say is that the "no" has got the same focus in this #NoEstimates debate. The focus is not on the "no" but on the "estimates". I'm not saying no to estimates. I'm saying that there are possibly other ways to think. I'm not saying that you should abandon estimates, but perhaps focus on other things as well. And maybe you are (just as I am) focusing too much on estimates? Are there more important things to focus on? I do think so. And if you try to focus on other (more important) things, you might find that you move away from estimates more and more?

What am I saying really?

Well, I think that we (as developers and/or consultants) accepts estimates a bit too easily. Estimates are guesses (or even WAGs as Woody Zuill says..?). They can never be anything else since it's about the future and we can't (yet) look into the future. And do we want our customers (clients) to make business decisions based on (our) guesses? Maybe, maybe not... Because, even if we abandon estimates we still have to plan (the verb, not the noun) and planning is about guessing and making assumptions. But I believe the most common way is this:

1. Customer/client has some idea on what they want to do/achieve, i.e. the goal (usually not clearly communicated).
2. Client asks developers to do a rough estimate on how much work it is and how much it will cost.
3. Developers asks for a workshop (or similar) to get a clearer picture on what they want to do (so they can give a more accurate estimate).
4. Workshops are held, and then (after some work, going through the material from the workshops) an estimate (and a plan) is given to client.
5. Client makes a decision if it seems valuable to start the project.

Is this the most valuable way to decide if a system should be built? It's at least very focused around costs and estimates. I'm not sure, but I'm willing to try other ways.

This is where I think #ImpactMapping fits nicely. Read more about Impact mapping http://impactmapping.org/, and most important: read the book if you haven't.

Impact mapping is about discussing the right things, asking the right questions. It's about focusing on value instead of costs and estimates. A system will not be valuable in itself; someone has to interact with it for value to appear. It's about creating impacts! The only way to create value is if the system can impact someones behaviour; change the behaviour of the users interacting with it. Someone should do something e.g. faster, better, cheaper, more accurate, with higher quality etc. (or maybe do something less often or with lower quality?) It's about the change. Discuss: "How can we change X's behaviour so that we can acheive Y?".

Impact mapping is also about creating options. There is never one road to a goal. Create alternate ways to the goal, then focus on which way(s) we should focus on. "Which way do we assume is the best/easiest/cheapest (or anything else) way to our goal?" Follow up and see if the assumption was correct. Stop if it's not, continue (and maybe add the other options) if it is. Discuss what we think will happen if you choose one option over another, what are the tradeoffs?

Just like with a real map we can choose other ways if one way is blocked or leads to a dead end or we notice that another way is better. Or we can turn around and go back if we missed a turn. And we can do it when it happens! Just in time! But we don't have to if it's not necessary! We don't have to make a detailed plan (estimate) on the exact way to go - we have options and we can take actions when things happen! We can stop and look at the map. Create new options when needed.

And speaking of tradeoffs... do we ever discuss the tradeoffs when doing estimates? There are always tradeoffs when choosing one thing over another. If the customer (client) demands estimates, what are they trading off? If they want a fixed price, fixed date or a detailed plan, what are they trading off? Discuss it! And, if we're doing #NoEstimates, what are we trading off then? Remember: it's about creating options, and then decide what we think is best for us at this moment! And step back and validate the decisions and create new options if required.

Anyway, for me, the goal is not to stop doing estimates, it's about exploring if there are other ways (as well) - options! - to make our customers look on and think about value.