The entire concept of a sprint to me always felt wrong. Development work can't be split up into time slices. And trying to divvy up tasks based on an estimate of how long it'll take to complete each one is just a waste of time. I remember being in a standup, being told to bump a high-priority task into the next sprint and complete a couple low-priority tasks instead because I already had too many points assigned to m…
> We estimated the amount of time each task would take, assigned it points based on that, and we'd fill our task list in such a way to try to make the estimation close 40 hours of work. The concept of story points was invented as an attempt to solve the problem of developers reliably estimating the amount of time a given task will take. If you're directly equating story points to time then you're doing it wrong.
But it's not us, the developers, doing this conflation. It's management. No matter how many times we say "story points are useless without a consistent measurement of velocity", they still say "okay, but 2 + 5 + 3 + 2 = 12 dev days, so you and Jane can have ${FEATURE} done on Tuesday, right?"