Agile Estimation: How Planning Poker Can Make Your Team More Effective

Feeling deflated by disharmony among your agile team members? Or uneasy about project estimations that don’t reflect true project requirements?

We’ve been there, but we’ve found a better way… It’s Planning Poker, an Agile estimation technique created by Mountain Goat Software that offers a more effective way to estimate work.

It’s the worst, right?

Assigning time-frames to software development tasks can evoke a surprising level of anxiety within agile teams. And, adhering to those time-frames, which are often set using arbitrary criteria by a person who typically isn’t expected to produce the deliverable, can create tension, panic, and burnout.

That’s not good. Let me tell you about a better way…

Two words: Planning Poker

Planning poker, sometimes called scrum poker, was created by James Grenning and made popular by Mike Cohn, both in the 2000s. Planning poker uses a specifically designed deck of cards to eliminate anchoring and other cognitive biases and help more accurately estimate the scope of a task from start to finish. This in turn reduces product backlog and burnout among team members.

It’s simply the most effective way for a development team to quantify a piece of work and engage in an accurate estimation process during sprint planning. But, before I tell you how to play Planning Poker, let me first explain a little bit about why it’s so effective.

What is Planning Poker?

During planning poker sessions scrum teams assign meaningful and relative value to a task in order to define and express its scope within the context of agile estimating and planning.

Breaking that down a little bit further…A task is a user story, which is an aspect of a project broken down into manageable iterations of development.

Got it?… Check!

A meaningful and relative value is a number that considers the complexity and size of a task and communicates accurate estimates to everyone involved, using one singular value.

That one singular value is a story point… Check!

Despite differences in experience or development speed, a user story’s story point will mean the same thing, relatively, to each involved team member.

But, you may wonder, since I know story points don’t arrive on the wings of a mystical dove…Where does the story point actually come from? How do I know which score conveys what scope and communicate that to the whole team?

Here is the answer to those questions…

The Fibonacci Sequence.

Wait…

Honest. That’s the answer.

In true Scrum, story points are assigned using the first several numbers of the Fibonacci Sequence, which is a series of numbers found to be mysteriously significant in math, nature and, as it turns out, Agile estimation.

The Fibonacci Sequence begins with either 0 or 1, and each number following the first two numbers is the exact sum of the preceding two numbers (like this: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, etc). As the sequence evolves, each number tends to be about 60% greater than the preceding number.

Why is that important?

Well— a super smart person realized that this sequence mirrors the way our minds naturally estimate or predict events. In this case, events are user stories and, as the sequence advances, the growth of each number looks a lot like the progression with which we regard complexity.

And so, the Fibonacci Sequence and Agile estimation were married... (awwww!)

While some agile operations assign story points using a “Fibonacci-like” number system rather than true Fibonacci, the concept, and the result, remains generally the same. The relative value of the story point is more important than its actual assigned number.

In other words, if your dev team has assigned a user story with 2 story points, that story should represent twice as much effort as a user story rated with 1 story point. Similarly, the 2 point story should represent roughly half the effort required to fulfill a 5 point user story, and so forth.

Make sense?

So— Planning Poker is the most effective way to quantify and estimate a task. It’s a simple concept with staggeringly effective results.

Planning Poker is efficient and inclusive and, most importantly, it transforms a traditionally dubious, contentious task into one that shares relevant inputs, establishes a unified understanding of the work ahead, and creates a viable metric with which one can measure future sprints.

That's a lot of benefit packed into a little card game...

Hallelujah!

So, in a few steps, here’s how to play Planning Poker…

To set the scene: a deck of Planning Poker cards contains 4 color-coded sets of values used to rate user stories. Each developer is given one set (for example, the red one). Each card in that set has a different value (usually 1, 2, 3, 5, 8, 13, 21, and so forth) with which the developer scores, or sizes, a user story.

1-  The product owner thoroughly, but briefly, explains the user story to the scrum master and dev team.
2- The dev team then asks any necessary questions to ensure they fully grasp the scope of work (including staging/testing/etc) that will be required to take the user story from concept to absolute completion.
3- Each member of the team then quickly determines how many story points they feel summarize the amount of effort required to reach completion.
4- When all players are ready, each estimator lays down their playing cards at the same time. This reveals all estimate values simultaneously.
5- This step may vary.
6- (or 7-) Assign story points to all user stories.

Whaa? Step 5 may vary?

In a perfect scenario, each member of your team will estimate an identical value. If they do this, step number 5 is...

5- Assign that number to the user story and move on to the next one.

But the world is often messy and it’s possible your team will create high and low estimates, and present different scores for one user story. This creates a dialog about complexity and accounts for each team member’s insight into potential hidden difficulties, backlog items, or other items impacting a more efficient approach to completion. In this case, step 5 is…

5- Each player defends their estimate, and everyone repeats steps 3 and 4 until a unanimous score is laid down.

Followed by:
6- Assign unanimous score to the user story and move on to the next one.

And that’s it!

The primary goal of this exercise is to ensure each team member, especially those producing the deliverable, fully comprehend a user story’s pathway to completion. When that unity is achieved, work is performed more effectively, project estimations are more accurate, and expectations are more likely to be met.

But before I let you off the hook, let me give you a few more things...

Here’s a helpful tip:

Be mindful of how much time you spend playing Planning Poker. While you want to be deathly accurate, you also want to be quick about it. Your time is precious, so don’t use it to spin wheels, use it to make progress.

Here’s a sad fact:

Although there's a learning curve inherent to all new tasks, if your team is spending hours defending discordant estimations, you may not have a super cohesive team. (yikes.) This means you may have some work to do in team-building or even that you may need to rearrange or on-board new developers. On the bright side, this sad fact means you can also use Planning Poker to ensure you have a solid, united, ultra-effective team.

Altogether, Planning Poker sounds like a pretty powerful way to form estimates, right? In the end, Planning Poker does these things better than any other agile estimation technique:

• it unites the differing perspectives of your team

• it sets task estimations that are supported by relevant experience

• and it establishes a reliable working velocity

For software developers, stakeholders, and anyone else with their hands on the product, Planning Poker works because it aligns ideas and balances expectations. That’s invaluable.

Want to share your thoughts on Agile estimation and Planning Poker? Please tell us your story in the comments section below.