Agile Software Estimation
•Download as PPTX, PDF•
23 likes•9,950 views
This presentation discusses the following: What is an estimate? What are the factors influencing estimating? How are agile projects estimated? How Agile estimation solves common estimation problems?
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Agile Software Estimation
Similar to Agile Software Estimation (20)
Recently uploaded
Recently uploaded (20)
Agile Software Estimation
- 1. Agile Software Estimation - Sunil Kumar
- 2. Agenda What is an estimate? Scenario What are the factors influencing estimating? How are agile projects estimated? How Agile estimation solves common estimation problems?
- 3. How to estimate this task ?
- 4. What is an estimate? Unbiased, analytical process to predict the duration or cost of a project
- 5. Estimation is the calculated approximation of a result which is usable even if input data may be incomplete or uncertain.
- 6. What does the definition mean?
- 7. By definition estimate is not accurate
- 8. Estimation is prediction not PLAN
- 9. Typical first estimate is off by factor of 4
- 10. We are not good in absolute measurement
- 11. We are good in comparing things
- 12. Estimates are not commitments
- 13. Time is not persistent
- 14. Scenario You are told to estimate a project to “build a space shuttle that will land on moon” You say “It will take 6 months to 2 years” Your superior hears “It will take 6 months”. why? – optimism bias, organization, political and competitive pressures.
- 15. Scenario contd.. 6 month estimate breakup 1 month design 4 months implementation 1 month testing
- 16. Scenario 1 contd.. Design takes 5 weeks, late by 1 week How much did the project slip? 1 week? 25% ?
- 17. Answer 25% slip in project 25% of design = 1 week 25% of implementation = 1 month (approx 4 weeks) 25% of testing = 1 week Total slip in project = 6 weeks
- 23. Group B173 hours
- 25. End user desktop apps
- 27. Etc.
- 28. Group B39 hours
- 32. Group C8 hours
- 34. customer has no technical knowledge
- 35. Don’t let the customer influence you
- 37. Group C99 hours
- 38. Biased opinion
- 40. Re estimation is considered heretic by most organizations so we overestimate by buffering
- 41. Overestimation downside: Goldratt’s student syndrome Eliyahu M. Goldratt
- 42. Competition, pressure from boss, peer-pressure, optimism bias, etc leads us to underestimate
- 43. Underestimating leads to project plan destruction
- 44. More bugs
- 45. Bad team health
- 46. More time in “status” meetings to discuss slippage
- 47. Time-based estimates are not additive for a team of varied skill set
- 48. What is the source of uncertainty in our projects?
- 49. Cloud of uncertainity (if the project is not well controlled)
- 50. Control the effects of overestimation and cloud of uncertainty using project planning and status visibility
- 51. Other factors influencing estimates Unstable requirements Forgetting to include the following while estimating Version control overhead Code review Build, installing More meetings Sick leaves etc
- 52. Always compare your estimates to your actuals or you’ll never be a better estimator Wisdom = Experience + reflection - Aristotle
- 53. Points to remember from Steve McConnell Narrow ranges != greater accuracy Don’t give off the cuff estimates Precision is not accuracy. The project will not take 233.725 hours Find something meaningful to count and keep a record of it. Use expert judgement only as a last resort
- 54. Estimation techniques Expert opinion Analogy Educated guess Disaggregating Planning poker – Agile estimation
- 55. Planning poker http://www.planningpoker.com/ Consensus-based estimation technique for estimating First described by James Grenningand later popularized by Mike Cohn in the book Agile Estimating and Planning
- 56. Planning Poker Estimated in story points for user stories* It is most commonly used in agile software development First described by James Grenning in 2002 and later popularized by Mike Cohn in the book “Agile Estimating and Planning” For Eg: the deck contains the following cards: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. User stories are user requirements of form "As a <Some Role> I want <Some Need> so that <Some Benefit>”
- 57. Planning Poker Each person gets a deck of cards. The story to be estimated is read to all. Attendants ask clarifications for the item. Each person selects a card and puts it on the table facing down. When everyone is done, cards are exposed. If the estimations do not match a short discussion is done. Timer is started for discussion and discussion must cease when it runs out -> Goto 4. Handle next item.
- 58. Why planning poker works ? Those who do the work estimate it. Emphasizes relative estimation Estimates are within one order of magnitude. Reduces anchoring - Everyone's opinion is heard. Modeled for open discussion – forces thinking. It’s quick & fun !
- 59. At the beginning of the project Use story trawling to prioritize tasks.
- 60. How to calculate time? Time (in no of iterations) = ( No of Story points / Velocity of each sprint/iteration)
- 61. Velocity How many points can the team complete in one iteration. Easy to measure. Fixes estimation errors. Easily reflects the project status. Primary parameter in planning.
- 62. How Agile estimation solves common estimation problems?
- 63. Assumptions reduced by constant communication
- 64. Anchoring is eliminated by not estimating in time but relatively
- 65. Cross-functional team while estimating shield from biased opinion
- 66. Blind vote and consensus rules out dominating opinion
- 67. Daily standup, self-organization and burndown charts reduce affect of overestimation
- 68. Estimation is based on team velocity for a sprint, this reduces underestimation
- 69. References Agile estimation and planning – Mike cohn (http://www.mountaingoatsoftware.com/books/1-agile-estimating-and-planning) http://www.slideshare.net/codeburns/the-art-of-estimation-presentation http://www.slideshare.net/aviram37/agile-estimation-sd-forum Software Estimation: Demystifying the black art – Steve McConnell (http://www.stevemcconnell.com/est.htm)
- 70. Questions?
Editor's Notes
- Ames room is a distorted room that is used to create an optical illusion. An Ames room is constructed so that from the front it appears to be an ordinary cubic-shaped room, with a back wall and two side walls parallel to each other and perpendicular to the horizontally level floor and ceiling. As a result of the optical illusion, a person standing in one corner appears to the observer to be a giant, while a person standing in the other corner appears to be a dwarf. The illusion is convincing enough that a person walking back and forth from the left corner to the right corner appears to grow or shrink.Human beings are not good at absolute estimation. For Eg: One cannot tell a weight of a person by just looking at them.
- Temporal estimates are more error prone due to various reasons: skill, knowledge, assumptions, self-efficacy, etc.
- Optimism bias is the demonstrated systematic tendency for people to be over-optimistic about the outcome of planned actions. This includes over-estimating the likelihood of positive events and under-estimating the likelihood of negative eventsIn a debate in Harvard Business Review, between Daniel Kahneman, Dan Lovallo, and Bent Flyvbjerg, Flyvbjerg (2003) – while acknowledging the existence of optimism bias – pointed out that what appears to be optimism bias may actually be strategic misrepresentation. Planners may deliberately underestimate costs and overestimate benefits in order to get their projects approved, especially when projects are large and when organizational and political pressures are high. Kahneman and Lovallo (2003) maintained that optimism bias is the main problem.
- The project plan is created and estimation is broken up into design, implementation and testing
- As the design is slipped by 25%, the estimate is off by 25% not 1 week because we cannot combine the actuals to estimates. Implementation and testing should also slip by 25% because our estimation was off by 25% in case of design.
- Domain experts make a lot of assumptions while providing specification requirements.For example: A mechanical engineer when talks about washers he means “disc shaped plate with a hole used in threaded fasteners”For a hotel manager washer could be “dish washer or washing machine”
- Customers provide anchoring by one of the following ways:1) Size of specification document2) Adding irrelevant details like UI, usernames, password3) Gives extra requirement but asks not to estimate it4) Gives own estimate but asks you to ignore it.
- Biased opinions: “The person working on this project must be expert in Java”“You should know pointers to work on this task”
- There are most probably boss, co-workers in organization who have dominating opinions and they influence the estimates more often than not.
- Downside of overestimation is Parkinson’s law: Work expands to fill time
- Student syndrome refers to the phenomenon that many people will start to fully apply themselves to a task just at the last possible moment before a deadline. This leads to wasting any buffers built into individual task duration estimates.This same behaviour is seen in businesses; in project and task estimating, a time- or resource-buffer is applied to the task to allow for overrun or other scheduling problems. However, with Student syndrome, the latest possible start of tasks in which the buffer for any given task is wasted beforehand, rather than kept in reserve.
- Cone of uncertaintyThe horizontal axis contains common project milestones such as Initial Concept, Approved Product Definition, Requirements Complete, and so on. The vertical axis contains the degree of error found in estimates created by skilled estimators at various points in the project. Estimates created very early in the project are subject to a high degree of error. Estimates created at Initial Concept time can be inaccurate by a factor of 4x on the high side or 4x on the low side (also expressed as 0.25x, which is just 1 divided by 4). The total range from high estimate to low estimate is 4x divided by 0.25x, or 16x.
- Cone of Uncertainty represents the best case accuracy it’s possible to have in software estimates at different points in a project. The Cone represents the error in estimates created by skilled estimators. It’s easily possible to do worse. It isn’t possible to be more accurate; it’s only possible to be more lucky.When the project isn’t conducted in a way that reduces variability—the uncertainty isn’t a Cone, but rather a Cloud that persists to the end of the project. The issue isn’t really that the estimates don’t converge; the issue is that the project itself doesn’t converge, that is, it doesn’t drive out enough variability to support more accurate estimates.
- The Cone narrows only as you make decisions that eliminate variability.
- Make your ranges as wide as they need to be (use theory of cone of uncertainty)
- The planning poker estimation units are not generally temporal.They are relative estimation relative to base. For example: If Login screen task is taken as a base, all other tasks are estimated based on this task.The estimation describe how many times the task is easier / harder than the base task.Finally the base task is calculated in ideal hours / days and remaining tasks time are thus calculated.