Time-box
Planning Cards Help Agile Teams Estimate Work
11 January 2018
Agile Workflows
đĽ Update: The limited-edition product sold out!
Exceptional PPM and PMO Solutions™ has Planning Cards as a tool to help agile teams estimate work. Excerpts of the information and instructions—which are included with each deck of the cards—follow. This article is for those interested in getting an overview.
About These Planning Cards
- These cards are used to help estimate work
- Each deck contains four sets of cards—enough for four estimators
- Each of the four sets has a unique color on the front side of cards—it’s in either blue, green, orange, or yellow
- Cards are based on the Fibonacci sequence, where every number after the first two is the sum of the two preceding numbers
- Each set includes cards with the following values: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, and "?"
- Each deck comes in a storage case
Purpose
These cards and instructions support the most popular approach to estimating work in Scrum projects—estimating the complexity of work via story points.
The Development Team—which may be comprised of business analysts, coders, testers, etc.—collaboratively estimates each item in the product backlog in story points. Story points are a relative measure of complexity.
Participants
- Product Owner
- Development Team
- Scrum Master (facilitator/observer)
Frequency
- Once or twice per sprint
Time-box
- One hour for each week of the sprint
- It’s a common practice to limit each meeting to one hour and have multiple meetings as appropriate
Prerequisites/Inputs
- Product backlog containing user stories, bugs, and other requirements
- One set of planning cards for each member of the Development Team
Suggested Steps
1. If each member of the Development Team does not already have their own set of planning cards, the Scrum Master provides materials as needed
2. The Product Owner describes an item (a user story, bug, or other requirement) from the product backlog and mentions its intent and business value
3. Each member of the Development Team silently picks a card best representing their assessment of the complexity of the work and places the card face-down
4. After all of the Development Team members have made their selections, the cards are turned face-up, and the values are read aloud
5. If all of the selections have the same value, the Product Owner records it as the estimate, and that completes the exercise for the item; otherwise, proceed to the next step
6. Team member(s) who gave an outlier value —such as someone who gave a high value and/or someone who gave a low value—explain their reasoning
7. After a brief discussion, the team may take the most common value (the mode average) as the estimate or they may play another round of this planning game (steps 3-7)
8. Steps 2-7 are repeated until each item in the product backlog has been estimated
9. The Product Owner updates the product backlog with the estimate values
Options
Some organizations use a subset of the cards and slice product backlog items when the estimate is "too large." Here's an example:
- Development Team uses cards with the following values: 0, 1, 2, 3, 5, 8, 13, and 21
- Predetermined that 21 is "too large"
- If a product backlog item is estimated at 21, it is sliced into two or more parts in collaboration with the Product Owner, and the resulting smaller items are estimated by the Development Team
This article provided a quick overview of an aspect of estimation in agile projects. Further details—including more information on the Fibonacci sequence, and additional options—are provided in the book, Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions. Agile Scrum is available in paperback and ebook formats at Amazon. For additional information, visit AgileScrumGuide.com.
Let's Connect
Connect with AgileScrumGuide.com on Facebook, Twitter, LinkedIn, Instagram, and Pinterest.
And connect with agile project management practitioner, consultant, award-winning author, and international speaker Scott M. Graffius on Twitter, Facebook, and LinkedIn.
© Copyright 2018 Scott M. Graffius, AgileScrumGuide.com. All rights reserved. This material may not be published, broadcast, rewritten or redistributed without the express written permission of Scott M. Graffius/AgileScrumGuide.com.
