#NoEstimates - Alternatives to estimates
Henri Karhatsu
Twitter: @karhatsu
Lyon - Jun 3, 2014
What is #NoEstimates?
Method, process, tool,..? Ten steps to #NoEstimates..?
#NoEstimates is "just" a hashtag for estimation related discussion in the context of software development - Why do we estimate? Is there something wrong with it? Are there better ways? ...
"We are uncovering better ways of developing software by doing it and helping others do it."
Definition by Woody Zuill:
"#NoEstimates is a hashtag for the topic of exploring alternatives to estimates for making decisions in software development. That is, ways to make decisions with 'No Estimates'."
And one more thing...
#NoEstimates != never estimate
So what other ways to make decisions do we have?
Let's try something else together...
Instead of giving an estimate right a way (or denying to estimate), try to understand what kind of decisions are made based on it.
Think what is the best possible way to help for making the decision. It's not always by giving a time estimate. (IME it rarely is.)
What if estimating is part of our development process (Scrum)?
And if we stop estimating, we lose important conversations?
Are the estimates really the only way to create conversations? Your team probably has then bigger problems than estimating...
What if two people estimate a story to be 5 points? Are you sure that they have similar reasoning behind their estimates?
Example of a team that started with hour estimates, changed to story points, then to S/M/L estimates, and finally stopped doing sprint estimates completely.
One of the most important things for the team was that they learned to split stories into smaller ones.
Ask "can we make this story smaller?" or
"can we make it simpler?"
Splitting naturally creates conversation, and smaller stories are easier to understand. No estimates needed.
As a side product you are creating yourself options (and that is a really important thing, more later...).
Behind a need to estimate there usually is a need to reduce uncertainty.
"I need your time estimate because otherwise I'm not sure if I'm making the right decision."
Unfortunately estimates (sometimes aka educated guesses) rarely reduce true uncertainty, they only create a false sense of certainty.
So how to increase true sense of certainty?
Best way to remove uncertainty in software development is to manager something concrete.
If your team delivers once a month, your manager naturally is interested in your estimates.
If your team delivers once a day, your manager isn't interested anymore how long something will take.
If you deliver often, people are not interested in estimates, they are interested in what you deliver next.
Try to improve your process so that delivering working software often is a norm.
Let me repeat: Try to improve your process so that delivering working software often is a norm.
(Notice that you probably cannot do this without test automation, build automation, small enough stories, good code quality etc.)
When there is a nice flow, the most important question isn't anymore how long task X will take.
The most important question becomes: How important task X is compared to the others from the business point of view?
In other words, the most important factor that defines when something will be done, is the assumed business value, not the short-term development cost.
ROI = (value - cost) / cost
but what if cost ~ 1?
More reasons behind the need to estimate...
What's wrong with this (sub) organization structure?
Would you rather prefer this kind of structure? Why?
Build an organization without communication barriers. Build an organization with high visibility.
If development team and management are close to each other, the need to estimate lessens.
The need to know when something is ready is usually a valid need.
However, quite often:
When will it be ready? = How long does it take to program it? (Which are not the same thing!)
It is better to ask how important the task is compared to the other possible ones.
Also, what is the possible deadline and what are the consequences of being late?
Example:
Initial question: How long will this take?
Reason behind the need to know: This has an effect on the marketing material that will be published in two weeks.
Cost of delay question: What happens if this feature isn't ready and cannot be marketed?
Opportunity cost question: What happens if this feature is ready but some others aren't?
Result: The business value of the feature isn't big enough. Let's focus on other features instead.
Consider cost of delay and opportunity cost before development cost
What if you need to know when a collection of stories might be done?
Is the only possibility to estimate all the stories (with e.g. days or story points) and count the estimates together?
If you have collected data from your progress (e.g. finished stories / week), you can use that data to forecast.
If you consider forecasting and estimating pure synonyms, I'm fine with that.
Just see the difference between estimates based on guesses and estimates based on real data.
Another example of using weekly throughput:
Team has finished on average 2 stories / week. 4 weeks time before the release. 25 stories waiting to be done.
The team could waste its valuable time on estimating how many days each of the 25 stories (or subset of them) takes.
Or it can just calculate that the expected value is 8 stories during 4 weeks and also calculate the likelyhood for that.
As a result the Product Owner makes heavy prioritization.
Notice that the historical data is valuable only if the future work is assumed to be similar enough as in the past.
That is again one reason to split big stories into smaller ones.
What about the new projects?
Surely we have to estimate their cost in order to know whether we should start them at all?
Yes, that is probably reasonable but...
Are you sure you are estimating the right thing?
Software development usually is emergent activity. This means that the backlog you are estimating may have very little to do with the features you will actually build (while you learn during the journey).
If you are about to invest about one million euros based on an estimate, would you see it reasonable to first invest e.g. 50k for learning more (drip funding)?
Software development done well is building working software in small steps.
Create options with small batch size!
Option to continue, option to quit, option to change direction, option to utilize new information, option not to build a planned feature,...
But what if we know the needed features very well beforehand and we just need to know the approximate project cost?
Well, if you think that none of the alternatives above doesn't help and you think that estimating is the best answer for that need, go ahead and estimate!
Remember, #NoEstimates != never estimate
But remember that there are alternatives to estimates. And basically it's all about uncovering better ways of developing software.
Alternatives like...
Try to understand what kind of decisions are made based on the asked estimate. Think what is the best possible way to help for making the decision.
Replace Scrum sprint planning estimates by asking "can we make the story smaller?"
Try to improve your process so that delivering often is a norm.
Build an organization without communication barriers. Build an organization with high visibility.
Consider cost of delay and opportunity cost before development cost.
Measure your progress and estimate based on actual data.
Build - Measure - Learn in small steps.
Those are what I have found.
I'm sure you can find some more.
Thank you!
These slides:
www.karhatsu.com/lyon
