Planning poker is an Agile technique invented by James Greening, one of the signatories of the Agile Manifesto. At that time, late 1990’s they were all uncovering better ways of developing software for customer delight. Some of those folks were busy with eXtreme Programming, like James.
One important practice that was being tested at that time as well was User Stories, or the most granular piece of value possible to be represented. Since they were small, they were estimated in hours or days, never exceeding more than 10 days, so small they would be. Since the people doing the work understand it best and can give the best shot on that, they were the ones alone doing the estimation.
It seemed like a good idea.
The problem, or how story points came to be
Those days in the estimation were ideal days. Now, project managers and stakeholders were somewhat losing that piece in translation. So, if I say something takes 10 days and it’s now day 11, they would be mad at me. They ignored that no day is ideal and that we all have interruptions, meetings and that we were estimating the size and amount of work, not giving a deadline.
That’s why story points, which could be ideal days or Fibonacci, or gummy bears or dog breeds came into existence in Agile estimation. To make clear that estimation by the team is about how big, how complex, and how hard it is to do the work. It’s not an answer to forecasting, or “when will that be done?”.
It’s a reference point for the team, so that they can
- Size the work and by that, understand if some user stories are too big and need to be split into smaller stories.
- Agree on the acceptance criteria, or how much work is enough, cutting through the noise.
- Understand how much of all that work they can accept in a release or iteration. There are only so many hours available and they need to then prioritize, based on how much value a story brings and how big it is in comparison to others.
So as you can see, story points and user stories are siblings. Now, how about planning poker?
What is Planning Poker
As it turns out, agreeing on things is not easy all the time even for well-oiled teams. With the best of intentions, we sometimes have people in teams that end up deciding for the whole team. Or people who just shut up to not be “too annoying”. People who sometimes are not super interested in the discussion. Anything you can imagine.
But all perspectives are required for the best estimation and planning possible, since the whole Agile team wins together or loses together. Collaboration was their motto, so, how to make everybody participate? Make it easy, fun, and powerful! While also leaving out of the conversation management interference, I should say.
Planning poker was created then as a gamified way to size, estimate, break-down stories, and plan the work ahead. And:
- In its nature, it requires relative estimation. Relative estimation is estimating current work based on work previously done. Direct comparison.
- It is done by the people doing the work, meaning no one else other than the team can estimate. Although others can give explanations and bring in perspective. Also, no one else from the team can skip estimating.
- It is consensus-based, which means everybody needs to _more than be involved_ agree.
The team looks at a story. They discuss that among themselves. How hard is it to do, to test, to deploy? Who really wants that work done, why, and by when? How much work is enough? And with that, when they then proceed to all at the same time reveal how many points the story is worth. Or gummy bears. Or what dog breed the story is. There’s an element of surprise in there. Like in poker, when you show your cards.
If there are disagreements, and there will be, the team then discusses them to make sure the story is as small as it can be, doable, testable, and relevant. they will agree on one number. Once satisfied, they proceed to the next story.
If you want to understand some more of the mechanics, check out the Youtube Video I’ve done on it.
Now, suppose the team is using Fibonnacci (I have written a thingy about story points here) and now they are all wondering: how can we know the difference between a 1, a 2, and a 5?
You need baselines
When a team is first starting out it is really a matter of guessing. But once the team starts working together, they will have more material to use. They need work accomplished to compare to. That’s the most helpful way to baseline their story points (or gummy bears, or… you got the point).
Here’s what I suggest you look at when you are baselining. Let’s consider Fibonacci for the sake of argument.
1 – Avoid one point story
Fibonacci goes from 1 to infinity. 1 is the simplest piece of work you could ever imagine. I like to leave that number empty. I like to challenge my teams to think that is the Valhalla of any possible work. You want to get there… but you only get there when you die! It’s unattainable.
And that is important because once you place a story as having the smallest value you have no other way to go from there. That is actually how some people started inventing decks of cards for planning poker that contain fractions, like ½. Yuck, that’s starting to get complicated!
Finally, remember how comparisons go:
2 is TWICE as difficult/bigger/complex than 1. Twice as much work is A LOT by any means of comparison. So it’s easier to have numbers that don’t go straight into double of the previous one. As an example, look between a 2 and a 3 (50% more), or a 3 and a 5 (60% more) we are still not talking about twice the amount of work. We only start having such double effort when comparing a 2 with a 5 or a 3 with an 8. In those comparisons, you had to skip at least one number. It just becomes more plausible.
2 – Don’t baseline at every project
By definition, a baseline is a fixed point of reference that is used for comparison purposes. A scale in this case. You don’t want to keep changing your scale, plain and simple. It gets confusing and the historical data, the past, ends up being unhelpful for you as input.
Over time, instead of re-baselining because now the team is more performing and doing stuff faster, I recommend just accepting the fact that most stories will remain on the smaller side of the scale. It also preserves the historical data that makes it easier for the team to understand how they estimate and how much they can commit to.
Now of course, if the team composition changes significantly or if the team moves to an entirely different product, I would 100% recommend a new baseline. In that case, too much has changed to make past effort valuable for the current reality.
3 – More than one value for baselines
What does it mean? It means that you discuss and identify at least two points in your scale. You size work that would be, say in Fibonacci a 2 and a 5. Instead of just one or the other.
Why?
It allows for triangulation of estimation. Once you can know what your 2 and your 5 look like, you can then better infer what choices you would have for a 3 or an 8. Over time it will help you achieve more consistency in your estimation.
Comparing to two things gives you better sizing abilities than comparing just to one.
4 – Don’t go beyond 9 values
Fibonacci sequences go from 1 to infinity. Sizes of clothes have gone waaaay beyond S, M, and L in the past decade. Yet I don’t recommend that you adopt more than 9 numbers into your scale. Research shows that humans are not that great when dealing with more than that in comparisons. I would even go and say, stick to 6, maybe 8 numbers on your scale. Because
- You want to achieve consistent small sizing of stories, so it’s beneficial to not go too big anyway.
- You don’t want to have to discuss all those 10 numbers if each team member picked a different number. If that happens it’s hard to understand and means the scope, in general, can be too broad.
- You remember best family-sized stuff. It’s true for team composition and it’s true for estimation scales.
So I usually stick to:
- XS, S, M, L, XL or
- 1, 2, 3, 5, 8, 13.
As you can see, the Scrum Master or Agile Coach should understand and teach these elements to make planning poker something that the teams can really benefit from if they chose to use it.
Now is that all?
What the team coach should pay attention to
Beyond mechanics and intent and insights, there are the human elements at play. Always. So what are those other things you should be paying attention to?
- Consensus decision-making instead of just averaging the points or saying “I’ll go with your 3”. The point is not to accept the number that appears the most in the team or to just accept what the senior architect just chose as his number. Averaging points, majority vote, they all defeat the purpose. It’s not about the number itself! It’s because we are in misalignment, and we need to explain our points of view and then select a number. Together. In agreement. It’s like language: when we say a word means something. Those numbers over time need to become a no-brainer _as far as work and scope context_ for the team to pick from when confronted with new work. If they are creating a new language together they need to all agree on the meaning of words, including nuances.
- A dominating person bulldozing or influencing others can also be a challenge. That’s why we need a coach on the scene, at least as the team gets used to the practice. All sorts of dominating dynamics that used to exist in the team and might have been normalized are detrimental to the practice. The point is to uncover all possible hidden scope, missteps and figure out what is essential in the user story or work item. If only one person speaks or if we always go with that person’s idea even if everyone speaks, the coach should look for opportunities to amplify the lower voices or shift the team dynamics. In the end it’s not just about the poker planning.
- Seek to understand why the shy voices keep shy or disinterested. You can facilitate in a way that everybody gets airtime and yet… there is that person who never says much or anything at all. Is it a lack of trust, of understanding, or maybe they even don’t care about the team anymore? It’s once again, beyond the scope of poker planning, and therefore, of major importance to understand why the minimum participation. I’ve been there and had a team member that was just waiting on the response from a future employer. They felt emotionally done with that team and would not feel like contributing anymore. We had to have a conversation on how they could still be present and how to best honor their work in the time they had left.
- And ultimately, like any practice, Agile or not, notice when the practice is wearing off. We adopt techniques and tools to fulfill a need, to learn something, or both. Once the need is no longer there it’s time to move on. Any Agile team can benefit from Planning Poker. And all Agile teams will outgrow Planning Poker at some point. But don’t just let the team skip the practice because of disorganization, lack of time, or confuse it with laziness. When it feels the practice is obsolete, create the space where a real conversation can be had on the subject: why to stop and what to do next. Remember, work still needs to be understood, discussed, and commitments still need to be made. What is the next step in the team’s journey to still honor those needs?
Final words
Planning poker is a combination of estimation, planning, and work item refinement that was invented to address the needs of Agile planning.
While highly effective for teams, it became misunderstood and misused. It’s even worse for the connected techniques of user stories and story points. So much so that even the creator of the story points technique, Ron Jeffries, has a few bitter words to say on the subject. Check that out here.
If you are to use Planning Poker with your teams, be knowledgeable of the techniques, but also be intelligent of the human gamification aspects this can bring. And don’t let it overstay its welcome! Or those are my thoughts.
How about you? Do you use or are considering using Planning Poker with your teams?
