Severity grades how badly a service is impaired. Impact is the effect on users or on a business process. Urgency is how soon the business needs the service restored. Priority is the order in which responders work the incident. Bug severity grades how far the software's behavior departs from what was specified or expected. Work item priority is the order a delivery team intends to pick up the work. Requirement priority is how important a requirement is relative to others.
The severe one waited, and the logo did not
Saturday at fictional Lantern Works. Checkout is up. The month-end export that finance uses on Monday morning is writing blank files, and the receipt logo is the old one for a launch happening today. The on-call engineer asks which item is "P1". The word is doing several jobs: how badly the service is impaired, what business effect that has, how soon restoration is needed, and how soon someone will touch it. Those answers come apart as soon as the calendar does.
Four facts on one incident
Incident severity uses the scale the organization uses for operations. A low number is not universally the worst grade. The scheme belongs to the organization. Impact can name which work is blocked. Teams often align the grade and the effect, and the two can still differ. A severe impairment of a service that nobody needs until morning can have low urgency.
Incident priority is often chosen from impact and urgency, and a person can override that suggestion. The attribute stores the resulting order for that incident. It does not store the impact, and it does not store the urgency. The Information Technology Infrastructure Library (ITIL) names impact, urgency, and priority for this ordering, and does not define severity as that order. Severity is also not the support tier that holds the ticket, and it is not the incident's status.
In the invented Saturday:
| Situation | Severity, impact, urgency, and the order |
|---|---|
| Checkout down for every buyer | High impairment. Buyers cannot pay. Restore now. The order is work it now. |
| Month-end export blank, needed Monday morning | High impairment of that job. Monday's close is blocked. Urgency stays low until Monday morning, so the order can wait. |
| Receipt logo wrong, launch today | Low, cosmetic impairment. The launch looks wrong. Urgency is high because the launch is today, so the order jumps the queue. |
The export is a severe fault in a service with no users until Monday morning. The logo is a small impairment that blocks today's launch. Priority follows the chosen order. Severity stays with the impairment. If a regulator moves the export deadline to today, urgency changes and the stored priority can change with it. Severity does not, unless the impairment itself is regraded.
A bug can carry both a grade and an order
Bug severity runs from data loss or a crash down to a cosmetic miss. It grades the flaw. It does not say when a team will fix it. That order is the work item priority on the work item. It is a planning decision. It is not bug severity, and it is not requirement priority.
A bug is a work item, so it can carry a bug severity and a work-item priority at the same time. Incident severity is a different attribute. It grades impairment of a running service. One flaw can have a bug severity in the backlog and, once it hurts a service, an incident severity on the incident. Bug vs defect vs incident keeps those records apart. Copying the incident's priority onto the bug, or the bug's severity onto the incident, answers the other record's question with this record's scale.
A requirement is another scale
Requirement priority uses the scheme the organization chooses for a requirement. One scheme is MoSCoW, which stands for must, should, could, and won't. That is a priority classification for a need. It does not grade the severity of a running failure or of a defect. A rank, or another local scheme, uses the same attribute. The scheme is not fixed, and priority is not the requirement's status.
"Must" on a requirement does not mean "high severity" on a bug, and it does not mean "page someone". A must-have requirement can be a quiet piece of compliance work. A could-have requirement can describe a screen that, once broken in production, is a severe incident. The words were assigned in different rooms, about different facts.
What to store
Store severity, impact, and urgency on the incident as separate attributes, and store the chosen order in incident priority. Store bug severity on the bug, and work-item priority on the work item. Store requirement priority on the requirement, in its own scheme. When a report says "everything is P1", ask whether the column is the impairment, the business effect, the hurry, or the queue. Incident vs problem vs change is the record those grades attach to. None of the grades above is a benchmark. The Saturday cases are invented.
