Each deck of Planning Poker® cards comes complete with a hard plastic storage case, 4 individually coloured sets of cards for 4 players and an instruction card. To order a set of cards please click the buttons below. You will need one set per 4 team members. So if you team is 8 strong, you will need to order 2 sets of cards. (Click add to cart twice) For bulk orders or special offers please use the contact form.

• Each pack contains four sets of cards (for four players)
• Professional design and high quality durable finish
• High quality PVC storage box for safe storage
• Numbers in the middle and top for easier identification when holding the set in your hand
• Colour coded back and front for easier identification and sorting
• Only source in Australia

click the images to expand




Planning poker is a card game that helps (Scrum/Agile) teams gain more accurate estimates when planning work. The game is played like the poker card game, by placing a card face down which represents the persons estimate for the work being discussed. Once all players have placed their cards face down, the cards are all turned over at once and the results discussed. The process is repeated until an agreement is reached across the team.




Estimates are an important part of software development and an essential component in the Scrum framework. Software projects cannot be planned correctly without estimates for the work to be completed. Team estimates have been proven to be more accurate than individual estimates. Scrum prescribes that the team completing the work must estimate the work to be done as a whole team.

Fun: Planning Poker® is fun, it gets the team talking and enjoying the process of estimation.

Accuracy: More accurate estimates are gained as the game forces every team member to think carefully about the task and the estimate.

Involvement: Every team member has a set of cards to play Planning Poker® and as such the game involves the whole team and everyone contributes.

Personalities: Each person has a different personality. Some people are loud and forceful whilst others are quiet and timid, some are confident and extrovert, others shy and introvert. Traditionally dominant personalities will run an estimation session, by giving their estimate first and expecting the rest of the team to agree. Given that they are dominate and/or confident in their estimate the team in most situations do follow this estimate. However this is estimate may be completely incorrect and a shy team member may be holding back his comments and estimate which are far more accurate due to these personality differences. Planning Poker® allows each team member to think on their own, choose an estimate and get it out in front of the team all at the same time. Differences are then discussed and the estimates repeated until an agreement is reached or the estimates are adjacent in the number sequence.

Planning Poker® provides a fun and entertaining way to team estimation, helping us overcome personalities and technical abilities.

The term “Planning Poker” was coined by James Grenning and popularized by Mike Cohn of Mountain Goat Software LLC.





You can play Planning Poker® whenever your team needs to estimate the size of an item, user story or task. Traditionally this is done during the sprint planning meeting at the start of a sprint when creating the sprint backlog. It can also be used when estimating the product backlog for release planning purposes.




Each set of cards (there are four in a deck) consist of the following numbered cards: 0, 0.5, 1,2,3,5,8,13,20,40,100 and the following special cards Coffee Cup and the Question mark. The numbered cards represent the value of the estimate that the player has chosen to use for the task. The cards are a modification of the Fibonacci sequence (1) The two earlier cards of 0 and 0.5 are added for estimating purposes and the sequence deviates at 20,40 and 100.
These sequences have been chosen to represent adequate bucket sizes for tasks and to demonstrate that the larger the task becomes the more uncertain the team will generally be about accuracy. Therefore we assume we can reasonably differential between smaller tasks at the 1,2,3 and 5 level but upwards of say 13 the gaps get larger as the complexity increases.
The zero card is a special case card to be used for tasks which would take an extremely small amount of time to complete and would adversely affect the teams velocity (2)

The special cards should be used in the following scenarios:

• Coffee Cup: The player is tired and cannot concentrate and calls for a coffee break. This card can only be used once per player in the team and is often not used at all in practice.
• Question mark: The player really has no idea what estimate to make this time. The player should ideally talk to the team before the team agree to estimate and the whole team should understand the task being estimated before commencing the play of cards. However should confused or a large amount uncertainty still remain the player should play this card.

Step by step playing guide:

1. The team should agree what the estimate consists of. Every team member should understand the definition of “done”. Does this include unit testing, documentation and deployment or is simply code complete? Agree this level of completion before estimation begins.
2. Obtain as many decks of cards required for you team. Each deck provides for 4 team members, having 4 sets of different coloured cards per deck.
3. Give each team member their own set of coloured cards.
4. Discuss the item to be estimated (user story or task)
5. Each player decides on the value of their estimate and chooses the appropriate card (single cards only) and places the card face down on the table without revealing to the other team members what his estimate is.
6. Once all team members have placed their estimate cards face down, the whole team should turn the cards over to reveal the estimates.
7. If all the cards are the same the value is taken as the estimate.
8. If all the cards have a combination of two adjacent numbers say, 3 and 5 then the higher value of 5 should be chosen.
9. If the cards differ more than this. The team should discuss the higher and lower card values to identify where the differences have come from. Examples of possibly incorrectly high estimates are: not realising that a framework component exists to perform part of the task or gold plating. Possible incorrect low estimates are: missing a task that must be completed or not including testing and documentation.
10. Repeat step 5 and 6 until either situation 7 or 8 occurs
11. Move to the next task and repeat from step 4.

For a further detailed description of Planning Poker and estimating please see the Mountain Goat Software website