Storypoint Disaster?

[Evan Fishman - Quely for Jira]

Story points didn’t fail this team.
They were being used for something they were never designed to do.

They were never meant to be time.
They were never meant to be precise.

Story points exist to compare effort, uncertainty, and complexity relative to other work. That’s it.

And honestly, I get why that’s confusing.

Most teams come from a world where planning means hours, deadlines, and fixed commitments. Then Agile shows up and says, “Estimate this thing, but don’t think in time.” That feels abstract at best and dishonest at worst.

So teams do what makes sense to them.

They quietly convert points back into hours.
They argue over whether something is a 3 or a 5 as if the number itself carries truth.
They treat velocity like a promise instead of a signal.

That’s a misunderstanding of the tool.

The real value of story points isn’t the number you land on. It’s the conversation you have while trying to land on it.

Why does one person think this is simple while another thinks it’s risky?

What assumptions are we making about scope, dependencies, or unknowns?

What work are we hand-waving past because “we’ll figure it out later”?

Those discussions surface hidden complexity long before it becomes rework.

When teams skip or rush that conversation, story points feel pointless. When teams treat points as a proxy for time, they turn into a control mechanism.
When management asks for velocity after sprint one, estimation turns into theater.

That’s how story points get a bad reputation.

Used well, they’re a forcing function for shared understanding. Used poorly, they’re just fake math with extra steps.

If the conversation isn’t happening, the numbers don’t matter.

[Debbie Lindsey]

An estimate will always remain an estimate no matter what you do to it.  The number is relative only to the team and that specific project based on risk, complexity, and effort and related assumptions and dependencies.  If it does not work the first time, use the retrospective to educate the team about the estimation purposes and develop working agreements towards it.  

[Michael Karl]

Hi Evan, thanks for your contribution. Could you somehow upload a higher resolution version of your screenshot "Storypoint disaster - agile newbees at work again"? It's really hard to read for me. Since you're referring it I'd really like to read it. Actually your text really captured my attention and appears to be worth reading.

Best regards,

Michael

[Evan Fishman - Quely for Jira]

Sure @Michael Karl here you go. 

[Michael Karl]

Thanks a lot for sharing this. I have to re-read your thoughts about it again. Maybe I can learn something, but besides from learning I have to admit that it is somehow refreshing and kind of a relief to see that other teams have their struggles, too. No reason for Schadenfreude, though.