Hi dear readers -
Following thoughts came directly from discussion with @asavin started from this article about necessity or redundancy of both - Severity and Priority - attributes of tasks / defects / bug reports.
My humble opinion stayed with classics - both attributes are required. Let me try to substantiate why.
E.g. some financial system has a critical bug related to switching a calendar year.
Severity is S1, sure.
But what about priority? It's P4 in January 1, but gradually raises till P1 till the end of the year coming a show-stopper on December 31.
Thus we can track this ticket and easily prioritize it among others in a backlog:
It was S1 x P4 - not so urgent to spend time on that those days, but when it's S1 x P1 - let's fix it finally.
Of course it's a rough example, but representative, I hope :)
Simple: assuming that we have only one attribute, let's say Priority, and this attribute is of 4 levels (P1 - to - P4) we are bucketing all the tickets in only 4 sets. Thus we should always think about - what to take first among all these tasks with P1. And then the same about tasks with P2 and so on.
But having two attributes with 4 levels each (P1 - to - P4 for Priority and S1 - to - S4 for Severity) we are sorting all the tickets in 16 (!) buckets.
And than it might be considerably simpler to make a decision: what should be done earlier and what may be put aside.
I would suggest using the following prioritization for S x P combinations:
Following thoughts came directly from discussion with @asavin started from this article about necessity or redundancy of both - Severity and Priority - attributes of tasks / defects / bug reports.
1. Dynamic world
Severity and Priority are in different planes by nature - with time one attribute may change it's value, when another - stay stable. Or both might change. In this case combination of Severity and Priority (S x P) can better reflect dynamically changed environment around us.E.g. some financial system has a critical bug related to switching a calendar year.
Severity is S1, sure.
But what about priority? It's P4 in January 1, but gradually raises till P1 till the end of the year coming a show-stopper on December 31.
Thus we can track this ticket and easily prioritize it among others in a backlog:
It was S1 x P4 - not so urgent to spend time on that those days, but when it's S1 x P1 - let's fix it finally.
Of course it's a rough example, but representative, I hope :)
2. Sorting the mass
This side is both - not applicable for a very small backlogs but should be considered for large projects with a lot of tickets in To Do lists.Simple: assuming that we have only one attribute, let's say Priority, and this attribute is of 4 levels (P1 - to - P4) we are bucketing all the tickets in only 4 sets. Thus we should always think about - what to take first among all these tasks with P1. And then the same about tasks with P2 and so on.
But having two attributes with 4 levels each (P1 - to - P4 for Priority and S1 - to - S4 for Severity) we are sorting all the tickets in 16 (!) buckets.
And than it might be considerably simpler to make a decision: what should be done earlier and what may be put aside.
- P1 & S1 - to be done ASAP;
- P1 & S2;
- P1 & S3;
- P1 & S4;
- P2 & S1;
- P2 & S2;
- P2 & S3;
- P2 & S4;
- P3 & S1;
- P3 & S2;
- P3 & S3;
- P3 & S4;
- P4 & S1;
- P4 & S2;
- P4 & S3;
- P4 & S4 - to be done last or never...
Severity x Priority decision matrix |
I would appreciate any suggestions, advice or critics in comments or via personal e-mails.
And thank you for reading till this very point :)
Комментариев нет:
Отправить комментарий