zlacker

[return to "How I estimate work"]
1. crazyg+Ae1[view] [source] 2026-01-24 20:05:28
>>mattjh+(OP)
Not a single mention of planning poker and story points?

They're not perfect (nothing is), but they're actually pretty good. Every task has to be completable within a sprint. If it's not, you break it down until you have a part that you expect is. Everyone has to unanimously agree on how many points a particular story (task) is worth. The process of coming to unanimous agreement is the difficult part, and where the real value lies. Someone says "3 points", and someone points out they haven't thought about how it will require X, Y, and Z. Someone else says "40 points" and they're asked to explain and it turns out they misunderstood the feature entirely. After somewhere from 2 to 20 minutes, everyone has tried to think about all the gotchas and all the ways it might be done more easily, and you come up with an estimate. History tells you how many points you usually deliver per sprint, and after a few months the team usually gets pretty accurate to within +/- 10% or so, since underestimation on one story gets balanced by overestimation on another.

It's not magic. It prevents you from estimating things longer than a sprint, because it assumes that's impossible. But it does ensure that you're constantly delivering value at a steady pace, and that you revisit the cost/benefit tradeoff of each new piece of work at every sprint, so you're not blindsided by everything being 10x or 20x slower than expected after 3 or 6 months.

◧◩
2. n4r9+hv1[view] [source] 2026-01-24 22:00:33
>>crazyg+Ae1
What is the benefit of estimating points rather than days? Feels like you're still ultimately estimating days in the end.
◧◩◪
3. crazyg+vx1[view] [source] 2026-01-24 22:20:26
>>n4r9+hv1
Because, for whatever psychological reason, estimating in time leads to a false sense of accuracy, people pointlessly argue over whether something will take 5 days vs. 6, and people tend not to be overly optimistic and forget to account for things like sickness, meetings, etc.

Estimating in points that are basically a Fibonacci sequence keep estimation precision limited and avoids implying false guarantees. Yes, in the end the chosen stories are based on summing to a number of points that is roughly equivalent to what the team has achieved per-sprint in the recent past, so in that sense it is ultimately estimating days in the end. But again, for whatever psychological reason, people seem to be more realistic about the variance in actual delivered points per sprint, as opposed to when you try to measure things in hours or days. The points imply more of an estimated goal than a deadline guarantee, which helps keep both team expectations and management expectations more reasonable.

tl;dr: Psychology.

◧◩◪◨
4. n4r9+rw2[view] [source] 2026-01-25 08:54:10
>>crazyg+vx1
Can't you do that by just limiting the precision? You can only vote 1, 2, 3, 5 or 8 days. Not sure what "points" are adding. As far as I can tell, it's an attempt to account for estimation difficulties by introducing a "velocity" concept. But I think it makes things more complex without actually solving the issue.
◧◩◪◨⬒
5. crazyg+Ff3[view] [source] 2026-01-25 15:29:16
>>n4r9+rw2
Let me repeat myself:

> and people tend not to be overly optimistic and forget to account for things like sickness, meetings, etc.

> But again, for whatever psychological reason, people seem to be more realistic about the variance in actual delivered points per sprint, as opposed to when you try to measure things in hours or days. The points imply more of an estimated goal than a deadline guarantee, which helps keep both team expectations and management expectations more reasonable.

[go to top]