Poker Planning Approach

Posted on3/26/2022by admin

Animal Sizing suggestions

If you’ve estimated with Planning Poker, you may very well have used cards with either the Fibonacci sequence, or a modified Fibonacci sequence. The traditional Fibonacci sequence is 1, 2, 3, 5, 8, 13, 21 and so on, with each number the sum of the preceding numbers.

Planning Poker The most popular technique of gross level estimation is Planning Poker, or the use of the Fibonacci sequence to assign a point value to a feature or item (Grenning, 2002).
Planning Poker is a consensus-based technique for estimation, mostly used to estimate effort or relative size of development goals in software product development. Planning Poker is done with story points, ideal days, or any other estimating units. The Scrum Master, Product Owner, and the development team participate in Planning Poker activity.
Iteration Planning Meeting. The iteration planning meeting is the whopper meeting that gets the entire team on board with exactly what functionality will be worked on during the iteration. All the developers and analysts attend (QA find it comes at a very bad time in their cycle, so just a QA representative comes along).
Planning Poker Planning Poker® in Scrum 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.

by Chee-Hong Hsia

Hi all,

Poker Planning Approach Plan

I’m sure all of you have experience the following matter with teams that are new with relative sizing.

Despite all the coaching and training, developers somehow always revert the numbers on the poker cards to time.
There are some T-Shirt sizing cards out there, but on these cards are also numbers displayed.

Because of this, I’m thinking of creating my own poker cards with nothing beside a picture.
I was thinking of something in the animal kingdom so I came up with the following animals:

0 Flea
0.5 Ant
1 Bee
2 Baby chicken
3 Rabbit
5 Dog
8 Lion
13 Horse
20 Hippo
40 Elephant
100 Blue whale
Koffie Coffee beans
? Question mark

I don’t really care if the dog isn’t really twice as big as a baby chicken, but more that it is obvious that it is bigger. Important here is that there should be no discussion about the size of the animals.

what do you guys think? Any animals that needs to be changed? switch? to avoid discussion? :)

I would suggest to try it and see what happens. In the end, it's inspect and adapt, not sticking to practices what makes teams successful. If animals help the team to focus on size instead of time, go for it, however it seems kind of weird that you translate the animals back to points in order to calculate a velocity. The team will learn this and may shift to translating time to points to animals, in which case you didn't win anything.
I have experienced that an experienced team that has understood the meaning of the size of a story doesn't even have to play the planning poker game to get a good estimation.

Posted By Ludwig on 26 Mar 2014 06:36 AM
I would suggest to try it and see what happens. In the end, it's inspect and adapt,

Customizing cards unfortunately doesn’t come cheap, so I was hoping to get it right at the very first time. (I know, not very agile when it comes to that)

however it seems kind of weird that you translate the animals back to points in order to calculate a velocity. The team will learn this and may shift to translating time to points to animals, in which case you didn't win anything.
I have experienced that an experienced team that has understood the meaning of the size of a story doesn't even have to play the planning poker game to get a good estimation.

I don’t believe in good estimations, only bad ones. (mister optimistic he?)
My idea is to abandon everything that has to do with points because from my experience it’s much easier to revert back to time if you are dealing with numbers, especially if you are relatively new with sizing.
Plus it’s just a fun way to do the estimation

I agree that it is a fun way to use animals instead of numbers. Think about how the team can decide how many items they pull into a sprint. You could paint Noah's ark (a ship on which he rescued all animals from the flood according to the bible) on the wall and paint the animal for each story inside the ark.
An agile approach for the cards would be to first use homemade cards, inspect and adapt, and as soon as the team is satisfied with the cards, order printed ones.
Best, Ludwig

Posted By Ludwig on 26 Mar 2014 09:00 AM
I agree that it is a fun way to use animals instead of numbers. Think about how the team can decide how many items they pull into a sprint. You could paint Noah's ark (a ship on which he rescued all animals from the flood according to the bible) on the wall and paint the animal for each story inside the ark.
An agile approach for the cards would be to first use homemade cards, inspect and adapt, and as soon as the team is satisfied with the cards, order printed ones.
Best, Ludwig

Cool idea and thanks for the tip. Will certainly provide feedback on how it went.

Using animals is interesting, however I think you'll need to keep educating the SCRUM team and SCRUM team would need to keep remembering where particular animal stands in the range. I think sub-consciously what people would do is associate the number corresponding to Animal or T-shirt size or any other unit you decide to use within your team.
These Units might be good to start with, however ultimately when the estimates are getting matured, the team could use only numbers to be more precise.

0 Flea
0.5 Ant
1 Bee
2 Mouse
3 Rabbit
5 Cat
8 Dog
13 Lion
20 Hippo
40 Elephant
100 Blue whale

Posted By Justin on 30 Mar 2014 10:04 PM
0 Flea
0.5 Ant
1 Bee
2 Mouse
3 Rabbit
5 Cat
8 Dog
13 Lion
20 Hippo
40 Elephant
100 Blue whale

Thanks :)

Poker Planning Approach Strategies

Planning Poker® in Scrum 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.

To get started with Planning Poker with your team, you can purchase Planning Poker cards from Mountain Goat Software. Or, play Planning Poker online for free.

How Does Planning Poker Work?

At the start of this agile planning exercise, each estimator is given a deck of Planning Poker cards. Each card has one of the valid estimates on it, for example: 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100 and infinity.

For each user story or theme to be estimated, a moderator (usually the product owner or an analyst) reads the description. There will be some discussion, where the product owner answers any questions the estimators have. But the goal of Planning Poker in Scrum is not to derive an estimate that will withstand all future scrutiny. Instead, we want a valuable estimate that can be arrived at inexpensively.

After discussion, each estimator privately selects a Planning Poker card representing his or her agile estimation. Once each estimator has made a selection, cards are simultaneously turned over and shown so that all participants can see one another’s estimate.

Estimates will likely differ significantly. And that’s OK. The highest and lowest estimators explain their perspective so that the team can know where they’re coming from. The moderator takes notes during this agile planning session that will be helpful when the story is programmed and tested.

After discussion, each estimator re-estimates by selecting a card. Often, the estimates will converge by the second round. If not, repeat the process until the team agrees on a single estimate to use for the story or these. It rarely takes more than three rounds in agile estimation to reach the goal.

Tips for Planning Poker in Scrum

Here’s some tips for common challenges in Planning Poker:

Poker Planning Approach Examples

Keep discussions productive: Consider purchasing a two-minute sand timer, and allowing anyone in the meeting to start it at any time. When the sand runs out, the next round of Planning Poker cards is played. This helps teams learn to estimate more rapidly within agile planning.
Break out into smaller sessions: It is possible to play Planning Poker with a subset of the team. It’s not ideal, but a good option if there are many stories to be estimated, as can often happen at the start of a new project.
Choose the right time to play: Estimating teams will need to play Planning Poker at two different occasions. The first time, teams will usually estimate a large number of items before the project kicks off or during first iterations. The second time, teams need to put forth ongoing effort to estimate new stories identified during an iteration.

Poker Planning Approach Definition

You can learn more about Planning Poker in detail in the Mountain Goat Software store or in Mike Cohn’s book, Agile Estimating and Planning.