This document provides guidance on estimating user story sizes using planning poker. It recommends estimating the size separately from estimating duration. Relative estimating is important, where a simple login screen may be a 2 and a complex search feature an 8. Basic math properties like 5 + 5 = 10 should hold. Examples are provided of planning poker card values and an iterative approach is described where estimators provide initial estimates, discuss differences, and re-estimate until consensus is reached.

2. IBusiness Analyst for 6 years and
IIBA NW&E Branch member
Joined Sigma in July 2012
Working on Agile projects for the
past 4 years
Certified Scrum Product Owner

3. Understand the importance of estimating size and
duration separately.
Understand how a team can use relative
estimating.
Give it a go!

6. • How long a user story will take (effort)
• Influenced by complexity, uncertainty,
risk, volume of work, etc.
• Relative values are what is important:
• A login screen is a 2.
• A search feature is an 8.
• Basic math properties should hold
• 5+5 = 10

8. Lion
Kangaroo
Rhinoceros
Bear
Giraffe
Gorilla
Hippopotamus
Tiger

9. • Look for the things you know,
that have known estimates or
sizes
• Use them to help compare tasks
to ensure that they are
relatively similar in size

10. • A little effort helps
a lot
• A lot of effort only
helps a little more

11. • Can you distinguish a 1-point story
from a 2?
• How about a 17 from an 18?
• Use a set of numbers that make
sense; I like: 1, 2, 3, 5, 8, 13, 20, 40,
100
• Stay mostly in a 1-10 range

12. An iterative approach to estimating
Steps
1. Each estimator is given a deck of cards,
each card has a valid estimate written
on it
2. Product owner/Scrum master reads a
story and it’s discussed briefly
3. Each estimator selects a card that’s his
or her estimate
4. Cards are turned over so all can see
them
5. Discuss differences (especially outliers)
6. Re-estimate until estimates converge

13. Round 1 Round 2
Player 1 5 8
Player 2 5 8
Player 3 8 8
Player 4 20 13

14. Task (backlog item) Estimate?
Read (and understand) a high-level, 10-page overview of agile software
development in a celebrity news magazine.
Read (and understand) a densely written 5-page research paper about agile
software development in an academic journal.
Your uncle owns a clock store and wants to sell clocks over the internet. Write a
product backlog for him that he can use to get bids from teams in India to build
his site.
Recruit, interview, and hire a new member for your team.
Create a 60-minute presentation about agile software development for your co-
workers.
Wash and wax your boss’ Camper Van. 2
Read (and understand) a 150-page book on agile software development. 8
Write a 5 page summary on this for your line manager

15. www.planningpoker.com

16. • Estimate size; derive duration
• A little effort helps a lot
• Triangulate
• Use the right scale / range
• Estimate as a team
• Discuss differences (especially outliers)
• Re-estimate until estimates converge