User Pain is an established concept to prioritize bugs in a consistent way that is stable over time by calculating a single score based on a small number of criteria.
While these criteria can wary across organizations, they usually share a number of qualities:
- Good coverage: These cover the range of concerns expressed by most stakeholders. Type includes business priorities while Likelihood and Priority help classify user impact.
- No overlap (aka orthogonal): A bug can be rated on one factor without affecting how you would rate the other factors. This allows you to rate each factor in isolation and greatly improves the objectivity of the results.
- Small number: There are few enough of them that they don’t overload the bug submitter. It is easy to add more factors for various edge cases, but typically this results in a cluttered and confusing bug submission form.
I would like to adopt that concept for prioritizing technical debt and maintenance in a large, old, but actively developed code-base. Meaning maintenance work that is not directly user-facing bugs.
It being a large and old code-base, there are tons of tickets like:
- [Maintenance] Do not bind against SomeProvider in ChangeOps
- Make X maintenance script more database friendly
- Create Docker-based CI job to build some specialized GUI
- UnitTest noise from DataUpdaterOutputManagerTest
- Write ADR and Docs about Caching in some specific domain
- Performance audit
- Unify react templates
- Migrate old ruby browser tests
- … etc.
What criteria would you suggest for ranking such tasks in order to create something like “Maintenance Pain” or “Developer Pain”, so that one can then just pick the ticket with the highest pain score?
Go to Source
Author: Michael Große