2-3

Estimation Techniques

Dr. Noura Semary

Outline
 Law of diminishing return
 Techniques
 As a team
 One order of magnitude
 Good sequences
 Zero
 Large stories
 Methods for estimating
 Expertopinion
 Analogy
 Disaggregation
Imagine…
 Analogy:
I can spend 1 hour cleaning my car and get a fairly
clean car
 I can call a car-dealing service to wash it and they can
go as far as cleaning small areas with a cotton swab –
far more effort for only slightly better results
 Similarly, we can spend a little time thinking
about an estimate and come up with a number
that is nearly as good as if we had spent a lot of
time thinking about it
The law of diminishing return

 Agile teams use less effort to get a similar

accuracy, and rely on iterative updates to
improve the accuracy
Comments about the graph
 No matter how much effort is exerted, the
estimate is never 100% accurate
 About 10% of the effort gets 50% of the
accuracy
 It is possible to put too much effort into
estimating, resulting in a less accurate
estimate
Techniques
 As a team
 One order of magnitude
 Good sequences
 Zero
Estimate collaboratively as a team
 Traditionally, the person who will do the work
makes the estimate on effort
 In agile plans, at the start, we don’t know for
sure who will be working on a certain story
 So we estimate as a team. The input of others
helps result in more accurate estimates
 Areej:
“I estimate this story at 3 ideal days”
 Leena: “But last time you did a feature like that it took
you much longer.”
Keep the estimation scale at
one order of magnitude
 Studies show we are best at estimating
things that fall within one order of
magnitude
 Canyou distinguish a 1-point story from a 2?
 How about a 66 from a 67?
 A false level of precision
Use a good sequence
 Good estimation scales
 1, 2, 3, 5, and 8 (Fibonacci sequence)
 1, 2, 4, and 8
 Think of the numbers as buckets and the
work as sand, not water
May introduce zero
 Use it when you don’t want a trivial feature to
count in your velocity calculation
 There are two reasons:
 To keep all features within a 10x range, .

 If the work truly is closer to 0 than 1, the team may

not want the completion of the feature to contribute to
its velocity calculations.
May introduce zero
Motive for creating large stories
 Analogy:
 Estimate the distance to your favourite restaurant and mall
 Your estimates will be less accurate if we add Mecca to the
list
 If we estimate all user stories within one order of
magnitude, then we need all stories to be written
at a fine-grain level
 Instead, write large user stories for features
 we may not implement
 that will be implemented far into the future
Themes and Epics
 Theme: set of related stories
 Epic: a large user story
 Add 13, 20, 40, and 100 to estimate these
 NOT for stories to be implemented in the next
few iterations
 True we reduced estimation effort, but estimates
of themes/epics are less accurate than their
smaller stories
Exception:
Partially Completed Stories
 When a team finishes an iteration and is
calculating their achieved velocity, what should
they do if a story is only partially completed?
 If anything in the story is not done, they earn no
points
 If the story is finished (coded, tested, and accepted by
the product owner), team earns all the points
 Works well because velocity in one iteration will be
slightly low and in the next will be slightly high, and in
the end we care about a team’s average velocity
Methods for deriving an estimate

 Three main methods:

 Expertopinion
 Analogy
 Disaggregation
1. Expert Opinion
 An expert is asked to estimate the story,
and based on their intuition and experience
they give it a number
 Quick method
 In agile projects, it’s hard to find an expert
because each story is cross-functional
(Developing this functionality is likely to require a variety of
skills normally performed by more than one person)
2. Analogy
 Estimators compare the story with other stories
 Studies show we’re better at estimating relative size
than absolute size
 Don’t use just a single reference story
 Instead, use triangulation
 Compare the story with an assortment of stories that
have already been estimated
 Example: If thinking of estimating a story at 5 points,
compare it to a story you estimated at 3 and one you
estimated at 8
3. Disaggregation
 Break a large story you find difficult to
estimate into smaller stories you can
estimate
 Disaggregating TOO FAR causes problems
 Forgotten tasks
 Summing many small errors can result in a
larger error
Conclusion: Test your understanding
 What are some advantages of estimating as a
team?
 What is the alternative to using zero?
 Large stories should be used for ______/______
 What is a theme? An epic?
 What is triangulation?
 What is the problem with disaggregating a story
too far?