This document discusses techniques for software project estimation. It recommends providing estimates as ranges rather than specific numbers, and always clarifying what an estimate will be used for. It emphasizes aggregating independent estimates, using past project data to calibrate estimates, and not negotiating estimates or commitments. Key techniques include decomposing work into independently estimable units, using the "law of large numbers" for accuracy, and re-estimating regularly based on actual project velocity. Overall, the document provides guidance for creating estimates that are useful without being overly precise commitments.

1. Estimation Games Pascal Van Cauwenberghe Nayima

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

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

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

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

6. 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

7. 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) Time’s up! 10min This quiz is from “Software Estimation” by Steve McConnell (Microsoft Press) (C) 2006 Steve McConnell. Used with permission

8. 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?

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

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

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

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

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

14. 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

15. 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 ....

16. #4 First try to measure, count and computeEstimate only when necessary

17. 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 ...

18. Aggregate estimates Independent estimators For example, by playing Planning Poker Independent estimation methods For example, by combining: Comparison with previous project Expert estimation Counting high level stories

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

20. 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%

21. 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

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

23. Sprint CommitmentSprint Burndown

24. Release Burndown

25. Velocity Chart

26. 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

27. 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!

28. 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”!

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

30. 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...)

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

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

33. #9 Never negotiate commitments

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

35. 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?

36. 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!

37. 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

38. Summary Ranges for estimates. Numbers for facts. Always ask what the estimate will be used for Estimation is not Commitment Measure, count, compute before estimating Aggregate independent estimates Use the law of large numbers (large ~= 15) Calibrate estimates with measured velocity Never negotiate estimates Never negotiate commitments Solve problems together

39. 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) Time’s up! 6 min This quiz is from “Software Estimation” by Steve McConnell (Microsoft Press) (C) 2006 Steve McConnell. Used with permission

40. 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

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

42. Software Estimation – Steve McConnell presentation 42 |

43. Session Retro Thank You! for your Gift of Feedback 

45. Merci Thank You

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