[bogeholm]

> 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.

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

[Fire-Dragon-DoL]

An estimate is composed of two parts:

    - Time
    - Risk of being wrong

When you do what you just said "I am not estimating time, I'm estimating risk".

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

The second one can come also through the question "how challenging do you think that is?" To which we answer "easy but long" "hard" (never done it) or things like that. That's easier to answer, but doesn't translate to dates.

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.

[crazygringo]

> 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.

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.

[bogeholm]

> 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.

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