Planning poker sounds like a strange concept: people sitting around a table, discussing work, and then turning over and comparing playing cards to determine how complex the work is.
Believe it or not, it’s a lot like it sounds. But don’t underestimate the impact this gamified ritual can have on your ability to estimate the work required to achieve your sprint goals (and plan accordingly).
How does planning poker work in agile software development and what does it really bring to the table?
Planning poker (aka scrum poker) is a technique most often applied in agile software development to help scrum teams estimate the amount of work required to complete tasks in the product backlog.
It doesn’t matter what industry or department you work in or on what kind of project — when it comes to estimating work, you’re virtually guaranteed to encounter roadblocks. Three of the most common impediments are:
In 2002, James Grenning created planning poker as an alternative to the popular project estimation processes of the day because he didn’t think they solved these problems particularly well. His idea became popular when it was included by Mike Cohn of Mountain Goat Software in his immensely popular book, Agile Estimating and Planning.
When we look at the estimation challenges mentioned above, we can see why finding an accurate estimate was a problem for Grenning:
Grenning recognized the need for an approach that:
That’s where planning poker comes in.
To play planning poker, you start with a deck of cards, but not your standard playing cards. Planning poker is played with sets of cards that display numbers that roughly follow the Fibonacci sequence (0, 1, 2, 3, 5, 8, 13…) before drastically increasing (20, 40, 100) and finally ending with infinity (variations on the numbers do occur in some packs).
The numbers are nominally used to represent the anticipated scale of the work under discussion, ranging from zero, which means there is no work to be done, to infinity, which indicates that the work simply cannot be completed.
For example, no work is required if the thing being asked for already exists. On the other hand, you can’t build something for which the technology doesn’t yet exist. In between these extremes, planning poker calls for gradually increasing the numbers according to the perceived effort for that work.
The numbers themselves do not relate to a real-world value of time. For instance, 1 does not equal one hour or one day; it is meant to represent the simplest form of work you do. In some cases, this task might take multiple days.
The important thing here is how the work relates to other pieces of work. Is it bigger than that? If so, is it a little bit bigger or a whole lot bigger?
Over time, scrum teams develop a clearer understanding of how they work as a unit and the effort and time required to complete a given project or task. The team members can use this understanding to ensure that the frame of reference remains constant.
The thing to remember is that the numbers don’t increase in a linear fashion, and neither does the complexity of your work. There are times when a piece of work might reach the point where it gets considerably more complex.
For a simple example, let’s say we’re considering adding an extra line to the shopping basket on our ecommerce site.
We might deem this task a 1; if we were to add two lines, we might see it as a 2 because it requires a little bit more work. When it gets to the point where we’re adding five lines, the planning poker score might jump to an 8 because it would involve redesigning the basket itself to allow for all the extra lines.
Before starting a planning poker session, distribute a full sequence of cards to every person who is participating in the estimation exercise, and you’re ready to get going.
When the first piece of work is described to the group, the members have an opportunity to ask questions and clarify the requirements. Once everyone feels comfortable with the work being discussed, the group is asked to provide its estimate.
Members submit their estimate by turning over a card from their deck. To avoid the second estimation challenge mentioned above — the influence of one person over others — all players must reveal their cards simultaneously.
By this point, you should have a series of cards on display around the table representing the effort assessment of all parties. For example, you might have a collection of cards labeled 2, 2, 2, 3, 3. What does this tell us?
This sequence would indicate that there is a shared understanding — the piece of work isn’t too complex, the task is well-defined, and everyone knows what they’re expected to deliver.
Now let’s look at another example: 2, 5, 5, 8, 13.
Here, the range is much more varied. This indicates that some parties involved consider the work to be more complex than others around the table do. The next step would be to determine what’s causing this difference of opinion.
Starting with the extreme numbers, we need to understand the rationale behind these team members’ scores. Why do they think the work is either very straightforward or complex? What do they know that others don’t? Or, what don’t they know that the others do?
Maybe the team member who scored the task a 13 thinks we’re building the work from scratch and therefore it carries a lot of risk and uncertainty. Maybe the team member who chose 2 knows that they had already built this function two years ago and it was just a matter of dusting it off and redeploying it. These are both things that may not have come up during the discussion.
This approach to reading a range of scoring addresses the first challenge mentioned above by highlighting this variation in knowledge and taking the opportunity to share information.
The objective of this stage is to discuss any differences and reach a consensus on a single score for a given piece of work to represent the team’s collective effort estimation.
Let’s say we’ve performed planning poker on 10 work items and we end up with the following scores: 2, 2, 2, 5, 5, 13, 1, 3, 8, 2. Our next objective is to understand how many of these items can be done within the next work period.
If we plan our work in two-week sprints, how many of these 43 points do we think we’ll get done during that period? Can we do them all, or just a subset of them?
When we start on this path, it’s difficult to know how much work we might get through. But over time, the team builds up a track record of performance and understanding as a group. Eventually, you develop a shared understanding of roughly how many points you can get through in a given period.
Let’s say we average about 30 points every two weeks. We can use this estimation of potential capacity (30 points) to focus on determining which of our 10 work items we can actually complete during the next period of time. Maybe these are the work items represented by the scores 2, 2, 5, 5, 13, 3, but they could also plausibly be 5, 5, 13, 8. The important thing is that you have an idea of what you can realistically do in the time available.
Remember, the end goal of planning poker is to have an estimation, not a 100-percent accurate forecast. Over time, your team’s potential capacity will vary, as will its ability to estimate. But the act of conducting planning poker enables you to eliminate some of the limitations associated with other forms of estimation.
Planning poker is applicable to any process that requires an estimation of effort involved in upcoming work, not just software development. You can use it to estimate the work required to redecorate your home, landscape your yard, organize an office move — the list of potential applications for planning poker is endless.
If you’ve got a list of work and you need to get a rough idea of how complex it is, planning poker can help.
As well as planning poker addresses the challenges associated with work estimation, it isn’t perfect.
It’s entirely plausible, for example, that the group might reach a consensus that is wrong. The team members might all be missing some important information that would increase or decrease complexity. If you have imperfect information, planning poker won’t solve this problem for you.
Over time, teams sometimes tend to shift their frame of reference. What previously was seen as a 1 might now be considered a 3, which will impact the overall estimation of work required.
At the end of the day, stakeholders outside of the estimating team just don’t care about this points system; they only care that on date X, feature Y will be delivered. It is immensely difficult to prevent most areas of the business from thinking about the effort in units of time, and the built-in vagueness of planning poker can drive them crazy.
When all is said and done, what we’re hoping to achieve is a greater understanding of what the future looks like. We want a little more certainty about what we’re going to deliver and when we’re going to deliver it.
If your scrum team is struggling to estimate the time and work required to deliver a product or feature in an agile way, why not give planning poker a try? You’ve got nothing to lose.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
This article covers insights for overcoming common challenges, as well as ways to embrace innovative ecommerce strategies.
Dipto Chakravarty, Chief Product Officer at Cloudera, talks about how it takes rigor to design complex technology and user experiences.
As an alternative, this article outlines a case against MVPs, drawing on my own personal experience in the realm of product management.
No product team starts out trying to harm users. However, harm still happens, and often not from one big decision.
Learn more →
