Why are you estimating things in hours? Why is management tracking the amount of story points every developer completes in a sprint? Why are you not working on the highest prio stuff in the sprint?
Of course sprints look useless if you're doing them like that. Do you even have a clear sprint goal you're working towards?
People always say not to estimate in hours and instead to estimate in "points", but at the same time teams tend to plan around how many points they're taking into a sprint. If you have 40 points but usually take only 30, you'll be asked to bump something out.
And once you agree on a number of points to do in 2 weeks, it's not rocket science to figure out an estimated number of hours per point.
The point (heh) is not that there is no mapping between story points and time, the point is that it helps us acknowledge that these are estimates, not promises that signify failure if broken. No individual estimate is expected to be exact, but we hope that deviations from the estimate average out across the stories in a sprint.
And most importantly, story points make it easy to base our sprint commitment on the available evidence from previous sprints. We say that we can do 40 story points in a sprint, because we know that is roughly what we managed to do in the last few sprints. The conversion factor can change over time as the team gains experience, or the team changes, or the nature of the work changes. It's much harder to do such adjustments when you directly estimate hours.
Because anything else is completely arbitrary. I mean, we ARE measuring things in "points", but with the understanding that 1 point ~ 1 hour of work.
> Why is management tracking the amount of story points every developer completes in a sprint?
Because they want metrics on productivity. I don't entirely blame them.
> Why are you not working on the highest prio stuff in the sprint?
As mentioned, because management really wanted to see us complete 40 hours of work every week, and getting close to 40 hours done per week was more important than priorities. If something couldn't be finished before the end of the sprint, they thought it was better to push it to the next sprint, rather than leave something incomplete at the end of a sprint.
> Of course sprints look useless if you're doing them like that. Do you even have a clear sprint goal you're working towards?
I was on a QA team writing test code. I specifically was writing security tests, while others wrote functionality or stability tests. Each sprint goal was effectively just "Write these tests".
Of course sprints look useless if you're doing them like that. Do you even have a clear sprint goal you're working towards?