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
•Group A
•One page spec 117 hours

•Group B
•7 Pages spec 173 hours
 Irrelevant information for same spec

•Group A
20 hours

•Group B

•added irrelevant details: 39 hours

• End user desktop apps
• Usernames & passwords
• Etc.
 Extra requirements
•Group A
4 hours
•Requirements 1-4

•Group B
4 hours
•Requirements 1-5

•Group C
•Requirements 1-5 but told 8 hours
to estimate 1-4 only
 Given anchor
•Group A 456 hours

•Group B
•Customer thinks 500 555 hours
• customer has no technical knowledge
• Don’t let the customer influence you

•Group C
•Same as B 99 hours
customer thinks 50
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-estim
ating-and-planning
)
• http://
www.slideshare.net/codeburns/the-art-of-estimation-
presentation
• http://
www.slideshare.net/aviram37/agile-estimation-sd-foru
m
• Software Estimation: Demystifying the black art –
Steve McConnell (http://
Questions?