Blog The Value of Planning Poker Cards
in Agile Development

Planning poker came about in 2002 as a way to help solve the complexities which so often arise when a team attempts to estimate future work or level of effort. Although it’s an outgrowth of the Wideband Delphi process from the 1970s, planning poker greatly simplifies the process and is designed to be conducted with live teams having real-time discussions.

Due to the level of uncertainty and complexity in software development, planning poker has been widely adopted in the Agile community — particularly on Scrum teams, although it’s not a formal part of Scrum.

The two most common variations are T-shirt sizing and card sizing. Both methods use relative weighting to communicate effort, with the former technique relying on the common American T-shirt sizes: Small (S), Medium (M), Large (L), Extra-Large (XL) and so forth. Card sizing, on the other hand, utilizes a specialized deck of playing cards which are primarily distinguished by closely following a Fibonacci sequence.

So why do we use cards? Why Fibonacci? Why gamify our planning in the first place?

In this post, I’ll introduce the basics of poker planning cards and share how they can be used with Agile development teams to make work more predictable over time. We’ll explore each of these in more detail below, but the general rules and processes of card sizing are as follows:

• Everyone who is necessary to answer questions should be present.
• Only the development team is allowed to participate in the sizing itself.
• Once everyone is familiar and sufficiently comfortable with the work under discussion, usually a single story, each player picks a card to reflect his or her thoughts on the relative “weight” of the effort.
• When everyone is ready, all the cards are shown at the same time.
• Variations in points are then discussed with the goal of reaching a team consensus.
• The final agreement is recorded on the story.

What is a size?

Before we dive any further into the use of the cards and the nature of estimation in Agile, we must first define our terms.

When a “size” is attached to a story, it’s just that: a relative metric. It’s not hours, it’s not days, it’s certainly not weeks. A size is a representation of several factors, not only effort, but also time, risk, dependencies and any other unknowns.

For example, if the size of the login form is deemed a “3,” how does that compare to the sales report? Is it less risk and effort or is it more? How much less or more? Maybe it’s a “2” because we haven’t written the authenticator yet for the login, but we know exactly what query will drive the sales report. Or maybe it’s a “13” because the login is simple and straightforward, but the sales report is going to be a monster with columns which can be hidden and shown — and we don’t even know if the data is all available yet.

It’s important to approach the planning process with this relativity in mind.

Why cards?

Clearly, helping ourselves and each other come to an agreement on the level of effort that will be required before we start doing work is extremely valuable in and of itself. So, what’s up with the cards? The single biggest reason is simply to derail or sidestep groupthink.

Employing the use of cards allows every person on the team a few moments to think through the details of the story — what’s known and what’s unknown — as well as what the risks might be before picking his or her own metric. Keeping this number to ourselves before the reveal prevents conscious or unconscious bias from affecting the results (i.e. “I thought this was a “2,” but the senior dev over there has an “8,” so I better change my number.”).

The best remedy for groupthink is creating free space within which conversation must happen. Just because the junior dev dropped a “13” doesn’t mean she was wrong. It could very well be that she worked on the last iteration of this feature. The senior dev only thinks the new story is a “5” because he doesn’t know what she knows. If the junior teammate quietly accepts the “5,” then the true level of effort becomes obscured and deliveries will be incomplete, late and/or invalid as a result.

Why Fibonacci?

The Fibonacci sequence is a set of numbers that mathematically describe the Golden Ratio which occurs throughout so much of the natural world. It’s derived by starting with two “1”s, then generating the next number by adding the previous two together. So 1+1=2, 1+2=3, 2+3=5, 3+5=8 and so on. As we can see, the numbers quickly develop larger and larger gaps — and this is where the magic happens with card sizing.

We don’t use an infinite scale of course because we are, after all, trying to reach consensus. Instead, some rough standards have arisen over the past few years.

A standard Fibonacci deck:

0, ½, 1, 2, 3, 5, 8, 13, 21, 34, 100, “?”

No, the “?” is not a typo. Often a teammate simply doesn’t have the information to help provide an estimate on a piece of work. That’s okay.

Our current deck:

½, 1, 2, 3, 5, 8, 13, “?”

The development team for which I’m currently the Scrum Master has been together for more than three years and is quite mature in their practice of Scrum. We don’t use the widest range of cards possible in the deck, but the net effect is still similar. Our team used to use “0” occasionally, but after realizing that QA and integration tests always require some amount of reconfiguration, “½” is now the lowest we’ll go.

So why don’t we simply use standard numerical increments? It’s a valid question and there’s a good reason for it. Most developers can identify quite quickly when a simple story is a “1” or a “2” or maybe a “3”, and these numbers tend to have fairly broad agreement. The work in this range is similar and the risks are probably minimal.

But the more unknowns there are, the more external dependencies on other teams, or the more sheer effort involved, the less likely it is that a team will have immediate agreement. Do you really know the difference between a “4” and “3?” Or a “4” and a “5?” The further away from certain you are, the less you know, and that “cone of uncertainty” expands.

We use the Fibonacci sequence to better represent this phenomenon. “I think that might take me about a week to finish,” is a much less certain estimate than, “I’ll have that to you 10 minutes after we get off this phone call.”

Why gamify estimation?

As I mentioned earlier, as humans we all have the ability and tendency to rapidly change opinions — or at least the expression of our opinions — in social groups. Development teams are no exception and the effect can be exacerbated by perceived differences in rank or title.

The gamification of estimation takes this largely out of the equation, so long as the team demonstrates courage and encourages everyone to speak up and participate. The conversations which result for widely differing sizes are usually where the most important refinement of requirements happens.

The following scenario isn’t uncommon during weekly meetings with my team:

This type of conversation is vital, and at the end of it, everyone’s understanding of the work to be done is vastly improved. Everyone is now also in agreement about what the level of effort means when it comes time to plan the next Sprint.

Building trust

Product Owners (POs) have a tendency to want to inject themselves into the work. Which is precisely why one of the main focal points of Scrum is to encourage the PO to leave the dev team alone during the Sprint so that they can get the work done.

For the PO to trust the team, however, there must be some mutual understanding of what’s expected in the next two weeks. During Sprint planning, the dev team takes mutual responsibility for helping each other accomplish everything they’ve agreed to tackle during the Sprint. In order for each individual to agree to the effort and risk of a story, however, the team must reach a mutual decision.

Over time, as a team matures, the accuracy of their estimates and the amount of work they can plan for in a given timeframe will get better and better. When members of a dev team trust each other, their ability to complete everything they’ve agreed to improves and this leads to greater trust from the PO. A PO who trusts the team starts to prioritize and define work in ways that make it easier for the dev team to complete. It’s a win-win-win that ultimately provides users with more valuable and less buggy software.

Reducing that specific complexity is the reason we use Agile — and planning poker cards can be an integral part of that process, both at the outset and ongoing.

Empower stronger Agile teams. Our Agile experts and strategic partnership with Scrum.org give you the tools to transform.

About the Author: