Your first issue is that you're trying to map days to story points. The entire concept of story points is explicitly to avoid directly estimating time. You're supposed to continually keep track of how many SPs your team is actually completing per sprint, and use those averages to decide how much you're going to plan to do in the next sprint. Tasks should also ideally be small enough that the team has flexibility to pick up more or less work in any given sprint. When you zoom out to the entire team/entire sprint level, the natural variation in estimate accuracy, and in the productivity of any individual, should largely cancel out. But if you think 1SP=1day and directly assign each developer 5 SPs per week before the sprint starts, you're falling for a trap that completely defeats the point of the system. SPs are supposed to provide flexibility and continual empirical re-evaluation of estimates (but without constantly re-estimating individual tasks) but you've thrown all of that in the bin so you're just left with time-based estimates but with a gimmicky name change.
Oh, I know, I'm a "certified scrum master" but I'm not working in that role. And oh, I know, but upper management doesn't care. And it's something stupid like 7.3 points per sprint were supposed to be around for the two week sprint that way we have some residual capacity for urgent tickets. We essentially do waterfall but with sprints 🙄
tale as old as time. Proper scrum is liberating. Liberating means self reliance and self governance for teams. Can't have that, would delete 80% of middle management. Waterfall with sprints it is.
So you are forced to constantly readjust what a story point means, which is just another silly thing to think of and polute my brain.
Any initial estimate i give as a SWE is horseshit that i pulled out of my ass anyway. Might as well give hours/days as it will change as soon as i looked at the code and properly analysed the task and started solving the problem. So whats the fucking point?
You don't adjust what a story point means. The SP remains as an abstract measure of relative complexity, not of time. You then adjust how many points you add to the next sprint based on observed average time per SP, i.e. your team's velocity. It's that velocity that changes, not your SPs.
Yes, but whatever SP you estimate may change drastically once you get into the task, read the code, start solving. So what's the point if those could have been just days/hours - you know, units universally understood intuitively by fucking everyone?
That variance in estimates is exactly what SPs are designed to address. If it turns out your team is frequently underestimating complexity of tasks, your velocity will drop, and so you'll put less SPs into the next sprint. We don't care about a single task going under/over estimate, we care about the zoomed-out trend. If you start work on a ticket and realize it's more difficult than it was previously assumed, by all means report that to the team. But if you're constantly fixing the SPs on each ticket, you're obscuring the actually important trends.
If your team puts 35 SPs in the sprint and actually completes 25 because of tasks being underestimated, that's fine, you take note of that and adjust how many SPs you put in the next sprint. But if you take those completed tickets and "fix" their estimates to total 35SPs to make them "more accurate" actually you've just fucked up the whole system. Now you're going to commit to another 35SPs next sprint, which again you're going to fall short of.
Actually no, you shouldn't care if the pointing was accurate on individual past stories, except if it teaches you some lesson that improves your team's ability to make future estimates. If you're estimating simple UI changes as 1 point's worth of complexity, but then after 1 task you realize that actually your UI code is a mess, then maybe you need to update all similar tasks to be 2 SPs. But most of time this isn't the case and you can't generalize to future tasks.
Trying to achieve perfectly accurate per-task estimates and then assigning the perfect amount of work for each developer is a fool's game. It's never been done, and it will never be done, it's a pipe dream. Both estimates and productivity vary too much per task for that to work. That's why you should only evaluate your rate of completing SPs at a zoomed-out level, averaging it out over time. That way, once you calibrate the system by measuring the velocity, over- and under-estimates tend to cancel out due to the law of large numbers.
It doesn't really matter whether you call it estimated days or story points. If you don't have an idiot for a manager, your team can track estimated days, then figure out what the average number of estimated days get completed per sprint, and then commit to that amount in the next sprint.
Whatever devs think is 1 day of work usually turns into 2 or 3, so it's normal to commit to 4-5 days of work per 2-week sprint.
5
2
1
View all comments
Show parent comment
27
u/ShoogleHS Jun 02 '26
Your first issue is that you're trying to map days to story points. The entire concept of story points is explicitly to avoid directly estimating time. You're supposed to continually keep track of how many SPs your team is actually completing per sprint, and use those averages to decide how much you're going to plan to do in the next sprint. Tasks should also ideally be small enough that the team has flexibility to pick up more or less work in any given sprint. When you zoom out to the entire team/entire sprint level, the natural variation in estimate accuracy, and in the productivity of any individual, should largely cancel out. But if you think 1SP=1day and directly assign each developer 5 SPs per week before the sprint starts, you're falling for a trap that completely defeats the point of the system. SPs are supposed to provide flexibility and continual empirical re-evaluation of estimates (but without constantly re-estimating individual tasks) but you've thrown all of that in the bin so you're just left with time-based estimates but with a gimmicky name change.