Scrum poker1 is a great tool for planning complex projects and can even be used beyond that to have everyone’s voice be heard in meetings. Back when I was working on my graduation project at the HKU, I used it for planning and early development. To be able to do so I searched the web for ways to acquire a set of cards known as a scrum deck2 but could not find any reasonably priced and well-made decks available in the Netherlands (nor in Western Europe for that matter). What I did find though were a lot of ways to print your own cards. So I quickly whipped together some images and had a couple of decks printed. Since then I’ve been asked a couple of times how I acquired these cards and if I still can. Well, here they are. For those familiar with scrumming, scroll right down for the files and have them printed to your preferences.
Scrum poker is a way to plan a project by breaking it down into its smallest assets and planning those in a relative fashion to determine more precisely how much time each facet will take. This can regularly be used to create or update a planning before or during production, but often you can already start using it in the late concepting face of the product. The benefit of doing so is that by breaking down your concept into the small assets that will be going to form it you flesh it out and get a stronger grasp on what it is you’re making. In this way you can link late concepting to planning and start your production phase with a more realistic view.
Does that sound good? Let’s get started then. First of all, a scrum deck consists of 52 cards divided into 4 equal sets of 13 cards and is thus suited to be used by 4 people. If you want to play with more than 4 people, you need more decks. Since this method works well if everyone on the team is involved, it is wise to get at least 2 decks for standard use. Besides the team members who will play and take part in the discussions it can be good to get a moderator who does not partake himself3.
Every set of cards is a sequence of numbers plus an infinite mark and a question mark4. The cards typically feature numbers alike the Fibonacci sequence with an added 0 at the start, resulting in the following 13 cards per set: 0,1,2,3,5,8,13,21,34,55,89,∞,? The reason for using the Fibonacci sequence is that the higher the numbers get the bigger the gap between two cards will be. This reflects the fact that the bigger an estimate is, the more uncertainty is involved. If a player estimates something to be a 10, she is forced to rethink and find that some of the perceived uncertainty does not exist and play an 8, or account for the uncertainty in her estimate and play a 13. This is also the reason I used the ‘rough’ numbers and did not round of the higher values like some decks do, because that gives the false notion of a high number being well rounded and thus a clean estimate while it is not.
Once every team member has a set of cards, the moderator determines what part of the project will be used as the smallest unit, meaning that it takes the least time to achieve. For the building of a website for example, this may be registering the web address. This will be the ’1′. It is vital that the members talk in units and not in hours or minutes, because this will get them to think alike when playing5. This is because humans are actually very bad at planning time and saying something will take “an hour or so” can result in it taking anywhere between 15 minutes and a day. Thinking in the smallest unit when estimating other assets will stimulate active consideration of the task, where thinking in hours would provoke a thoughtless estimate.
Once the unit has been determined and the cards have been dealt, the actual planning begins. Usually, the team leader will not yet have listed all the assets that need to be build, so she (or the product owner) begins by sketching a user scenario for the project. During this sketch the team determines step by step what will be needed to facilitate the usage6. Once those assets have been determined and written down for each desirable user scenario, a round will be played for each asset. Try to break assets down into the smallest workable parts, the smaller you make them, the better they can be estimated7.
Playing a round
At the start of a round, the moderator shortly introduces the asset, making sure it’s clear for everyone around the table what it is about. All the players pick a card in their hand and put it face down in front of them. Once everyone has chosen their card, the cards will be turned simultaneously and the moderator gives a soapbox to people with high or low estimates (compared to the others). When given a soapbox, a person will offer a quick insight as to why she made this estimate. Do this until a middle ground is met in the group, the estimate doesn’t necessarily have to be a number on card, it can be in between two cards. There may be special scenarios:
- A question mark is played. This means that either the asset is not clear enough, or the player playing the question mark has truly no idea how long it will take to produce this asset. The moderator generally gives the player playing a question mark the first speaking opportunity to explain why it was played.
- An infinite is played. This means the player playing it estimates the asset to be so big or complicated it could take forever to make or may even be impossible. This should result in a discussion about the asset, its meaning in the project and whether it is realistic. It could be that the asset has not been broken down quite enough. If the team finds this to be the case, they will go about doing that on the spot and then play a round for every new asset.
- One or more people make very high estimates. Just like with the infinite this could mean the asset needs to be broken down into smaller assets first. It could however also mean it’s simply something that will take up a lot of time.
- A zero is played. This usually means someone thinks the task will take no time at all. It could be the asset already exists, or is not needed for the project. It could however also mean the smallest unit wasn’t picked correctly. In this case make the estimate in halves or quarters of the smallest unit rather than redefining it, unless you run into this problem a lot.
Write down every final conclusion of an estimate to be used later in the finalisation of the planning by the team leader. The estimates will however often deliver more than just that, which is the beauty of this method. Make notes of useful points in the discussions and be sure to work iterative; if you stumble upon something while playing like a missing asset or a previously unknown dependency between assets, directly apply it to your list and play an extra round when needed.
Some tips and remarks
- Like said before, it is vital to involve everyone in this process, even people that only do part-time tasks. This often helps your team to discover assets the usual production lead might not have considered.
- This method is excellent when working with people that are not yet very adjusted to other team members, because it gives the product owner and team leader a clear view of how long those people feel certain tasks may take8. This is especially useful when planning for disciplines that are unfamiliar to the team leader.
- Scrum poker excels for usage in dynamic (creative) projects that don’t have a clear precedent or common practice to fall back on when making planning estimates.
- If somewhere in the project you discover new assets that are required, add features or need to scrap some, be sure to get back around the table and scrum for the changes.
- It is not so much the estimated number as the team-wide discussion about that estimate that is the fruit of this method.
- This method is very suited for usage in teams where people would normally tend to anchor their points a lot towards certain members due to seniority or experience of those people, because the estimates are made known all at once.
Below are two files, the images are jpg’s with the dimensions that are often requested by Dutch card-printing companies. If you need to edit the size or look of the images, download the psd’s instead and have your way with them.
Copyrights: The images have been made by me, with use of the font ‘OCR A Extended’. I was unable to find the copyrights for this font, if restrictions exist and you claim to be the rightful owner of this font and take offence to this usage, please contact me. These images are distributed for free by me for personal use only. Please do not redistribute them without my permission, or make money by selling the digital files or printed versions of this deck. Adaptations are allowed for personal use.
If you have any questions or want help learning scrum poker, feel free to get in touch. If you want to thank me for making this guide and these files available, hire me to teach you the tricks and trades of scrum poker or link me up to another type of project.
- Not to be confused with scrum as a way of development as mostly used in tech companies, though that philosophy builds from the same basis. [↩]
- Of course I could have written the required cards on some paper and worked with that, but there is something a crisp set of cards brings that a stack of marked paper does not. [↩]
- Since it is good to get every team member involved and many teams will not have someone available to moderate from outside the team, the moderating can be done by the team leader or product owner instead, who will in this case also play. [↩]
- There are decks out there though which use different symbols or numbers. [↩]
- When working with a group that is new to scrum poker, it is generally a good idea to forbid words like minute, hour and day in the conversation altogether. [↩]
- This works for apps and games and the like, but by stretching up the definition of user scenario a bit, any project can be asserted in this way. [↩]
- If applicable to your project, this is a good moment to define dependency as well. Doing so will help you throughout the project to manage the planning and scrap assets ( and with that features) during the project if needed without encountering unforeseen relations between assets when doing so. [↩]
- If the team works with a writer for the first time for example, in a situation without scrum poker, the team leader might make the estimates for his tasks and completely over or underestimate the time certain tasks may take. Even if the team leader has previous experience with the discipline and knows how long she wants something to take, you’d rather hear the writer say a task takes him longer when planning than during production [↩]