zlacker

[parent] [thread] 3 comments
1. crazyg+(OP)[view] [source] 2026-01-24 22:14:01
> Because story points MUST be specific per person based on the smallest task they ever faced, they cannot be summed up because they are not units, and points do not translate to time, we cannot talk about story points.

Literally none of that is anything I've ever encountered on any team.

They're not specific to a person, they're to a team.

They have nothing to do with the smallest task ever faced.

They are obviously for summing and are obviously units.

They effectively get translated into time in the sense that the team has a history of delivering an average of n points per e.g. 2 weeks.

replies(1): >>Fire-D+B
2. Fire-D+B[view] [source] 2026-01-24 22:18:47
>>crazyg+(OP)
Every person I met gave me a different statement, so I don't fail to believe you, it's just that the definition of story points is different for everybody
replies(1): >>crazyg+p3
◧◩
3. crazyg+p3[view] [source] [discussion] 2026-01-24 22:42:18
>>Fire-D+B
I'm sure everyone has their own idiosyncratic interpretations, but I believe I've got enough experience to tell you that what I'm explaining is pretty standard.

Here are literally the top two Google results for "story points" and they both seem to align entirely with what I said:

https://www.atlassian.com/agile/project-management/estimatio...

https://www.mountaingoatsoftware.com/blog/what-are-story-poi...

I don't doubt that what you're describing as story points is something somebody told you. I'm just telling you that their definition was highly idiosyncratic and extremely non-standard. When discussing these things, using the standard definitions is helpful.

replies(1): >>Fire-D+Lr
◧◩◪
4. Fire-D+Lr[view] [source] [discussion] 2026-01-25 02:13:34
>>crazyg+p3
The definition of story points like the one I have mentioned has been provided by a certified scrum master and in a different context,by a certified scrum coach.

I appreciate your effort, but I don't believe there is any formal definition. It's redefined per team, it's redefined by the team too if needed.

So people want an estimate (uncertain) based on a number that's also nebulous. It kills me.

Use time ranges, you get a sense for risk AND have an estimated delivery date.

The adjustment people make with numbers can still be made on a per team basis using time ranges, I don't see why we have to use a proxy

[go to top]