A guide to priority poker

4 minutes read

Priority poker is a really quick and easy design game for collaboratively prioritising items, be they features, goals, business objectives, usability issues, requirements, bugs or any number of other things. Priority poker will not only help to assign priorities but will also facilitate the discussion as to why something is important; and will help to ensure that everyone who needs to be is included in the prioritisation process. In this article I discuss what priority poker is, how you play it and when you might use it within a project.

What is priority poker?

You’d perhaps guess that priority poker is a new variant of Poker, as played in casinos and backrooms around the world and beloved by Lady Gaga. However, it is in fact a quick and easy design game for prioritising items. I’ve called it priority poker because it’s very similar to planning poker (as often used in Agile projects), the main difference being that instead of choosing estimates players choose and then discuss with the group a priority from a set of cards. I’ve used it successfully in the past to help groups to prioritise a number of different things, including:

• Product features
• Business goals and objectives
• Key performance indicators
• Scenarios and user journeys
• User stories

Sounds like it could be useful? Here’s how it works.

Getting ready to play

Before you start playing priority poker you of course need a list of items to prioritise. You’ll also need to think about how many levels of priority there will be as this will dictate the number of priority cards that you need to provide for each player. I usually use a 5 point scale (e.g. very high priority, high priority, medium priority, low priority, very low priority) but there’s no reason why you couldn’t use a 3 point (e.g. high priority, medium priority, low priority) or even 10 point scale. You’ll also need to allow for additional ‘insufficient information’ cards that players can use when they don’t know enough information about something to assign it a priority.

Once you’ve decided how many levels of priority there will be you’ll need to make your priority cards. These should be playing card sized and should have the card number and priority on just one side.

It’s a good idea to use card, or at least thick paper if you can because thin paper cards (if that’s not a contradiction in terms) can be a little fiddly to use, and you don’t want people being able to cheat by seeing through the paper. I’ve included templates for some 5 priority and 3 priority sets of cards that you can use, or alternatively why not go crazy and create your own.

• Priority cards template – 5 priorities (PDF, 77Kb)
• Priority cards template – 3 priorities (PDF, 87Kb)

Using your poker face

There’s not much point in playing poker on your own and the same goes with priority poker. You’ll want to gather all the people that need to be involved in the prioritisation process, such as stakeholders, product owners, designers, developers, domain experts and perhaps even users, so that they can all take part. Ideally you’ll want to include everyone in the one session, however if you’ve got more than 5 or 6 people you might want to schedule a number of sessions, otherwise the priority poker can become a little unwieldy.

Playing priority poker is dead easy. In fact it’s much easier than playing regular poker as you don’t have to remember any complex rules. Once you’ve got all the players together each should be given a full set of priority cards, including an ‘insufficient information’ card. You then start with the first item to be prioritised and ask everyone to individually (and silently) choose a corresponding priority card (i.e. high priority, medium priority, low priority etc…) and lay it face down on the table. If players feel that they don’t know enough about the item to assign it a priority then tell them to use the ‘insufficient information’ card.

Once everyone has placed a card down you should all reveal your choice at the same time and then take it in turns to discuss what priority you’ve chosen and why. It’s important that everyone reveals their choice at the same time to avoid any collusion, as you don’t want people being swayed by what other people have chosen. Invariably people are likely to have chosen different priorities and you can choose to either collectively agree a priority (having discussed what everyone thinks the priority could be), or create an aggregate score by adding together everyone’s priority card. Having prioritised the first item you then repeat the whole process for the rest until you’ve got a nice list of prioritised items. Simples.

Why is priority poker so useful?

Here are just a few reasons why you should be thinking about using priority poker to help turn that random collection of stuff into a nice prioritised list:

• Priority poker is a really quick, simple and dare I say it even fun way to get a bunch of items prioritised.
• Priority poker is a really good way to include lots of people in the prioritisation process. As soon as you tell people that you will all be playing poker they will be chomping at the bit to be involved.
• Priority poker helps to facilitate the prioritisation process. It highlights where there are differences in opinion and helps to explore ‘why’ a priority makes sense for an item, not just ‘what’ it is.
• Priority poker is very flexible. You can change the different levels of priority and play around with how you calculate a final priority to your heart’s desire.

When can you use priority poker?

Priority poker is incredibly useful throughout a project as there are many times when items need to be prioritised. The main instances when I’ve previously used priority poker for projects include:

• During requirements gathering and analysis to prioritise goals and objects; functional and non-functional requirements; and to prioritise features.
• During design to prioritise personas, scenarios and user journeys.
• Following usability testing and expert reviews to priorities usability issues and recommended changes.
• During testing to prioritise bugs, defects and fixes.
• Within Agile projects to prioritise user stories and the product backlog.