Planning Poker is an agile estimating technique based on Wideband Delphi. Planning Poker brings together multiple expert opinions for the agile estimation of a project. In this type of agile planning, we include everyone from programmers, testers and database engineers to analysts, user interaction designers and more. Because these team members represent all disciplines on a software project, they’re better suited to the estimation task than anyone else. Planning Poker is extremely simple to play while also being accurate enough to use for agile planning.
The basic rules are as follows:
Planning poker is based on a list of features to be delivered, several copies of a deck of cards and optionally, an egg timer that can be used to limit time spent in discussion of each item. The feature list, often a list of user stories, describes some software that needs to be developed. Each participant gets a deck of estimation cards representing a sequence of numbers. The most popular sequences Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, etc.) is used. The moderator PO presents one user story at a time to the team. The Product Owner (or equivalent role) answers any questions the team might have about the story. Each participant privately selects a card representing his or her estimate of the “size” for the user story.
Usually size represents a value taking into account time, risk, complexity and any other relevant factors. When everybody is ready with an estimate, all cards are presented simultaneously. If there is consensus on a particular number then the size is recorded and the team moves to the next story. In the (very likely) event that the estimates differ, the high and low estimators defend their estimates to the rest of the team. The group briefly debates the arguments.
Agile Planning Poker Rules How To Play
The rules of the game. In our previous blog post, we discussed key concepts for Agile planning, such as story points.Let’s continue with the rules of the Planning Poker game. All you need is a deck of planning poker cards. And a team, of course 🙂 Then the procedure is simple: Team refreshes their definition of a baseline story. When planning, we use a tool called planning poker to help estimate the relative size of tasks. Planning poker, or Scrum poker, is a very effective, collaborative planning tool that was first defined by James Grenning in 2002, and made popular by Mike Cohn, founder of Mountain Goat Software.
Example Walk-Through for Planning Poker
The user story is “How many chickens are required for a dinner party for twenty people?”
The Facilitator is Ralph Runner
The Requirements Owner is Debbie Diner
The Estimation Team has three members
Bob Cook
Sue Chef
Ted Baker
In first round of voting:
Round 1
Ralph reads the story, the team discusses the story internally and in case if they have doubts Debbie clarifies them. Casino park lane london.
And as voting begins, Ralph Notes:
Bob has 20
Sue has 13
Ted has 5
Ralph asks high and low voters for their reasoning.
Bob says, “I can eat a whole chicken, so we need one per person.” Ted says, “I thought one chicken would feed three people, and we’d have some vegetarians.” Sue has nothing to add.
Discussion after Round 1
Ralph asks Debbie to respond. Patty says, “Oh, I wrote ‘chicken,’ but I was thinking ‘mutton,’ so use mutton instead of chicken. And we’ll probably have one-third vegetarians, who will get mushroom risotto.”
Sue asks, “What’s a mutton?”
Patty says, “It’s what you call a sheep when you cook it.” Ted says he doesn’t want to eat a sheep. He starts to tell a long joke about sheep, but Ralph says, “Hey, folks, let’s stay focused!” Bob asks, “How many muttons does one person eat?” Patty says, “Its one mutton per person.” There are no more questions, so Ralph calls for a new vote.
In second round of voting :
Team votes again for second round and after voting Ralph founds:
Agile Planning Poker Rules For Dummies
Bob has 5
Sue has 13
Ted has 20
Ralph asks high and low voters for their reasoning. Bob says, “Ted was right last time. Most people won’t eat sheep. They’ll have risotto.” Ted says, “Bob was right last time. We need 20 to cover late-comers and spoilage.” Sue adds, “Thirteen is just right for one-third vegetarians.”
Discussion after Round 2
Ralph asks Debbie the Product Owner to respond.
Debbie says, “I know who will be coming, and the non-vegetarians will love the mutton.
I don’t want to buy extras, because the muttons are very expensive. Also, the risotto is very good, we’ll have plenty, and I’ve told everyone that it’s first-come, first-served.”
Agile Planning Poker Rules Card Game
Sue asks, “What kind of wine do you serve with mutton? White or red?”
Agile Planning Poker Rules For Beginners
When the wine discussion threatens to drag on, Ralph the moderator reminds everyone that they have a lot of estimation to do in a short time, and need to move quickly. There are no more questions, so Ralph calls for a new vote.
In third round of voting:
After third round of voting, Ralph and Debbie find team has come to consensus:
Bob has 13
Sue has 13
Ted has 13
Hence this story is estimated to 13, PO records it and team moves on to next story. What we learn from this Example
So, this example helps to understand that:
Written requirements that make sense to the writer often mean something else to the reader Is it a chicken, or mutton? Implicit assumptions are revealed during a discussion of high-low results.
Note that none of these were mentioned in the requirements:
One mutton feeds one person
A third of the guests are vegetarians
Mutton is expensive, so buy no more than necessary
Mutton lovers who don’t get a mutton will be content risotto
Some may hate mutton, but only mutton-lovers are attending
Distractions beckon, but time is limited, so the facilitator needs to keep the group focused. And that’s it! Planning Poker is a very simple but powerful technique, designed to extract the collective wisdom of the team.
