Post on 02-Jul-2015
description
#NoEstimates
Vasco Duarte@duarte_vasco
A way to improve estimates that gives you results!
Learn more about NoEstimates:
• How it can help you turn around a failing project
• How it can help you show what is possible and stick to that
• How it can help you find very early if you are late (and get your manager, or customer, to believe you)
• How to apply #NoEstimates without threatening anyone
Become a Beta Reader and get the book for free!
http://NoEstimatesBook.com
Vasco Duarte@duarte_vasco
http://bit.ly/vasco_blog
http://bit.ly/vasco_slideshare
Vasco.Duarte@oikosofy.com
http://NoEstimatesBook.com
#NoEstimates
pictoquotes
Kent Beck – Extreme Programming
Ken Schwaber - Scrum
Taiichi Ohno – Toyota Production System
Edwards W. Deming – Everything above...
“If I have seen further it is by standing on the shoulders of giants” - Isaac Newton
Just Google
it
Customer Collaboration over Contract NegotiationResponding to Change over Following a Plan
#NoEstimates is easy!
1.Select the most important piece of work you need to do
2.Break that work down into risk-neutral chunks of work
3.Develop each piece of work4.Iterate and refactor
#NoEstimates How-to
Is the system of development stable?
(ref: SPC)
I AM GOING TO GO AHEAD AND
ASK YOU TO DELIVER 10
STORIES NEXT SPRINT...
0
1
2
3
4
5
6
7
8
9
10
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
velocity
Average=
LCL
UCL
Target
Actual, measured throughput over 21 sprints
WTF!!!!!!#%&!
Can we use the data we observe to predict the system throughput and detect changes that affect system
stability?
1.Velocity outside limits 3 times in a row (“outside limits”)
2.There are 5 or more points in sequence (“run test”)
System stability rules
More in the 1-day #NoEstimates WorkshopInformation by email: vasco.duarte@oikosofy.com
0
2
4
6
8
10
12
1 3 5 7 9 11 13 15 17 19 21
# of items/storiesdelivered
LCL
UCL
average
Team: AT
0
2
4
6
8
10
12
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
LCL
UCL
average
# of items/storiesdelivered
Team: RF
0
2
4
6
8
10
12
14
16
18
20
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
LCL
UCL
average
# of items/storiesdelivered
Team: RF2
0
5
10
15
20
25
1 3 5 7 9 11 13 15 17 19 21
# of items/storiesdelivered
LCL
UCL
average
Team: SH
-1
1
3
5
7
9
11
13
15
17
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
LCL
UCL
average
# of items/storiesdelivered
Team: K
0
2
4
6
8
10
12
14
16
1 2 3 4 5 6 7 8
# of items/storiesdelivered
LCL
UCL
average
Team: MPC
0
2
4
6
8
10
12
14
16
1 2 3 4 5 6 7 8 9 1011121314151617181920
# of items/storiesdelivered
LCL
UCL
average
Team: AS
0
5
10
15
20
25
30
1 2 3 4 5 6 7 8 9 10
# of items/storiesdelivered
LCL
UCL
average
Team: FC
#NoEstimates delivers!
Counting Stories vs. Estimated Story Points
Q: Which ”metric” is more accurate when compared to
what actually happened in the project?
A long project
24Sprints
Which metric predicted most accurately the output of the
whole project?
a) After only the first 3 Sprints
b) After only the first 5 Sprints
Disclaimer...This is only one project!
Find 21 more at: http://bit.ly/NoEstimatesProjectsDB
After just 3 sprints
# of Stories predictive powerStory Points predictive power
The true output: 349,5 SPs
completed
The predictedoutput: 418 SPs
completed
+20%
The true output: 228 Stories
The predictedoutput: 220
Stories
-4%!
After just 5 sprints
# of Stories predictive powerStory Points predictive power
The true output: 349,5 SPs
completed
The predictedoutput: 396 SPs
completed
+13%
The true output: 228 Stories
The predictedoutput: 220
Stories
-4%!
Q: Which ”metric” is more accurate when compared to
what actually happened in the project?
But there is more...
#NoEstimates
RegularEstimates
“The chart is a snapshot of one team of 20+ teams over a 2 year period.” – Cory Foy
Which is more
predictable?
What difference does a Story Point make in a project that used both Story Points and
#NoEstimates?
Next you will see the forecasted release date when
using Story Points (values 1:3:5)
6871 71 71 71 71 71 72 72 72 73 73
0 3 7 7 9 11 12 13
20 20 22 23
0
10
20
30
40
50
60
70
80
90
100
1/3 1/17 1/31 2/14 2/28 3/14 3/28 4/11 4/25 5/9 5/23 6/6 6/20 7/4 7/18 8/1 8/15 8/29 9/12 9/26 10/10 10/24 11/7
Product Backlog Cumulative Flow Diagram
Remaining
Done
Linear (Remaining)
Linear (Done)
Release on 20th October
2014
Next you will see the forecasted release date when
using Story Points (values 1:2:3)
48
51 51 51 51 51 51 52 52 52 53 53
0 2 5 5 7 8 9 1015 15 17 18
0
10
20
30
40
50
60
70
80
1/3 1/17 1/31 2/14 2/28 3/14 3/28 4/11 4/25 5/9 5/23 6/6 6/20 7/4 7/18 8/1 8/15 8/29 9/12 9/26 10/10 10/24 11/7
Product Backlog Cumulative Flow Diagram
Remaining
Done
Linear (Remaining)
Linear (Done)Release on
14th October 2014
Next you will see the forecasted release date when
#NoEstimates (or, all stories = 1 story point)
28
31 31 31 31 31 3132 32 32
33 33
0 1 3 35 5 6 7
10 1012 13
0
10
20
30
40
50
60
1/3 1/17 1/31 2/14 2/28 3/14 3/28 4/11 4/25 5/9 5/23 6/6 6/20 7/4 7/18 8/1 8/15 8/29 9/12 9/26 10/10 10/24 11/7
Product Backlog Cumulative Flow Diagram
Remaining
Done
Linear (Remaining)
Linear (Done)
Release on 29thSeptember 2014
Conclusion...
All dates within 3 weeks of each other in a 38 to 42 week
project (a margin of ~8%)
Data used with permission from Bill Hanlon at Microsoft
”At that point, I stopped thinking that estimating
was important.”
Bill Hanlon: http://bit.ly/BHanlon
In 1986, Profs. S.D. Conte, H.E. Dunsmoir, andV.Y. Shen proposed that a good estimationapproach should provide estimates that arewithin 25% of the actual results 75% of the time
--Steve McConnel, Software Estimation: Demystifying the Black Art
In this presentation you have seen examples that far outperform what estimation specialists consider a ”good estimation”. In common they have one way to look at work: #NoEstimates
#NoEstimates testimonial
The deviation between estimated and actual velocity would have been approximately 15% lower if we would have used #NoEstimates.
We have analyzed data from 50 Sprints…
…at no time the story point based estimation was better than #NoEstimates.
One more thing...
80% Late or Failed
Source: Software Estimation by Steve McConnell
The larger the project, the bigger the problem
Source: Software Estimation by Steve McConnell
Source: Software Estimation by Steve McConnell
Comparison of 17 projects ending between 2001 and 2003. (Average: 62%)
Take #NoEstimates and experiment!
Learn, Be Agile!
Learn more about NoEstimates:
• How it can help you turn around a failing project
• How it can help you show what is possible and stick to that
• How it can help you find very early if you are late (and get your manager, or customer, to believe you)
• How to apply #NoEstimates without threatening anyone
http://NoEstimatesBook.com
Become a Beta Reader and get the book for free!