Agile Software Estimation
- Sunil Kumar
Agenda
• What is an estimate?• Scenario• What are the factors influencing estimating?• How are agile projects estimated?• How Agile estimation solves common
estimation problems?
How to estimate this task ?
What is an estimate?
Unbiased, analytical process to predict the duration or cost of a project
• Estimation is the calculated approximation of a result which is usable even if input data may be incomplete or uncertain.
What does the definition mean?
By definition estimate is not accurate
Estimation is prediction not PLAN
Typical first estimate is off by factor of 4
We are not good in absolute measurement
We are good in comparing things
Estimates are not commitments
Time is not persistent
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.
Scenario contd..
• 6 month estimate breakup– 1 month design– 4 months implementation– 1 month testing
Scenario 1 contd..
• Design takes 5 weeks, late by 1 week
• How much did the project slip?– 1 week?– 25% ?
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
Factors influencing estimating
Assumptions (domain jargon)
Anchoring (by customers)
Same specification
•One page spec
•7 Pages spec 173 hours
117 hours
•Group A
•Group B
Irrelevant information for same spec
•Group A
•added irrelevant details:• End user desktop apps• Usernames & passwords• Etc.
•Group B
39 hours
20 hours
Extra requirements
•Requirements 1-4
•Group A
•Requirements 1-5
•Group B 4 hours
4 hours
•Requirements 1-5 but told to estimate 1-4 only
•Group C8 hours
Given anchor
•Group A
•Customer thinks 500 • customer has no technical knowledge• Don’t let the customer influence you
•Group B
555 hours
456 hours
•Same as B customer thinks 50
•Group C99 hours
Biased opinion
Dominating opinion
Re estimation is considered heretic by most organizations so we overestimate by buffering
Overestimation downside: Goldratt’s student syndrome
Eliyahu M. Goldratt
Competition, pressure from boss, peer-pressure, optimism bias, etc leads us to underestimate
Underestimating leads to project plan destruction
More bugs
Bad team health
More time in “status” meetings to discuss slippage
Time-based estimates are not additive for a team of varied skill set
What is the source of uncertainty in our projects?
Cloud of uncertainity (if the project is not well controlled)
Control the effects of overestimation and cloud of uncertainty using project planning and status visibility
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
• Always compare your estimates to your actuals or you’ll never be a better estimator
• Wisdom = Experience + reflection
- Aristotle
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
Estimation techniques
• Expert opinion• Analogy• Educated guess• Disaggregating
• Planning poker – Agile estimation
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
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>”
Planning Poker
1. Each person gets a deck of cards.2. The story to be estimated is read to all.3. Attendants ask clarifications for the item.4. Each person selects a card and puts it on the table facing
down.5. When everyone is done, cards are exposed.6. If the estimations do not match a short discussion is done. 7. Timer is started for discussion and discussion must cease
when it runs out -> Goto 4.8. Handle next item.
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 !
At the beginning of the project
Use story trawling to prioritize tasks.
How to calculate time?
Time (in no of iterations) = ( No of Story points / Velocity of each
sprint/iteration)
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.
How Agile estimation solves common estimation problems?
Assumptions reduced by constant communication
Anchoring is eliminated by not estimating in time but relatively
Cross-functional team while estimating shield from biased opinion
Blind vote and consensus rules out dominating opinion
Daily standup, self-organization and burndown charts reduce affect of overestimation
Estimation is based on team velocity for a sprint, this reduces underestimation
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)
Questions?
Top Related