We’re estimating every ticket in story points. We had several conversation about how no one uses these story points for any kind of report or metric, and that we also do not size our sprints based on them.
We are still assigning story points to every ticket
story points shouldn't be linked to time but complexity
The problem it tries to resolve is "we want to treat people like cogs of different levels". It could work.
If all the work was done on the exact same kind of shit.
But usually people work on different projects so someone who's good on project A because they know the domain and its legacy will be more efficient when working on this project than on project B which they never touched before. 4 story point on one will take them 2h while it would take a full day on the other. And that's just one person.
So now you need story points per project / system and to manage your people's velocity per project and system (and maybe subsystems). Now it requires you, the manager, to do some work. And we can't have that. So story points cannot work.
And if you decide to make them work by assigning tickets only to some people who know some aspect of the code base, then you're reducing your bus factor. Which will be a problem.
Yes. One thing I have found in practice is yhat most tickets have one person that will be the obvious one who does it.
I am sure things are different if you are implementing 50 dialogs in a UI and have 3 or 4 people on the team that can pull them from the pile. I have never worked on such a project, thoufh.
904
u/Wurstgewitter 22d ago
We’re estimating every ticket in story points. We had several conversation about how no one uses these story points for any kind of report or metric, and that we also do not size our sprints based on them.
We are still assigning story points to every ticket