Agile Software Estimation

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?