zlacker

[parent] [thread] 2 comments
1. Fire-D+(OP)[view] [source] 2026-01-24 22:17:04
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.

replies(2): >>crazyg+u3 >>bogeho+p8
2. crazyg+u3[view] [source] 2026-01-24 22:45:41
>>Fire-D+(OP)
> 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.

3. bogeho+p8[view] [source] 2026-01-24 23:25:35
>>Fire-D+(OP)
> 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

[go to top]