Sorry if it comes through as rude, but this is how I keep repeatedly being told story points work.
If you look at all those properties together, story points are completely useless.
The only moment time it makes sense is when you have a SHARED understanding of the smallest point AND you can translate it to time. When you do that, story points are useful. Also, they become time, so there is no reason to use points.
I’d like to disagree on that one. A single story point shouldn’t be translated to time, but should reflect the relative complexity between tasks (ie. a 7 is harder than a 3 and so on).
You could assign relative complexity based on a number of things:
- number of integrations to other systems, - is the area well known to the team, - is the code well tested, - is CI/CD set up, - do we need a lot of alignment or can we just get started, - etc.
So you’re not estimating time, but complexity or hardness.
Then, supposing you have a stable team, you can go back six months and find out “we do on average 90 points per month” or similar
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.
- Time
- Risk of being wrong
"This will take between 1 and 3 days" gives you both: the risk (complexity, hardness) which is represented by the gap, and time: how long it takes.
When a non engineer asks for an estimate, they usually mean one of these two things:
1. How long it takes?
2. Have you had experience with something similar before?
For the first one, you CANNOT use what you just described, since it doesn't represent time, so you cannot give dates in any form.
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.
That's the purpose of story points and planning poker. They don't represent time guarantees or delivery dates. That's not a bug, it's a feature.
They represent estimated effort, with a recognition that uncertainty is generally roughly proportional to size. Which is why point estimates are usually restricted to approximately Fibonnaci sequences values (or sometimes doubling). Often it will be limited to 1, 2, 3, 5, 8, 13, 20, where stories aren't allowed to be larger than 20 -- if they are, you need to break them apart.
So to be clear, when you say that estimates are composed of two parts -- time and risk -- planning poker intentionally conflates them into a single number. If a task is both large and truly high-risk, then it should be broken into a research story and an implementation story, where the size of the research story can be better estimated, and then implementation waits for the next sprint depending on what research tells us. If it's small and high-risk, then you basically just "try", and accept that it might not get delivered, and then revisit in the next sprint whether it's worth trying again and if it needs to be revised.
Exactly - that’s the point.
Story points assigned to a SINGLE task is not for estimating time spent on that task.
Story points can - given prior data - give you an estimate of time spent on a GROUP of future tasks
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