Agile Estimating and Planning
[material inspired by “Agile Estimating and Planning” by
Mike Cohn]
Laurie Williams
North Carolina State University
[email protected]
This lecture material is copyrighted by Laurie Williams
(2007). However, you are encouraged to download, forward, copy,
print, or distribute it, provided you do so in its entirety (including this
notice) and do not sell or otherwise exploit it for commercial purposes.
Estimating and planning

Estimating – estimating the [resources, time, size]
required to develop a [user story, feature, or
requirement]

Planning – putting the estimates together to
formulate a project plan and schedule
© Laurie Williams 2007
2
Estimating size: concepts

Story point: unit of measure for expressing the
overall size of a user story, feature, or other piece of
work. The raw value of a story point is unimportant.
What matters are the relative values
values.
– Related to how hard it is and how much of it there is
– NOT related to amount of time or # of people
– Unitless, but numerically-meaningful

Ideal time: the amount of time “something” takes
when stripped of all peripheral activities
– Example: American football game = 60 minutes

Elapsed time: the amount of time that passes on the
clock to do “something”
– Example: American football game = 3 hours

Velocity: measure of a team’s rate of progress
© Laurie Williams 2007
3
Coming up with the plan
Desired
Features
5 story points/twoweek iteration
30
October
30 story points
6 iterations
© Laurie Williams 2007
4
Estimating “dog points”


Estimate each of the dogs below in dog points,
assigning each dog a minimum of 1 dog point and a
maximum of 10 dog points
A dog point represents the height of a dog at the
shoulder
– Labrador retriever
– Terrier
– Great Dane
– Poodle
– Dachshund
– German shepherd
– St. Bernard
– Bulldog
© Laurie Williams 2007
5
What if?


Estimate each of the dogs below in dog points,
assigning each dog a minimum of 1 dog point and a
maximum of 100 dog points
A dog point represents the height of a dog at the
shoulder
– Labrador retriever
– Terrier
– Great Dane
– Poodle
– Dachshund
– German shepherd
– St. Bernard
– Bulldog
Harder or easier?
More or less accurate?
More or less time consuming?
© Laurie Williams 2007
6
Estimating story points


Choose a medium-size story and assign it a “5”
Estimate other stories relative to that
–
–
–
–

Twice as big
g
Half as big
Almost but not quite as big
A little bit bigger
Only values:
–0, 1, 2, 3, 5, 8, 13, 20, 40, 100
Near term iteration
“stories”
A few iterations away
“epic”
© Laurie Williams 2007
7
Estimating ideal days

Ideal days vs. elapsed time in software development
–
–
–
–
–
–
–

Supporting current release
Sick time
Meetings
Demonstrations
Personal issues
Phone calls
....
When estimating
g ideal days,
y , assume:
– The story being estimated is the only thing you’ll work on
– Everything you need will be on hand when you start
– There will be no interruptions
© Laurie Williams 2007
8
Deriving an estimate for a user story

Expert opinion
– Rely on gut feel based on (extensive) experience
– Disadvantage for agile: need to consider all aspects of
developing the user story, so one expert will likely not be enough

Analogy
– Relative to (several) other user stories
– Triangulation: little bigger than that “3” and a little smaller than
that “8”

Disaggregation
– Break up into smaller
smaller, easier-to-estimate
easier to estimate pieces/tasks.
pieces/tasks
– Need to make sure you don’t miss any tasks.
– Sanity check: does the sum of all the parts make sense?

Planning poker
– Combines expert opinion, analogy, disaggregation
© Laurie Williams 2007
9
Playing Planning Poker

Include all players on the development team (but less
than 10 people overall):
–
–
–
–
–






Programmers
Wideband Delphi
Testers
Database engineers
Requirements analysts
User interaction designers . . .
Moderator (usually the product owner or analyst) reads
the description and answers any questions
Each estimator privately selects a card with their estimate
All cards simultaneously turned over
Discussion ensures
Re-estimate
Repeat until converge
© Laurie Williams 2007
10
Coming up with the plan
Desired
Features
© Laurie Williams 2007
11
Velocity



Velocity is a measure of a team’s rate of progress.
Velocity is calculated by summing the number of
story points assigned to each user story that the
team completed during the operation.
We assume that the team will produce in future
iterations at the rate of their past average velocity.
–“Yesterday’s weather”
© Laurie Williams 2007
12
Coming up with the plan
Desired
Features
5 story points/twoweek iteration
October
30
30 story points
6 iterations
© Laurie Williams 2007
13
Not working as fast as planned?
Desired
Features
3 story
yp
points/two5 story
week points/twoiteration
week iteration
30 story points
25
December
October
30
6 iterations
10 iterations
© Laurie Williams 2007
14
Not working as fast as planned?
Desired
Features
3 story
yp
points/two5 story
week points/twoiteration
week iteration
October
30
30 story points
18 story points
6 iterations
© Laurie Williams 2007
15
Velocity corrects estimation errors


Since all user stories are estimated relative to each
other . . .
It’s the velocity that should change, not each story
point estimate for future releases
© Laurie Williams 2007
16
Coming up with the plan
Desired
Features
© Laurie Williams 2007
17
Prioritization


Driven by customer, in conjunction with developer
Choose features to fill up velocity of iteration, based on:
– Desirability of the feature to a broad base of customers or users
– Desirability of a feature to a small number of important customers
or users
– The cohesiveness of the story in relation to other stories.
Example:
» “Zoom in” a high priority feature
» “Zoom out” not a high priority feature




But it becomes one relative to “Zoom in”
High
g Priority
y – “Give us these stories to p
provide a minimal
working system.”
Medium Priority – “We need these stories to complete this
system.”
Low Priority – “Bells and whistles? Which stories can
come later?”
© Laurie Williams 2007
18
Coming up with the plan
Desired
Features
© Laurie Williams 2007
19
Burn down charts



Vertical axis shows
number of story points or
hours remaining in the
project
Iterations [or days] are
shown across the
horizontal line
Shows the amount of
work remaining at the
start of each iteration
Visual indicator of how
quickly a team is moving
toward its goal
400
350
300
Work Remaining (hours)

250
200
150
100
50
0
1 2 3 4 5
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
Scrum Day
© Laurie Williams 2007
20