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.

  • 4
    The whole point of story points is to have an abstract that is not bound to a specific person. A 3 points story could take 2 days for Paul but 5 days for Mike, who is a junior. Estimating in days is meaningless, since Paul and Mike could never agree on an amount anyway. So what is their goal in using the current story points system being bound to a specific person, what do they gain from it over estimating hours anyway?
    – nvoigt
    Commented Nov 19, 2020 at 15:11
  • How well are the stories refined before you ask for estimation? The main issue might not be poker planning, but simply that you're asking devs to estimate un-ready stories...
    – Laurent S.
    Commented Nov 19, 2020 at 17:30
  • 1
    So does current way cause problems? Why did you decide to introduce planning poker? Commented Nov 19, 2020 at 18:49

2 Answers 2


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?"

  • I think this is really helpful, especially your second bolded section. You're completely right, we need to finish what we're chewing on now in order to better select work going forward. Thinking about it more holistically as you mention in your last paragraph is also very good advice I will definitely follow and think about! Commented Nov 20, 2020 at 18:49

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.

  • Yes, I want badly to break them of relating complexity and time. They loop back to it but I believe strongly that this insistence of thinking of it in time is a big part of why they are behind. I think T-Shirt sizing could work very well for them. Commented Nov 19, 2020 at 19:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.