This document discusses moving away from estimation practices in software development and instead focusing on delivering value to customers frequently through iterative development. It notes challenges with estimation such as durations often exceeding estimates and the "estimation game" where developers are pressured to provide unrealistic estimates. Instead of estimates, it recommends tracking lead time and throughput to manage workload and using probabilistic forecasts to set expectations on completion times. The document advocates for prioritizing work, analyzing tasks at a high level, and delivering in small batches to get feedback and adapt quickly.

1. Delight Your Customers:
Insanity: doing the same thing over and
Over again and expecting different results.
-Albert Einstein
The #noestimates Way
Troy Tuttle, KCP
Principal Consultant, Owner
KanFlow.com
troy@kanflow.com
@troytuttle
Rate This Talk!
http://spkr8.com/t/31701

2. Before Lean Software Existed …
(In my mind anyway)

3. What is this #noestimates Thing?
#noestimates means different things to different people
It started as a conversation on Twitter
The #noestimates topic sparked a renewed interest
in the original promise of Agile

4. 1st Rule of #noestimates:
If estimation works for your team or your organization,
Keep Calm and Carry On.

5. “Estimates are a function of duration and uncertainty.
Since we don't like uncertainty,
we convert it simply to duration. “
-Jabe Bloom (@cyetain) #lkna14

6. Estimation Challenges
“Ranges that are given as +/– a constant time or constant
percent are missing the problem’s exponential nature.”
Actual durations exceeded estimates by an average 2.2 times.
Little’s statistical analysis compared developer’s estimates to the
actual task durations. (for example: estimate was 4 hours, it actually took 7 hours)
“Schedule Estimation and Uncertainty”
IEEE Software, May/June 2006
-Todd Little
“It’s not just good enough to double the initial estimate—
some teams have found it appropriate to
multiply by 3, 4, or even Pi.”

7. A manager’s response…

8. The Estimation Game
The Software Estimation Game goes something like this:
Developer: Sure! Looks like it should take about 1 week.
Manager: Joe, would you give me an estimate of how long feature X will take?
-- 2 weeks later, feature “X” is completed. --
Manager: Um, Yeah. Joe, it took twice as long as your estimate. I told management
it would take 1 week. If this happens again, it will require overtime.
Developer: Ok, I understand.
Manager: Joe, would you give me an estimate of how long feature Z will take?
Developer: Sure! It should take about 3 weeks.
-- 3 weeks later, feature “Z” is completed. --
Manager: Great job Joe! Now were making progress!

9. The Estimation Game
Theoretical Task Completion Time
Donald Reinertsen, Managing the Design Factory
Duration
Due Date
Average
Actual Task Completion Time
Duration
Due Date
Average
“Expanding Work”

10. Parkinson’s Law
Work expands so as to fill
the time available for its completion

11. Nature of Knowledge Work
Manufacturing = repeatable processes
Product Development = one time processes
One-time processes are non-deterministic in nature

12. Nature of Knowledge Work
Deterministic Approach
Project Start
Knowledge
“Complete”
Planned Activity
Non-deterministic Reality
Project Start
Knowledge
“Complete”?
What Customer
Really WantsBetter Knowledge
Project Managers in the middle,
pulling out their hair

13. Nature of Knowledge Work
Idea Analysis Design
Build
(Dev)
Test
“Design” Phases “Execute” Phases
Idea Analysis Design
Build
(Dev)
Test Production
“Design” Phases “Execute” Phases

14. What happens when we estimate?
Customer collaboration over contract negotiation

15. Story Points and Velocity are abstractions
that insulate the team and the business from reality
“Yippie! Our Velocity was 25 story points the last sprint.
Let’s go celebrate!”

16. To Story Point or Not to Story Point
X X X X XX X X
?

17. To Story Point or Not to Story Point
@duarte_vasco
-Vasco Duarte
http://bit.ly/vasco_blog

18. The #noestimates Playbook
• Dedicated and stable teams
• Fix time and cost constraints
• Right size user stories
• Iterate and deliver frequently
• Drip Feed or Investment Funding
• Track lead time and throughput
• Speak the language of the business
(don’t use terms from physics)
• Don’t use bullet points in your slides

19. The #noestimates Playbook
Input Q Design Develop Test Done1 2 1
3
12
9
7
8
6
4
5
Lead Time
Throughput
10
14 days from this point
5 stories per week
Upstream Planning
1. Prioritize
2. Analyze
S
S
S
S
SS
S
S
S
S

20. The #noestimates Playbook
If we start a new story today, we expect to complete it in:
Probabilistic Forecasting
<= 5 days (50th percentile)
<= 8 days (85th percentile)
<= 13 days (95th percentile)

21. Delight Your Customers:
Insanity: doing the same thing over and
Over again and expecting different results.
-Albert Einstein
The #noestimates Way
Troy Tuttle, KCP
Principal Consultant, Owner
KanFlow.com
troy@kanflow.com
@troytuttle
Rate This Talk!
http://spkr8.com/t/31701