The Art Of Estimation

  • 49,433 views
Uploaded on

I read, reviewed and digested the excellent The Art of Estimation by Steve McConnell and presented back what I'd learned about software estimation to the team.

I read, reviewed and digested the excellent The Art of Estimation by Steve McConnell and presented back what I'd learned about software estimation to the team.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
49,433
On Slideshare
0
From Embeds
0
Number of Embeds
9

Actions

Shares
Downloads
554
Comments
0
Likes
7

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. The Art of Software Estimation john burns
  • 2. A presentation I put together as part of a digestion and book review of the excellent Art Of Estimation by Steve McConnell. Any mistakes or inaccuracies are entirely my own doing.
  • 3. What is an estimate?
  • 4. The client needs RiskForce IV before next month or the Death Star will implode. How long do you think it will take? P.s. We should softcode the architecture in case we need to integrate with their Other System running on Paula Bean’s VM. Love, The Boss x
  • 5. An estimate is an unbiased, analytical process to predict the duration or cost of a project.
  • 6. We need RiskForce IV ready to demo at a conference in February.
  • 7. We will have something to demo at the conference in February.
  • 8. It’s a prediction. It is NOT planning!
  • 9. Estimation is not 100% accurate All estimates are probabilities
  • 10. Why bother making estimates at all?
  • 11. Better estimation…
  • 12. Better planning…
  • 13. Lower costs…
  • 14. Greater chance of project success!
  • 15. How do we know if our estimate is good?*
  • 16. Hi RiskWorks! A good estimate should be within 25% of actual results 75% of the time. Steve McConnell
  • 17. For each question, fill in the upper and lower bounds that, in your opinion, give you a 90% chance of including the correct value. Low High estimate estimate 1. Surface temperature of sun 2. Latitude of Shanghai 3. Area of Asian continent 4. The year of Alexanda the Great’s birth 5. Total value of U.S currency in circulation in 2004 6. Total volume of the Great Lakes 7. Worldwide box office receipts for the movie Titanic 8. Total length of the coastline of the Pacific Ocean 9. Number of book titles published in the U.S. since 1776 10. Heaviest blue whale ever recorded
  • 18. Answers 1. Surface temperature of sun 10,000°F / 6,000°C 2. Latitude of Shanghai 31 degrees North 3. Area of Asian continent 17,139,000 square miles 4. The year of Alexanda the Great’s birth 356 BC 5. Total value of U.S currency in circulation in 2004 $719.9 billion 6. Total volume of the Great Lakes 2.3 x 10^16 litres 7. Worldwide box office receipts for the movie Titanic $1.835 billion 8. Total length of the coastline of the Pacific Ocean 84,300 miles 9. Number of book titles published in the U.S. since 1776 22 million 10. Heaviest blue whale ever recorded 170 metric tons
  • 19. How did you do?
  • 20. Where did the pressure to narrow your ranges come from?
  • 21. They came from within
  • 22. Narrow ranges != greater accuracy; Make your ranges as wide as they need to be
  • 23. over estimate? under
  • 24. Parkinson’s Law Work expands to fill time
  • 25. Goldratt’s student syndrome
  • 26. Underestimating will make them fearful, increasing their rate of work. The empire will soon be mine.
  • 27. Underestimating leads to project plan destruction
  • 28. More bugs
  • 29. Bad team health Bad team health Image: sick
  • 30. More time in status meetings to discusstime spent in status meetings at the end of the project More slippage
  • 31. Control the effects of overestimation using project planning and status visibility Not by buffering your estimates
  • 32. What’s the source of uncertainty in our estimates?
  • 33. Cone of uncertainty
  • 34. Cloud of uncertainty
  • 35. The cone doesn’t narrow itself You have to force it to narrow by reducing variability
  • 36. Unstable requirements are the worst offender
  • 37. Project chaos leads to uncertainty in estimates
  • 38. Remember to include: Testing Support of old projects Version control Building the installer More meetings…
  • 39. Optimism is bad
  • 40. How do we become better estimators?
  • 41. Don’t give off the cuff estimates
  • 42. Precision is not accuracy The project will not take 233.725 hours
  • 43. Find something meaningful to count and keep a record of it
  • 44. Use expert judgement only as a last resort
  • 45. What about when you’re agile?
  • 46. Measure story points per sprint
  • 47. Use t-shirt sizing at the start of the project S, M, L
  • 48. We can easily identify early on anything not worth pursuing T-Shirt sizing chart Feature Business value Development cost Feature A Large Small Feature B Small Large Feature C Medium Large Feature D Medium Medium … Feature Z Small Small
  • 49. We can be better at expert judgement
  • 50. Make tasks more granular 2 days max per task
  • 51. Use ranges not single points with best case and worst case estimates Feature Best Case Worst Case Feature A 1.25 2.0 Feature B 1.5 2.5 Feature C 2.0 3.0 Feature D 0.75 2.0 Feature E 0.5 1.25 Total 6.0 10.75
  • 52. Use the PERT formula to get the effort in the Expected Case Expected case = [Best Case + 4(MostLikelyCase) + WorstCase] / 6
  • 53. Always compare your estimates to your actuals or you’ll never be a better estimator
  • 54. Questions?