Estimation is associated with Fear, Uncertainty and Death marches. Most of us would rather not estimate. Yet, sometimes we do need estimates and commitments, even on "estimation-less" projects. Play a series of estimation games to experience how different techniques deliver very different results. Learn a few simple rules that turn you into a reliable estimator. But correct estimates aren't enough. See what else is required to deliver on your promises. Learn to deal with the destructive games people play with estimates. Estimating can be Fun, embracing Uncertainty and Delivering.

1. Estimation Games
Pascal Van Cauwenberghe
Nayima

2. His Blog: blog.nayima.be
NAYIMAWe make play work
Consultant.
Project Manager.
Games Maker.

3. Thank you to our sponsors
GOLD
SILVER BRONZE
HOST

4. Eco-System Partners
Support Sponsors Organizer
Thank you to our
media partners

5. Estimate the height of the
highest place in Belgium
In meters or feet

6. # 1: Always give a range
Never give them a number

7. # 1: Numbers are for facts
Ranges are for estimates
I estimate “Between 650 and 700m”
Or “Between 0 et 4000m”
I know it’s 694m (2092 ft)

8. Estimation exercise
• One result per table
• Choose one of three collaboration techniques
• If you can’t choose, let the Post-It choose for you
• RED Post-It
– Estimate as a group, come to consensus
• GREEN Post-It
– Divide the work among you
• YELLOW Post-it
– First estimate individually
– Then combine the estimates as a group

9. Estimation exercise 1
• Surface temperature of the sun (in degrees C)
• Latitude of Shanghai (in degrees)
• Surface area of Asia (in km2)
• Birth date of Alexander The Great (year)
• Dollars in circulation in the US in 2004 (in $)
• Volume of the Great American lakes (in litres)
• Global revenue of “Titanic” (in $)
• Length of the Pacific coastline (Ca, Or, Wa) (in km)
• Number of books published in USA, 1776 to 2004
• Weight of the largest whale (in tonnes)
This quiz is from “Software Estimation” by Steve McConnell (Microsoft Press)
(C) 2006 Steve McConnell. Used with permission
Time’s up! 10 min

10. An estimation joke
• An engineer, a mathematician and an
accountant are sitting at the bar
• The barman asks: “What’s 68+73 ?”
• Engineer: 141
• Mathematician: 68 + 73 = 73 + 68
• Accountant: Usually it’s 141, but what do you
want to do with the number?

11. Why estimate?
What is the expected error margin?

12. #2 Always ask what the estimate
will be used for

13. What have you committed to?
Based on what information?

14. Cone of uncertainty
400%
25%
Watch out: this is the best possible case!

15. #3 Estimation != Commitment
Getting an estimate wrong doesn’t
hurt

16. Estimating money (individually)
• How much money is there in this room?
– Counting only cash dollars
• Re-do the estimation, but this time
– Count the number of people: N
– Count how much money you have on you: M
– Estimate how much money the average person
holds, based on M: M1-M2
– Compute the amount: N * M1 – N * M2

17. What can you count?
• Number of stakeholders
• Number of goals
• Number of events
• Number of business processes
• Number of high-level user stories
• Number of detailed user stories
• Number of screens
• ....

18. #4 First try to measure, count and
compute
Estimate only when necessary

19. Estimating money (in group)
• Estimate as one group per table
• Combine individual estimations into a group
estimate
– Planning Poker style: announce estimates, low/high
estimators explain, again
– Take min and max for a range that covers all estimates
– Take average of min and max for a range that covers
much of the estimates
– ...

20. Aggregate estimates
• Independent estimators
– For example, by playing Planning Poker
• Independent estimation methods
– For example, by combining:
1. Comparison with previous project
2. Expert estimation
3. Counting high level stories

21. #5 Aggregate independent
estimates
“Wisdom of the Crowds”

22. The law of large numbers
(or: statistics is on our side, for once)
• If we estimate with an error of x%
• The estimate of each scope item will have an
error of x%
• But...
• Some items will be over-estimated, others
under-estimated (maybe....)
• => The error on the total estimate is < x%

23. The law of 15
• Have about 15-20 same-sized elements at
each planning horizon
– Program, Project, Release, Iteration
• Enough for the law of large numbers to have
an effect
• But not too many, easy to manage

24. #6 Use the law of large numbers
Decompose
Just enough, just in time

25. Sprint Commitment
Sprint Burndown

26. Release Burndown

27. Velocity Chart
0
5
10
15
20
25
1 2 3 4 5 6 7 8
Velocity per iteration
Velocity
Linear (Velocity)

28. Re-estimation and calibration
• First estimation:
– Relative estimate (1 point, 2 points, ...)
– Calibrate with previous projects (16-22 points per
iteration)
• Re-estimate during the project
– Check if relative sizes are ok
– Re-calibrate with measured velocity

29. Ensure consistency of relative
estimates
• Build in internal consistency
– Demonstrated in “XP Game”
• Analyse large errors in retrospectives
– Some variance is normal
• Keep a library of representative reference
stories
– Estimate relative to references
– Add stories that were mis-estimated!

30. Velocity of the first project
• Take a similar, finished project
• Estimate relatively in Story points: N points
• We know it took M mandays
• Decide how many mandays per iteration: K
• Velocity = +/- K * N/M points/iteration
• Attention: M is complete cost
– No “Twilight Zone” or “Murky Zone”!

31. #7 Calibrate your estimates with
real velocity data
Project data >
Company data >
Industry data

32. Evil Estimation Games
• “Guess the number I’ve got in my head!”
• “An awesome team like you can do better than that!”
• “This time it’ll go so much faster, because we learned
so much from the previous project!”
• “This project will be very different!”
• “If we just work a bit harder, we’ll increase velocity”
• “I could code this in half the time!”
• “If we lower the estimate, the project will be done
faster” (this actually works in some circumstances...)

33. Q: Why are there so many pointy
haired-bosses?
A: because there are so many
Dilberts

34. #8 Never negotiate estimates
Always question the reasoning and
assumptions behind estimates

35. #9 Never negotiate
commitments

36. #10 Solve problems together
Make assumptions explicit
Question assumptions
Offer options

37. The Options exercise
• Estimate of the project: 5-6 months
• Conference in 3 months
– We need to make a great impression on prospects
– I want to show all our functionality
• Which assumptions are we making?
• What options can you offer?

38. Roadmap OR Kanban?
• Our dilemma:
– Product manager needs to publish a credible long
term roadmap for customers, partners and
integrators
– Development team has flow-based process
without estimation, planning or velocity tracking
• We can’t have both, can we?
• Yes we can!

39. Roadmap AND Kanban
• Roadmap with customer goals, not features
• Product Manager estimates value of achieving
each goal => priorities of roadmap
• Product Manager determines budget per goal
• Quick feasibility check by team
• Each release, PM and team find a way to
achieve release goals within release budget
• Watch flow, ensure release goals are met

40. Summary
1. Ranges for estimates. Numbers for facts.
2. Always ask what the estimate will be used for
3. Estimation is not Commitment
4. Measure, count, compute before estimating
5. Aggregate independent estimates
6. Use the law of large numbers (large ~= 15)
7. Calibrate estimates with measured velocity
8. Never negotiate estimates
9. Never negotiate commitments
10. Solve problems together

41. Estimation exercise 2
• Surface temperature of the sun (in degrees C)
• Latitude of Shanghai (in degrees)
• Surface area of Asia (in km2)
• Birth date of Alexander The Great (year)
• Dollars in circulation in the US in 2004 (in $)
• Volume of the Great American lakes (in litres)
• Global revenue of “Titanic” (in $)
• Length of the Pacific coastline (Ca, Or, Wa) (in km)
• Number of books published in USA, 1776 to 2004
• Weight of the largest whale (in tonnes)
This quiz is from “Software Estimation” by Steve McConnell (Microsoft Press)
(C) 2006 Steve McConnell. Used with permission
Time’s up! 6 min

42. Answers
• Sun: 6000° C
• Shanghai: 31 degrees North
• Asian area: 44,390,000 km²
• Alexander was born in 356 BC
• Dollars in circulation: $719.9 billion
• Great Lakes: 6.8x10^23 litres
• Titanic: 1.835 billion $
• Pacific Coast: 1293 kilometres
• Published books: 22 million
• Whale: 170 tonnes
This quiz is from “Software Estimation” by Steve McConnell (Microsoft Press)
(C) 2006 Steve McConnell. Used with permission

43. And the winner is?
Life is like a box of tasty
Belgian chocolates!

44. Software Estimation – Steve
McConnell
presentation 44 |

45. Session Retro
What Went Well What Went Wrong
Questions? Lessons Learnt
Thank You!
for your Gift of Feedback

47. Merci
Thank You

48. www.agilecoach.net
www.nayima.be
blog.nayima.be
If you want to know more