Definition
The process outlined in this document is only concerned with a mismatch between the behaviour of a system and expectations of that system occurring, after the feature development has been completed by the responsible scrum team.
There are many definitions for bugs and defects, both in their causes and the time of their detection, unfortunately many definitions are contradictory.
As JIRA has the ‘bug’ issue type, for simplicity that term will be used when referring to any problem identified after the JI for the feature has been updated to ‘Done’, irrespective of who discovered the issue and at what point in the software lifecycle.
Deciding Priority
When deciding how to respond to a bug, consider the two variables of probability and severity, and apply them to a risk matrix to determine the priority and corresponding action.
Probability
How often actual customers are likely to encounter the issue during their use of the product?
A feature rarely used, with a high likelihood of failure, may have a lower overall probability than a popular feature with a low likelihood of failure (due to a high number of customers affected).
Frequent | Will occur several times in the lifetime of the product. |
|---|---|
Probable | Likely to occur often in the lifetime of the product. |
Occasional | Likely to occur some time in the lifetime of the product. |
Remote | Unlikely but possible to occur in the lifetime of the product. |
Improbable | So unlikely, it can be assumed occurrence may not be experienced. |
Severity
How bad is the problem when it is encountered?
An issue that causes data loss/corruption is automatically classed as Catastrophic.
Catastrophic | Detrimental risk for the product as a whole. |
|---|---|
Critical | Jeopardises feature(s) of the product, not ruining the product entirely. |
Moderate | Jeopardises aspects of a feature, not ruining the feature entirely. |
Marginal | Causes an inconvenience when using a feature of the product. |
Insignificant | No significant threat posed and can be left unmediated. |
When judging the severity of the bug as insignificant (ie the bug does not need addressing) it automatically gets set as P5 (very low) priority.
Risk Matrix
Catastrophic | Critical | Moderate | Marginal | |
|---|---|---|---|---|
Frequent | Very High | High | High | Medium |
Probable | High | High | Medium | Medium |
Occasional | High | Medium | Medium | Low |
Remote | Medium | Medium | Low | Low |
Infrequent | Medium | Low | Low | Very Low |
Priority Levels
Priority | Policy (recommended actions) | |
|---|---|---|
P1 | Very High | Added immediately to the current sprint taking priority over that work. It may very well require the effort of more than one team member, possibly including the whole team. |
P2 | High | Added immediately to the current sprint and resolution starts as soon as logically possible. Ideally, should be resolved by the end of the sprint. Team decides who can best address the issue. |
P3 | Medium | Added as a priority for the next sprint, at the discretion of the product owner. |
P4 | Low | Documented. Discussed in the next sprint planning meeting at the discretion of the product owner. Candidate for a Good First Issue for the community. |
P5 | Very Low | Documented in list of known issues. Revisited only if severity or probability increases or at the discretion of the product owner. Candidate for a Good First Issue for the community. |