Agile Estimating and Planning

[material inspired by “Agile Estimating and Planning” by

Mike Cohn]

Laurie Williams
North Carolina State University
williams@csc.ncsu.edu

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/two-
week 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 Harder or easier?

– Great Dane
– Poodle More or less accurate?
– Dachshund
– German shepherd
More or less time consuming?
– St. Bernard
– Bulldog

© 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 A few iterations away
“stories” “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
– Testers Wideband Delphi
– 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/two-
week iteration
October
30

30 story points 6 iterations

© Laurie Williams 2007 13

Not working as fast as planned?

Desired
Features
3 story
yppoints/two-
5 story
week points/two-
iteration 25
week iteration December
October
30

30 story points 6 iterations

10 iterations

© Laurie Williams 2007 14

Not working as fast as planned?

Desired
Features
3 story
yppoints/two-
5 story
week points/two-
iteration
week iteration
October
30

30 story points 6 iterations

18 story points

© 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 400

project 350

 Iterations [or days] are 300

Work Remaining (hours)

250

shown across the 200

horizontal line 150

 Shows the amount of 100

50
work remaining at the 0

start of each iteration 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

 Visual indicator of how

quickly a team is moving
toward its goal

© Laurie Williams 2007 20