We’d like to get you near the subject of Planning Poker as an efficient way of estimation, explaining the rules, purpose, pros and cons of using it in your projects.
Who never faced the estimation issues within their team, cast the first stone. Estimation is one of the biggest challenges in software development. Provide it with the best accuracy that’s the one way to be looked at it. Another side of the coin is to do that effectively and not let the team get bored and stressed. Assuming that you’re developing software in agile methodology, let me introduce you to the Planning Poker method, together with its advantages and disadvantages.
Planning poker - is it worth it?
To answer that question, it would be good to reveal the cards and provide the definition of Planning Poker. In other words - Scrum poker or Pointing Poker - “is a consensus-based estimating technique. Agile teams around the world use Planning Poker to estimate their product backlogs. Planning Poker can be used with story points, ideal days, or any other estimating unit.” (1) Sounds complicated? Nothing could be further from the truth! Let me introduce you to the arcana of this game, step by step.
Who came up with planning poker?
A long, long time ago… just joking. In 2002 James Grenning was facilitating a meeting where two senior developers were stuck in the middle of a discussion that was getting boring enough to push him into that brilliant idea. (2) Later, it was distributed by Mike Cohn in the book “Agile Estimating and Planning”. His company trademarked the term and a digital online tool.
What are the rules?
Before we start the game it would be good to know the rules. Do not sit down for a long time, because the instructions are simple.
Every person who participates in estimation has the same deck of cards. Usually their values are based on the Fibonacci sequence ( 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100). As an extra, there might be a card with a “?” symbol that says that there’s no idea how much time should be spent (it’s a starting point for the discussion). I’ve also seen the deck with the value 0,5 which stands for super small tasks. You may also see a coffee card or a drink card that’s translated into “I’m hungry, I need a break” or the Infinity symbol standing for enormous tasks, that most probably should be broken down into smaller pieces. Values might represent story points, man-days or any other unit agreed by the team, but it has to be set up at the same beginning.
Facilitator presents the Story/task/feature and then estimators can start the discussion, asking a product owner about the details.
When it’s clear, everyone votes with one of his cards. Cards are being revealed simultaneously.
When all the values are the same - then the Story gains its estimation. If not - extreme values are being discussed.
Re-voting, until consensus is reached.
What’s important is the presence of the Product Owner who answers the question of the estimators, providing as many details as possible.
You may also ask - how long is the game? There’s no strict rule. The game should be timeboxed as other Scrum meetings, usually, it’s being played during refinement meetings. It could be a part of a Sprint ceremony.
What do I need to start?
First of all - product backlog, at least the initial one to start with. Secondly - the team of players = estimators and of course (like in a good casino) a dealer who will deal ‘the cards’, so particularly a facilitator (most probably it would be your Scrum master). Product’s Owner presence would be also valuable. Last, but not least - your deck. It could be a separate online tool, Jira’s app or real paper cards if you have your team in front of you.
Is it worth it?
Yes, yes and… yes. There are many pros of using Planning Poker for your estimations, starting with that this game provokes discussion. Experts seated at one table are the best ones to estimate them as they will be the ones, solving them. There’s a space for opinions, knowledge and insights exchange. The live discussion leads to more accurate estimations. (3)
In addition to estimates, if they find discrepancies during playing the cards, it may turn out that Story/task was missing some important details that Product Owner wasn’t able to think of.
Moreover, using Planning Poker you can get rid of suggestibility. Once someone speaks up, others might rely on his judgment in the sizing. Planning Poker forces individual thinking and active involvement. Everyone has a turn to provide input.
In the end - it’s simple, intuitive, fun and gives space for working together, acting as a team, and encouraging collaboration.
To be objective, I can’t skip the drawbacks. Planning Poker won’t work in complex environments or with a scope that’s not granular enough. Then, the estimator might not be aware of the dependencies, blockers and give the assessments without real coverage.
Furthermore, if the team won’t get the rules, then the method can be much more time-consuming than the others. Fortunately, they are not difficult. Same, if they can’t reach a consensus, re-voting may take ages. Then, it’s the facilitator who should help a little bit.