@karhatsu
#NoEstimates -
Alternatives to estimates
Henri Karhatsu
Twitter: @karhatsu
Oct 30, 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."
(Agile Manifesto)
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'."
(http://zuill.us/WoodyZuill/2013/05/17/the-noestimates-hashtag/)
And one more thing...
#NoEstimates != never estimate
(Like NoSQL != SQL-is-dead)
So what other ways to make decisions do we have?
(https://twitter.com/WoodyZuill/status/288765769028890624)
I was once asked for an estimate.
Let's see together what happened...
Wanting something != Needing something
"Needing" estimates != Needing estimates
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.)
(http://blog.karhatsu.com/2014/03/need-to-estimate-part-ii.html)
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.
From hour estimates gradually to #NoEstimates
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 deliver working software.
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.)
Basically it's about changing the system conditions from those that require estimates to those that make estimating irrelevant.
For example...
I'm reading a book and want to start the next one immediately after I have finished this one.
So when I order the new book from the internet, I need an estimate when I will get it home.
But what if..?
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 (calendar time) is usually a valid need.
Unfortunatly, quite often...
When will it be ready?
=
How long does it take to program it?
But how about designing, testing, deployment,
release cycle and — the order of tasks?
Instead of asking "When will it be ready?", you could ask "How important the task is compared to the other tasks?"
Also, what is the possible deadline and what are the consequences of being late?
(See also: http://blog.karhatsu.com/2014/10/cost-of-delay-and-artificial-deadlines.html)
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
(short-term) development cost
(And read The Principles of Product Development Flow by D. Reinertsen.)
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.
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)?
How about Build - Measure - Learn?
(Lean Startup by Eric Ries)
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 and with high visibility.
Consider cost of delay and opportunity cost before development cost.
Measure your progress and forecast based on actual data.
Build - Measure - Learn in small steps.
Those are what I have found.
If you are willing to explore,
I'm sure you can find some more.
Dziękuję bardzo!
These slides:
www.karhatsu.com/abe14