Agile Estimation and Planning

A Quick Guide to Estimating Features

and Stories in Agile Development
Peter Saddington, CSM CSP
Executive Editor
AgileScout.com
@agilescout
Peter Saddington, CSP CSM
Independent Enterprise Agile Coach
Rally Software Agile Coach
Executive Editor AgileScout.com
Author – Scrum Pocket Guide
me@peter.ps
+1.404.669.6662
www.agilescout.com
www.scrumpocketguide.com
Twitter: @agilescout

White Barrel LLC. © 2011 Peter Saddington

White Barrel LLC. © 2010 Peter Saddington
 Product Backlog
• A prioritized list of
features for the given
product
• Stories are
implemented based
on their priority
• The TOP priority
Features are put into
iterations first
• Changes to the
iterations are OK
White Barrel LLC. © 2010 Peter Saddington
 Prioritization Factors to Consider
• Financial value of
features
• Costs of
implementation
• Amount of risk
removed / added
• Training on new
features
• PO should be
enabled
White Barrel LLC. © 2010 Peter Saddington
Prioritization Sliders

White Barrel LLC. © 2010 Peter Saddington

Sizing Features for Release

White Barrel LLC. © 2010 Peter Saddington

 Sizing Features for Release
• Sizing and estimation
happens during an
Iteration Planning Meeting
• “Commitment-driven
iteration planning” is
setting a goal for the
iteration – What we will
commit to and complete!

White Barrel LLC. © 2010 Peter Saddington

Atlanta Snow Day
• Snow day Atlanta on
1/10/2011

• You have volunteered to

help move a mountain of
snow off a parking lot

• How do we estimate how

long this will take?

White Barrel LLC. © 2010 Peter Saddington

 One Way to Estimate
1. Estimate the
amount of snow
2. Measure how
much snow you
can move
3. Estimate the total
duration

White Barrel LLC. © 2010 Peter Saddington

 Size to Velocity
Size = f(Complexity + Amount)

OR

Velocity = f(# of team members, skills, learning,

distractions, sickness, absence, changes, Murphy, ?)
White Barrel LLC. © 2010 Peter Saddington
 Velocity
• Is the rate at which a team can produce
working software
• Used for estimation and planning
• Measured in non-time-referent terms
(Story points)
• Should not be used as a measure of
comparison across teams

White Barrel LLC. © 2010 Peter Saddington

Size Estimate – Derive Duration

White Barrel LLC. © 2010 Peter Saddington

 Estimation Guidelines
• In Agile, we estimate
size, not duration
• Estimates are
intentionally vague
(in the beginning)
• Common estimate
values include:
– T-shirt sizes
– Scale (1-10)
– Fibonacci sequence

White Barrel LLC. © 2010 Peter Saddington

 More Estimation Guidelines
• Size (complexity) is estimated
– A story is estimated to be 5 story points in relative
complexity
• Velocity is measured
– The Team can deliver 15 story points in a 2 week sprint
• Duration is derived
– Based on the Team’s measured velocity of 15 story points per
sprint, it will take the Team 4 sprints to deliver 60 story points

White Barrel LLC. © 2010 Peter Saddington

 Approaching Estimation
• Assign points for smallest and medium sized stories
• Size other stories by comparison or same size

White Barrel LLC. © 2010 Peter Saddington

 Approaches to Sizing
• Estimates are made by a GROUP not an
INDIVIDUAL
– Points sizes never decay
– Sizes don’t change based on estimator
– Use consistent relative scale
• Use techniques
– Analogy
– Decomposition
– Planning Poker

White Barrel LLC. © 2010 Peter Saddington

 Estimate by Comparison / Analogy
3 points

5 points

8 points

13 points
White Barrel LLC. © 2010 Peter Saddington
 Decomposition of a Story
• Goal: Break big stories into smaller stories
• Goal: Define stories that can fit into single iterations
• Remember: A little effort helps a lot
• Remember: A lot of effort only helps a little more

White Barrel LLC. © 2010 Peter Saddington

 Techniques – Planning Poker
1. Each team has a deck of cards – Each card has a point size
2. Product Owner reviews a story (1 minute per story)
A. PO should have enough knowledge about the story to discuss details

3. Analysis (3 minutes per story)

A. The story is briefly discussed with questions
B. The discussion should be sufficient enough to determine the complexity and relative size of work
C. Compare story to other previously sized stories
D. Each team member selects a card that is his or her estimate

4. All cards are presented to the group at the same time

5. Differences and outliers are discussed (1 minute)
6. Re-estimate until estimates converge
A. Time-box card considerations if time is needed to discuss
B. Negotiate a happy medium
C. If one individual is in disagreement, ask them if the consensus is agreeable

White Barrel LLC. © 2010 Peter Saddington

 Breaking Stories into Tasks with
Planning Poker
Using Mike Cohn’s “Ideal Time vs Elapsed Time”:
How long does a football game last?

Questions to ask yourself:

1.How long would [task] take:
2.If it’s all you worked on…
3.You had no interruptions…
4.Had everything you needed to complete it?
White Barrel LLC. © 2010 Peter Saddington
 Ideal vs Elapsed Time in Planning
Poker
It’s much easier to estimate in ideal time
It’s too hard to estimate in elapsed time
•Start with ideal time
•Define what 1 story point equals (1 story point = 1 ideal
day)
•Estimate how many hours each person has available
•Then gradually move team’s thinknig to unit-less story
points (“This story is like that story”).
•“Stop talking about how long it will take” – Mike Cohn
White Barrel LLC. © 2010 Peter Saddington
 Summary
• Remember the purpose of the iteration planning
meeting is to arrive at a commitment to an iteration
goal or set of product backlog items.
• Story point estimation and task estimation takes time!
• The purpose of the meeting is to come up with a list of
tasks and hours.
• The tasks and estimates are a tool for determining
what we can commit to!
• Inspect and adapt your velocity over time with 90%
confidence intervals
White Barrel LLC. © 2010 Peter Saddington
 Resources Used in Presentation
1. Mike Cohn’s Presentations on “Agile Estimating and
Planning” –
http://www.mountaingoatsoftware.com/presentation
s-estimating

2. Dean Leffingwell’s book – “Scaling Software Agility”

3. Jeff Patton – http://www.agileproductdesign.com

White Barrel LLC © 2010 Peter Saddington

Questions?

White Barrel LLC © 2010 Peter Saddington