Planning Poker: Knowing When to Fold

I’ve been working in agile for almost twenty years now in one way or another (developer, manager, or coach) and there’s one practice that I find most challenging for new teams – planning poker. It’s not so much the whole “pointing thing” but it’s asking a team to figure out – is this story one point? Five points? Twenty points? But I’ve posted elsewhere that there are different ways to do this and today I’d like to talk about knowing when to fold on planning poker.

What Is Planning Poker?

Planning Poker is a technique used by teams to estimate stories. The flow of the practice is something like this:

• The team discusses a story, including acceptance criteria, the business need, and technical constraints
• Each player chooses a card – hidden from the other team members – that has their choice for the number of points to assign to the story (usually modified Fibonacci – 1, 2, 3, 5, 8, 13, 20, 40, 100, infinity)
• Everyone shows their card at the same time
• The people who show the lowest and highest point values discuss their reasoning for their proposal (why did you pick three? twenty?)
• The team talks about the concerns raised and repeats the process until there’s agreement if not consensus

This is great, but it does pre-suppose that the team has a consistent interpretation of what a two or a five or a thirteen is.

What’s Wrong With Planning Poker?

The main issue I see with Planning Poker is that most explanations, including the one presented in the SAFe material, recommends that teams should find a story that takes a half-day to develop and a half-day to test and then use that as a one. The problem is that we’re almost immediately starting off saying that one point equals one day, and we all know (or should know) that there’s no real correlation between points and days. Instead, this technique tends to push people to think in those terms. They think that five points means a week of work. But that’s not it.

Instead, points represent the Complexity, the Uncertainty, the Risk, the Scope, and the Effort required to deliver a story. Something very risky might have very low effort but still have a high point value. Something very straight-forward but very time-consuming may still have a low point value. In other words – points don’t equate to time.

What To Do Instead?

One of the things I like to do – especially with new teams – is to ignore planning poker entirely. Get the team thinking about relative sizing, which is what story pointing should be about. A two isn’t twice the size of a one – it’s just bigger than a one and smaller than a three. There are some methodologies – including SAFe – that try to push that because they were trying to find a way to bridge agile and traditional organizations. But we need to ignore that and focus on what makes sense for the team.

What I do with new teams is just create a relative estimation board. I pick the top story of the product backlog and put it on the wall. Then I pick up the next story and ask the team “Is this smaller, the same size, or bigger than the story on the wall?” Then I place it accordingly and repeat that process until we’ve processed the top stories in the backlog. We still have the conversations about scope, about risk, about the acceptance criteria and business need. All the things that help the team figure out how this story fits in with the stories already on the board. But at no point do I show them any points. Some software packages, like CA Agile Central (formerly Rally), offer this as a tool for teams.

 

After we complete that exercise, I sit with the Scrum Master and we assign points based on the relative sizes. Starting with the far left, we assign a one (or possibly one-half) and then count up. When we get into the eight to thirteen range we know we’re going to have to ask the team about whether those stories can be completed in a sprint or if we need to break them down. Sometimes a team has a very fine-grained set of stories and they can complete twenty-point stories in a sprint easily. Sometimes a team struggles to complete five-point stories. It’s the conversations that matter and that’s what this helps facilitate.

 

Closing Thoughts

Planning Poker can be a really good tool for teams that are very comfortable with the points they use for stories, but most new teams are struggling enough with the concepts of agile and Scrum that tossing in points is just asking too much. Rather than trying to get a team to meet some arbitrary bar about “doing agile” or “being agile”, let’s help our teams be successful first. And sometimes that means knowing when to fold on planning poker.

Happy coaching, my friends!

Subscribe here to get notified when new posts are added!

[email-subscribers namefield=”YES” desc=”” group=”Public”]