Feeling deflated by disharmony among your 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 that offers a more effective way to estimate work.
It’s the worst, right?
Assigning time-frames to product development tasks can evoke a surprising level of anxiety within a team. 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 uses a specifically designed card deck to estimate the scope of a task from start to finish. As it happens, it’s also the most effective way to quantify and estimate a piece of work. 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?
Planning Poker is a means of assigning meaningful and relative value to a task in order to define and express its scope.
Breaking that down a little bit further… A task is a user story, which is an aspect of a project broken-down into manageable segments of development.
Got it?… Check!
A meaningful and relative value is a number that considers the complexity and size of a task and communicates that information 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?
Here is the answer to those questions…
The Fibonacci Sequence.
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 they 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. You see, what’s more important than the actual number assigned to the story point, is its relative value.
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.
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…
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 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, they lay down their cards together. This reveals all estimate values at the same time.
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 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 or 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.
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.