Planning poker is one of the most useful tools in Agile Software development, and yet most Agile Marketing teams don’t practice it. Here’s why, if you’re not already practicing planning poker, you should start.
What is Planning Poker?
Planning poker is a tool for estimating the size of each user story in terms of story points. Story points, if you’re not familiar with the term, are a relative measure of the effort and time required to complete a user story. Story points are usually expressed either in numbers that follow the Fibonacci series (1, 2, 3, 5, 8, 13), t-shirt sizes (XS, S, M, L, XL, XXL) or even dog breeds (Chihuahua to Great Dane). User stories are not estimated in hours or days – agile software developers recognized that human beings are not very good at absolute estimation, and are much better at relative estimation. In other words, they’re better at saying the effort to complete this task is about the same (or less or more) than the effort to complete this other task, which is a known and well-understood task.
Planning poker also takes advantage of the so called “Wisdom of Crowds”, the documented ability of groups of people to produce a better estimate than one person acting alone.
Planning poker works like this: each member of the team is given a deck of index cards. Each index card represents a size in your user story sequence (either one of the Fibonacci numbers or a t-shirt size, for example). Each member of the team then chooses a card representing their estimate of the effort involved in completing a particular user story, and places that card face down in front of them. When everyone has chosen a card, they are all turned over.
If all the cards are the same, this becomes the estimate for that user story. Most of the time, however, there will be one or two outliers. That’s when things get interesting, and the real value of planning poker becomes apparent. The team members who contributed the outlier estimates are asked “why did you choose that estimate?” Usually, it’s because they made different assumptions about what really needed to be done to satisfy the user story. The discussion reveals assumptions, which are the single biggest contributor to inaccurate estimates. Based on the discussion, other team members may change their estimates. If necessary, the team plays another round of planning poker; usually, this isn’t necessary, and the team either accepts the assumptions of one of the outliers and changes their estimate, or rejects the assumptions and stays with the majority. Some teams average the results, although most agile teams prefer to get consensus and document any assumptions.
Why is Planning Poker Valuable to Agile Marketers?
Agile marketers, just like agile software developers, need to decide how much work to accept into each individual sprint backlog. Once a sprint backlog is documented and published, it sets up an expectation that the work outlined in the sprint backlog will be done at the end of the sprint.
If the estimates of effort involved are wildly inaccurate, the team will not get all the work done, or have to work unsustainable long hours to get it done. Neither situation is desirable. Not getting the work done damages the credibility of the team; working unsustainable long hours leads to burnout. Accurate estimating is just as important to agile marketers as it is to agile developers.
Getting Started
To get started, you first need to decide on your sequence for estimating user stories. I use a modified version of the Fibonacci series (1/2, 1, 3, 5, 10, 20). These roughly correspond to person-days (1/2 a day to 4 weeks). As soon as possible, I try to get the team to create reference user stories. For example, creating a draft of a press release may be a typical 1/2 story point task. Writing a white paper may be a 5 story point task. And so forth.
Create a deck for each member of the team. During your sprint planning session, as you’re deciding to accept stories into the Sprint backlog, estimate each task in the story using the planning poker procedure outlined above. Make sure that you take the time to discuss the estimates and the outliers. This discussion leads to more accurate estimates.
If everyone is physically in the same room, I recommend using index cards, as referenced above. If, however, you are a distributed team, you may want to use an online tool. Mountain Goat Software has made a free tool for planning poker available at https://planningpoker.com/. Luis Goncalves also has a great article on planning poker over at his blog. Let me know if you decide to use planning poker for agile marketing, and how it works out.
Hi!
There is also a fancy add-on for Jira Cloud, that works really well especially for distributed teams:
https://marketplace.atlassian.com/plugins/agile.estimation.3.0_private
http://www.planitpoker.com may be worth a look. Its also free.
Thanks Graham. That’s a new tool to me and I’ll take a look.
Very nice article! As an Agile consultant I love the clarity with which you write about this process. One caution is that you don’t want to advise people to think of Story Points having any relationship to days (as you’ve mentioned in the conclusion). You just want to do relative sizing of work. If 5 turns out to be 1 day or 3 days, it doesn’t matter. Since your Sprint is a fixed number of days (say 5 days), then you can always *derive* the number of days, but this derivation will change in the future as your team’s performance goes up or down.
You’re article is nearly perfect. I’d like to add another point:
It’s important that the number sequence used for story points is *not linear.* Fibbonacci and Geometric series (and other series) force us to *quickly* estimate because their are gaps between the numbers. This keeps team members from spending time arguing about whether a task is a 2 hour or an hour task. Who cares as it’s going to be lost in the noise of a 5 day sprint with a team of people. And they are estimates after all. The accuracy isn’t good enough to merit that.