Re:How we use tennis rankings for fixing bugs
by lucaronin on Wednesday October 07, 2020 @03:19PM
(#24711642)
That's good feedback thank you!
We tried to prioritize the backlog of small tasks against the rest of regular Sprint tasks, but we couldn't make it work very well (tried to write it in the post)
It's not that people skipped bugs entirely, but we found more success by setting up a fixed time every week
At the end the whole process is exactly what you said: a system to make sure the backlog is properly prioritized and managed, with developers assigning bugs to themselves and telling the rest of the company when they will address them
Do your developers maybe have too much autonomy, or lack an appreciation for the way bugs impact users/customers?
I've never worked somewhere that we didn't prioritise the backlog, with input from the Product team. You didn't just get to skip fixing bugs because you didn't think it was fun or interesting. Fixing bugs is part of professional engineering. And, lucky us, they're not actually always boring.
Perhaps I missed something from the rest of the blog post, but it seems like a lot of this system could have been unnecessary if the backlog was properly prioritised and/or management made sure developers were aware that bugs have to be fixed. If you have to assign bug tickets to people because they're not getting voluntarily chosen, then you do that.
Edit: I agree with the point of the section that I took my quote from, which is that you need to have retrospectives/team meetings, work on bottlenecks and processes, etc... But none of those are an excuse for not fixing bugs, they're just hindrances.