Outcome thinking applied to estimation (TLDR; its mostly waste)
Outcome thinking applied to estimation (TLDR; its mostly waste)
Most effort estimating software development is waste. Here's why and where our effort is better spent.
Estimation in software development is mostly wasted effort and should not be part of the routine process of development.
We know estimation is wasted effort because in most cases:
Estimation will not add value to achieving your goal.
A value-first approach changes how we think about the cost of our effort.
Estimation exists mostly to serve the activity-first approach to work and as a crude attempt to prioritise based on cost.
Estimation will not add value to achieving your goal.
Only taking steps towards your goal will add value. And the movement toward your goal is also the best way to understand the effort involved, over time.
Thinking in terms of outcomes encourages a working backwards approach which helps you :
adapt and course correct towards your goal.
be agile in the sense you optimise by identifying only the work you need to do to get to your goal. You achieve this by stopping any work the moment you identify it is not helping you reach your goal.
If you are working this way you will not find much need for estimation. You can exert your energy in more value-adding activities.
A value-first approach changes how we think about the cost of our effort.
Instead of thinking ‘how much time will it take us to do this work' a value-first approach would ask ‘how much would we invest to achieve this?’.
You may be willing to pay substantially more to achieve something than what you guess it might cost.
If we are working top down on an organisation's most important priorities, why would we compromise achieving the most important priority with the second or lower priorities?
“we guessed this would cost this little to achieve the lead in market share so now we will pursue our 2nd top priority instead" is the bizarre cost equation we set ourselves up for.
For this reason, a cost-first approach makes no sense as it constrains artificially to a low information guess.
Instead should be activating our thinking around what else we could be doing to achieve our top priority.
If the goal was to prioritise between achieving two goals would the most useful data point be how little we thought they cost? No, it's '“what is the threshold before achieving the most valuable thing becomes less profitable than the next most valuable thing”.
Sometimes executives will state they need to understand the cost of something to prioritise. This doesn't survive scrutiny.
If this were true, you would hope it would also be a requirement and even more important to understand the value and impact of the highest priority. That it consistently doesn't tell us that cost estimation is firmly an artefact of activity-first planning rather than the quality of prioritisation.
There are times when estimation may make sense to help you achieve a particular outcome but the practice should be strictly reserved for those occasions. The rest of the time there are literally better things you can be doing to help your organisation.
To recap:
Estimation of elapsed time to develop software is a waste of effort.
If you are going to estimate anything for prioritisation it should be “how much effort are you willing to spend to achieve the goal”?
If you have found this interesting you may find some further perspectives on not using estimation by authors such as Vasco Duarte (who also has a book on #noestimates) and from others posting content under the #noestimates tag on various social platforms.
Do you agree with this logic? Do you do any estimation at your organisation? Do you think it is valuable? Please share your views and experience in the comments.