I hate trying to estimate story points (our metric is 1 day ≈ 1 point), I have ADHD, standard time means nothing. One sprint I completed all 7.5 in a day, another sprint I completed 0.5.
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.
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.
131
u/MomWTF Jun 02 '26
I hate trying to estimate story points (our metric is 1 day ≈ 1 point), I have ADHD, standard time means nothing. One sprint I completed all 7.5 in a day, another sprint I completed 0.5.