Planning Poker Reluctance

Question

I am joining a new team that has been struggling with sizing for years. They have not been making sprints. They have been setting their own Story Points, and historically they have correlated them to time (half a sprint, a week, days, a day, hours). If a dev is assigned a story, she sets her own SP value. QA time is not considered. They are also estimating issues. SP values are then used against capacity of developers to assign out work. About 40% of a given cycle is issues, the other 60% are stories that are in flight over multiple cycles typically.

I would like to use Planning Poker to help them get better at estimates.

However, the team is really reluctant about it. They've had some bad experiences with estimating in the past, and there has been a lot of change to processes in the last year for them. A PM came in earlier this year, but ended up leaving due to personal reasons which caused a lot of chaos since they had introduced new processes but weren't able to stay on to maintain/help transform the team with them. That was the beginning of the year, and I joined a couple months after they left. I've spent the last month learning their current processes.

How do I go about making sure they get a win here? They are tired and don't want more change, especially if it isn't productive. I am considering doing planning poker with them for the upcoming sprint, but also attempting to under-size it. We're coming to holidays, and we're changing process, so I am thinking that the combo of Planning Poker and shooting for a low velocity for the overall sprint might help build momentum around work, but I'm worried that when we size the next sprint higher, it might feel like a bit of bait and switch?

The main thing is to give them a win so that it builds trust and momentum in the process. It can be hard when you first start, especially since we'll be just starting to include QA for the first time. I want to smooth things out and make the path simple, but it's tough because usually if these things take a long time, it's because they need to. I don't want to ask this tired team to just "suck it up," I want to help them.

I'd love your thoughts. Thank you for reading and for any feedback.

Answer 1

People tend to focus on improving estimates, when in fact you should be focusing on delivering value as quickly as possible. If, as you say, 40% of a given cycle is issues and the other 60% are stories that are in flight over multiple cycles, then it seems the team isn't delivering. Getting better at estimates or changing how you estimate by introducing Planning Poker won't change the fact that you are currently not delivering.

If you want to give them a win, then you should stop taking on more work until you finish and deliver what is now in progress. Then find a way to better select work.

You mentioned right from the beginning that the team has been struggling with sizing for years. Don't get better at estimating, get better at splitting work into smaller pieces. Those will then be easier to estimate, be it in hours or story points, by using Planning Poker or some other method.

Also, from what you posted in your question, it seems there is more going on with this team. Don't assume necessarily that it's their estimation at fault. Maybe the stories aren't properly defined to start with, certainly the team isn't sizing them properly, maybe things change once estimated, maybe other processes are at fault, etc. Take a wider view on things and ask yourself "What are some or all of the things that are preventing this team from delivering every sprint?"

Answer 2

Assuming the rest of the process bringing a story to maturity so that it can be estimated is ok, one difficulty I encounter the most with the teams I've worked with is to understand the concept of complexity. I also came to realize that when you don't understand the concept well, using story points (numbers) gives a false impression of accuracy being needed, making it even harder to understand the concept.

What I like to use in that case is t-shirt sizing. Any developer should be able to understand that. You might be wearing a L t-shirt and your friend weighting 5 kg more or less could also wear that size. Also you could be able to fit in a L from some brand (team), and be forced to go XL for another brand (other team), it's all relative.

From there, feel free to convert t-shirt sizes into story points so that you can draw charts:

Smaller than XS -> Child-size, not a story but a task XS -> 1 S -> 2 M -> 3 L -> 5 XL -> 8 bigger than XL -> Story is an epic and/or should be split in several other stories.

Whatever you do, please refrain to convert story points into hours. it is just wrong. Complexity IS NOT time, because complexity is tightly coupled with the story while time is more tightly coupled with the people executing the story.