And boy, do people hate planning poker.

It comes up all the time with friends and coworkers. When talking about life as a dev, work processes, management, or the industry as a whole, eventually someone mentions work-costing, and people hate points being assigned to work they have to do.

Planning poker is one common name for the act of a group choosing those point values for future work, to determine the time and the effort the group believes will be required to perform the work.

And people have legit issues with it: the method their team follows, its accuracy in finding costs, how frequently it’s done, the way the points get used, and the reasons they have to do it. But most concerns are targeted at the ineffectiveness of costing, which misses the true, hidden point of the task — and you can’t blame them for missing it! They see the finger, not the moon.

Buddha’s no moon

The finger and the moon are an old zen metaphor: those who seek the moon and find people pointing fingers to the sky shouldn’t mistake the fingers for the thing they seek. They shouldn’t mistake a temple, or an idol, for the end result of the teaching. The finger is just a thing that helps them get to the thing.

Planning poker is often discussed as a way to determine the cost of work, and that’s how it’s sold. Many companies only bother to do it because certain strata of management want to know what things cost and when they’ll be finished. Planning poker puts numbers to work, so why not use it? Some people want to use the costs it produces to forecast future project timelines, while others want to measure their teams’ (or, frightfully, individuals’) relative productivity by their completion of certain numbers of points in given time periods. But planning poker isn’t really good for or about any of that — it’s just a finger, pointing at the moon.

The moon here is all the parts of your work that you don’t even know exist until you’re working through the middle of them. It’s all the hidden costs that an optimistic Product Owner would never consider. You can’t have one person sit on their own in a room and just see all these things, so what can you do?

You can build a temple with a finger in it pointing at the moon, i.e. a process that naturally leads to the discovery of these unknowns. That’s planning poker.

Planning Poker is not itself a Heavenly Body

Planning poker has many variations, but it’s typically done by having cards in roughly fibonacci number increments from about 1 to 33, which every member of a small development team has a copy of while attending the session. A story or task to be costed is selected — it may have a prior general assessment as “large”, “medium”, etc. from an initial triage lookover, and after some discussion of the task, everyone privately chooses a card with a cost from their own set. They all reveal simultaneously to avoid a big group-think in first selection.

On any appreciably complex story, at this stage you will find a cost disparity between team members. Someone who is junior might think something they don’t understand is more or less expensive than makes sense to the rest of the team. Someone who is feeling pessimistic that day might put in a high cost, or vice versa with an optimist, or just someone who knows more or less about the problem space. Now that the cards are down, the discussion begins — the finger has pointed.

“Junior Dev Danny, why do you think this story will take 3 points?”, quoth the scrum master.

Danny now has to fumble around and rationalise their cost. They might have good reasons, and they might not. Everyone sitting in the room listens, and other members of the team can agree or disagree and give their own reasons. You do this a few times with the outlier costs, write down the most legitimate concerns and new stuff that fell out in the process, and what you’ll find is this:

1. Your cost will average toward a meaningless number.
2. You ended up with a far better description of the task.
3. Everyone on the team better understands the work to be done.

If you asked everyone to just improve the description, or just read through all of the tasks? Especially without the meeting? You would end up with shit. No one cares enough to read closely over all of the tasks. People hate that stuff and it would be culled from your process simply by never happening.

But if you get everyone in a room and ask them to assign point values for the sake of finding out the cost to the business? Well, you still end up with shit on that front. No one cares enough to do a great job by themselves, if it’s even possible, and people hate this stuff and want to remove it from the process because they feel it’s a waste of time, even as they make use of the way better descriptions and feel good knowing what the whole team is working on. As a byproduct of the process and its shit, we all get to see the moon.

Caveats

There are some caveats here. Being evaluated in any way by the points output gives a lot of awful incentives to game them, even subconsciously, which leads away from good discussion. Also, doing punishing amounts of discussion over small bits of work builds enough process-hate to get people to check out and stop even listening, which also leads away from good discussion. And trying to evaluate work that is too remote (e.g. if you’re on a team that is too large, or is handling many totally unrelated projects, or is trying to work 6 months into the future rather than on stories for the next few weeks/month) will let people zone right out during the process.

For these discussions to happen you need a right-sized, reasonably focused team that’s only having the meetings they need to have, and they have to be able to talk without fear of being penalised for wrongness. This is sadly a tall order for some places!

So whatever you do with the numbers that come out of planning poker, please don’t measure your team by them in any sort of performance-review capacity, and though they’re better than nothing at all, please don’t trust the numbers to tell you the exact launch date.

But keep doing the estimation!

Keep watching the skies

It gives a key time to teach junior developers about your systems. It gives product, design, and QA people more confidence and context in the work being done. It gets everyone on the team invested in every task. And it uncovers a huge amount of work that you otherwise wouldn’t see until you were standing in the middle of it! This lets you adjust course before you have momentum built, while you’re less invested in work you’ve already done, which may even have been the wrong work to do in the first place if you’d only sat down and talked it through as a team.

These things are absolutely key to producing good software in a reasonable period of time and making life less miserable for everyone. It has saved teams I’ve been on so much hassle, so many times. We found the moon.

Planning poker absolutely helps us all to find it, even though it mostly sucks at accurate cost estimation, and people can grossly misuse the numbers it produces.