Task management systems usually come with severity and priority options, however I’ve rarely seen clear, up front definitions of how they should be used. There’s myriad ways of course, but here I’m going to share a simple one I’ve used in a couple of my former placements, just as a straw man.
Severity can be used to flag the difficulty of the fix, however that can be achieved by tasking out and estimating the fix. I think it’s better to use it to flag to the business how major the issue is from the user’s point of view.
There are three factors that I chose to decide that:
- Whether functionality or content is impaired
- How obvious that impairment is to the user
- How many users are affected
These can be combined into 3 general situations, with severities depending on the proportion of users affected:
Situation 1: Content/functionality broken, and obvious to users
- All users => Severity 1
- >10% users => Severity 2
- <10% users = > Severity 3
Situation 2: content/functionality broken, but not obvious to users
- All users => Severity 2
- >10% users => Severity 3
- <10% users = > Severity 4
Situation 3: Display issue, not obscuring content or functionality
- All users => Severity 3
- >10% users => Severity 4
- <10% users = > Severity 5
Use this to flag to the developers which tasks to tackle first. It should be influenced by the severity, but also by stakeholder views and business needs – things like booked ad campaigns for the product, or politically powerful stakeholders who may otherwise cause the project difficulty.
This makes priority more subjective, but hopefully less than it would have been without the objective severity value acting as a guide.
After agreeing these severity definitions, the BA and project sponsor can get together and (without reference to specific issues, which gets emotive) do a cost benefit analysis to decide how much time it’s normally worth the business spending on each severity. For example:
- Severity 1 to 3, fix no matter how long it takes
- Severity 4 spend no more than a developer day
- Severity 5 spend no more than a developer hour
This gives a clear, pre-agreed mechanism to drop tickets aren’t worth the money / lost development time to the business – an otherwise controversial and CYA-riddled action.
- Give the user a voice via severity
- Agree severity metrics up front, so you don’t get mired in subjective debate
- Define a ticket’s severity before priority, using those metrics
- Give the business a (better informed) final say via priority
- Define what fixing each severity level is worth to the business