Issues Severity vs frequency

h1. Guidelines for Issues severities, frequency and workaround

Issue Severities Each issue must be assigned a ‘severity’. The severity is used to communicate and record the effect of the issue to the customer. An issue is assigned a severity based on its impact to the customer, the customer’s ability to work while the issue is still live and the frequency of occurrence. The severity is used when prioritising work on an issue and that works impact on planned development. 5 severities exist, 1 being the highest severity with 5 being the lowest. The following flow chart and definitions should be used when identifying the correct severity.

Impact

VH - Primary function* of the system is not available or is significantly impeded
H - Primary function* is impeded or other significant function is not available
L - Other significant function is 'impeded'
VL - Problem does not impact the use of the system

∗- Primary function is defined as the core task that the system is designed to do. E.g.

Workaround The customer can continue to make use of the functionality unimpeded through other means than they would usually be expected to do.

Frequency

High - Problem occurs frequently enough that it would affect a customer at least once per day on a fully running system.
Low - Above criteria clearly not met

Notes

If it is believed that a customer will be highly critical of the severity assigned then consideration should be given to raising the severity based on this fact
These severities are to be applied to actual incidents and not to be used for risk assessment

Severity Service Levels Based on the severity, the issue should be prioritised as follows.

1 – All reasonable resources will be utilised to find a solution and provide to the customer immediately.
2 – All reasonable resources will be utilised to ensure that a workaround is available to the customer and a solution is made available within the next scheduled release candidate (unless identified workaround is a significant drain in which case an immediate solution will be sought)
3 – Will be added to the work backlog of the appropriate Soft.D.E team with a high priority (guide to fix within 2 – 3 sprints)
4 – Will be added to the work backlog of the appropriate Soft.D.E team with a medium priority
5 – Will be recorded, and fixed when all higher priority items are fixed or used for training of developers

The group will be using JIRA for defect tracking. JIRA will contain short description of defect possible effort estimation to fix the defect and the priority to fix the defect. Once bugs are discovered in the code, they must be added to JIRA by any team member (preferably the person who discovered it). If the bug in question is trivial and can be fixed without much effort, the founder of the bug can assign it to themselves and proceed accordingly. However, if the bug requires more attention or is clearly out of the founder’s field of knowledge, they must be assigned to the project manager who will then in co-operation with the architect decide to whom it will be delegated to. Defects will be categorized based on their criticism to one of the following: blocker, critical, major, minor and trivial. They will be processed according their criticism level.

8D If it is believed that finding the cause and identifying a solution will likely take more than 1 man days of work then the 8D methodology must be used to resolve the issue.

Minor Problems If the reported problem will take less than 1hr of work and it's severity appears to be 3 or below then logging the issue etc can be left out.