Agile Software Estimation
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Agile Software Estimation

on

  • 13,748 views

This presentation discusses the following: ...

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?

Statistics

Views

Total Views
13,748
Views on SlideShare
13,673
Embed Views
75

Actions

Likes
14
Downloads
525
Comments
3

8 Embeds 75

http://www.slideshare.net 29
http://myvividcogitations.blogspot.com 17
http://myvividcogitations.blogspot.ru 11
http://myvividcogitations.blogspot.in 9
http://aktionitems.tumblr.com 4
http://www.linkedin.com 3
https://twimg0-a.akamaihd.net 1
http://myvividcogitations.blogspot.com.br 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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.

Agile Software Estimation Presentation Transcript

  • 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
  • 18. Factors influencing estimating
  • 19. Assumptions (domain jargon)
  • 20. Anchoring (by customers)
  • 21. Same specification
    • One page spec
    • 22. Group A
    117 hours
    • 7 Pages spec
    • 23. Group B
    173 hours
  • 24. Irrelevant information for same spec
    • Group A
    20 hours
    • added irrelevant details:
    • 25. End user desktop apps
    • 26. Usernames & passwords
    • 27. Etc.
    • 28. Group B
    39 hours
  • 29. Extra requirements
    • Requirements 1-4
    • 30. Group A
    4 hours
    • Requirements 1-5
    • 31. Group B
    4 hours
    • Requirements 1-5 but told to estimate 1-4only
    • 32. Group C
    8 hours
  • 33. Given anchor
    • Group A
    456 hours
    • Customer thinks 500
    • 34. customer has no technical knowledge
    • 35. Don’t let the customer influence you
    • 36. Group B
    555 hours
    • Same as B customer thinks 50
    • 37. Group C
    99 hours
  • 38. Biased opinion
  • 39. Dominating 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?