Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Like this presentation? Why not share!

- The Art Of Estimation by codeburns 57945 views
- Project Estimation Presentation - D... by Promet Source 1764 views
- Software Project Estimation Surviva... by michaelcummings 6188 views
- Estimation techniques and software ... by Mae Abigail Banquil 16320 views
- Software estimation techniques by Tan Tran 6210 views
- Software Estimation Techniques by kamal 92906 views

15,483 views

Published on

What is an estimate?

What are the factors influencing estimating?

How are agile projects estimated?

How Agile estimation solves common estimation problems?

No Downloads

Total views

15,483

On SlideShare

0

From Embeds

0

Number of Embeds

96

Shares

0

Downloads

688

Comments

4

Likes

20

No embeds

No notes for slide

- 1. Agile Software Estimation<br />- Sunil Kumar<br />
- 2. Agenda<br />What is an estimate?<br />Scenario<br />What are the factors influencing estimating?<br />How are agile projects estimated?<br />How Agile estimation solves common estimation problems?<br />
- 3. How to estimate this task ?<br />
- 4. What is an estimate?<br /> Unbiased, analytical process to predict the duration or cost of a project<br />
- 5. Estimation is the calculated approximation of a result which is usable even if input data may be incomplete or uncertain.<br />
- 6. What does the definition mean?<br />
- 7. By definition estimate is not accurate<br />
- 8. Estimation is prediction not PLAN<br />
- 9. Typical first estimate is off by factor of 4<br />
- 10. We are not good in absolute measurement<br />
- 11. We are good in comparing things<br />
- 12. Estimates are not commitments<br />
- 13. Time is not persistent<br />
- 14. Scenario<br />You are told to estimate a project to “build a space shuttle that will land on moon”<br />You say “It will take 6 months to 2 years”<br />Your superior hears “It will take 6 months”. why? – optimism bias, organization, political and competitive pressures.<br />
- 15. Scenario contd..<br />6 month estimate breakup<br />1 month design<br />4 months implementation<br />1 month testing<br />
- 16. Scenario 1 contd..<br />Design takes 5 weeks, late by 1 week<br />How much did the project slip?<br />1 week?<br />25% ?<br />
- 17. Answer<br />25% slip in project<br />25% of design = 1 week<br />25% of implementation = 1 month (approx 4 weeks)<br />25% of testing = 1 week<br />Total slip in project = 6 weeks<br />
- 18. Factors influencing estimating<br />
- 19. Assumptions (domain jargon)<br />
- 20. Anchoring (by customers)<br />
- 21. Same specification<br /><ul><li>One page spec
- 22. Group A</li></ul>117 hours<br /><ul><li>7 Pages spec
- 23. Group B</li></ul>173 hours<br />
- 24. Irrelevant information for same spec<br /><ul><li>Group A</li></ul>20 hours<br /><ul><li>added irrelevant details:
- 25. End user desktop apps
- 26. Usernames & passwords
- 27. Etc.
- 28. Group B</li></ul>39 hours<br />
- 29. Extra requirements<br /><ul><li>Requirements 1-4
- 30. Group A</li></ul>4 hours<br /><ul><li>Requirements 1-5
- 31. Group B</li></ul>4 hours<br /><ul><li>Requirements 1-5 but told to estimate 1-4only
- 32. Group C</li></ul>8 hours<br />
- 33. Given anchor<br /><ul><li>Group A</li></ul>456 hours<br /><ul><li>Customer thinks 500
- 34. customer has no technical knowledge
- 35. Don’t let the customer influence you
- 36. Group B</li></ul>555 hours<br /><ul><li>Same as B customer thinks 50
- 37. Group C</li></ul>99 hours<br />
- 38. Biased opinion<br />
- 39. Dominating opinion<br />
- 40. Re estimation is considered heretic by most organizations so we overestimate by buffering<br />
- 41. Overestimation downside: Goldratt’s student syndrome<br />Eliyahu M. Goldratt<br />
- 42. Competition, pressure from boss, peer-pressure, optimism bias, etc leads us to underestimate<br />
- 43. Underestimating leads to project plan destruction<br />
- 44. More bugs<br />
- 45. Bad team health<br />
- 46. More time in “status” meetings to discuss slippage<br />
- 47. Time-based estimates are not additive for a team of varied skill set<br />
- 48. What is the source of uncertainty in our projects?<br />
- 49. Cloud of uncertainity (if the project is not well controlled)<br />
- 50. Control the effects of overestimation and cloud of uncertainty using project planning and status visibility<br />
- 51. Other factors influencing estimates<br />Unstable requirements<br />Forgetting to include the following while estimating<br />Version control overhead<br />Code review<br />Build, installing<br />More meetings<br />Sick leaves<br />etc<br />
- 52. Always compare your estimates to your actuals or you’ll never be a better estimator<br />Wisdom = Experience + reflection<br />- Aristotle<br />
- 53. Points to remember from Steve McConnell<br />Narrow ranges != greater accuracy<br />Don’t give off the cuff estimates<br />Precision is not accuracy. The project will not take 233.725 hours<br />Find something meaningful to count and keep a record of it.<br />Use expert judgement only as a last resort<br />
- 54. Estimation techniques<br />Expert opinion<br />Analogy<br />Educated guess<br />Disaggregating<br />Planning poker – Agile estimation<br />
- 55. Planning poker<br />http://www.planningpoker.com/<br />Consensus-based estimation technique for estimating<br />First described by James Grenningand later popularized by Mike Cohn in the book Agile Estimating and Planning<br />
- 56. Planning Poker<br />Estimated in story points for user stories* <br />It is most commonly used in agile software development<br />First described by James Grenning in 2002 and later popularized by Mike Cohn in the book “Agile Estimating and Planning”<br />For Eg: the deck contains the following cards: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.<br />User stories are user requirements of form "As a <Some Role> I want <Some Need> so that <Some Benefit>”<br />
- 57. Planning Poker<br />Each person gets a deck of cards.<br />The story to be estimated is read to all.<br />Attendants ask clarifications for the item.<br />Each person selects a card and puts it on the table facing down.<br />When everyone is done, cards are exposed.<br />If the estimations do not match a short discussion is done. <br />Timer is started for discussion and discussion must cease when it runs out -> Goto 4.<br />Handle next item.<br />
- 58. Why planning poker works ?<br />Those who do the work estimate it.<br />Emphasizes relative estimation<br />Estimates are within one order of magnitude.<br />Reduces anchoring - Everyone's opinion is heard.<br />Modeled for open discussion – forces thinking.<br />It’s quick & fun !<br />
- 59. At the beginning of the project<br />Use story trawling to prioritize tasks.<br />
- 60. How to calculate time?<br />Time (in no of iterations) = <br />( No of Story points / Velocity of each sprint/iteration)<br />
- 61. Velocity <br />How many points can the team complete in one iteration.<br />Easy to measure.<br />Fixes estimation errors.<br />Easily reflects the project status.<br />Primary parameter in planning.<br />
- 62. How Agile estimation solves common estimation problems?<br />
- 63. Assumptions reduced by constant communication<br />
- 64. Anchoring is eliminated by not estimating in time but relatively<br />
- 65. Cross-functional team while estimating shield from biased opinion<br />
- 66. Blind vote and consensus rules out dominating opinion<br />
- 67. Daily standup, self-organization and burndown charts reduce affect of overestimation<br />
- 68. Estimation is based on team velocity for a sprint, this reduces underestimation<br />
- 69. References<br />Agile estimation and planning – Mike cohn (http://www.mountaingoatsoftware.com/books/1-agile-estimating-and-planning)<br />http://www.slideshare.net/codeburns/the-art-of-estimation-presentation<br />http://www.slideshare.net/aviram37/agile-estimation-sd-forum<br />Software Estimation: Demystifying the black art – Steve McConnell (http://www.stevemcconnell.com/est.htm)<br />
- 70. Questions?<br />

No public clipboards found for this slide

×
### Save the most important slides with Clipping

Clipping is a handy way to collect and organize the most important slides from a presentation. You can keep your great finds in clipboards organized around topics.

On page 48 it must read 'How many points can the team complete in one iteration ON AVERAGE'.