Incident Management Where the Follow Up Actually Happens

1. 1

   Agree the severity levels before anything happens

   Write down what each severity means and what each one obliges you to do. Severity one wakes people up, severity three waits until Monday. Deciding this during an incident is how you get it wrong.

   Carried byWiki
2. 2

   Raise one incident record, immediately

   The first person who sees it creates the record. One record, whatever channel the report came from, so three people do not investigate the same thing separately.

   • Support tickets get linked to the incident rather than answered individually
   • The record is the single source of truth for the rest of the incident

   Carried byBug and issue trackingTicketing
3. 3

   Name an incident commander

   One named person, on the record, who makes the calls. They do not have to be the most senior engineer, and it is usually better if they are not, because their job is coordination rather than debugging.

   Carried byTask management
4. 4

   Keep the timeline as you go

   Every finding, every action, and every decision goes on the incident record as a comment with a timestamp. Nobody can reconstruct this afterwards, and the postmortem is worthless without it.

   • Mention people on the record rather than messaging them separately, so the context stays in one place
   • Self-hosted teams can push updates into a Microsoft Teams channel as they happen

   Carried byMentionsMicrosoft Teams
5. 5

   Split investigation from communication

   The people fixing it should not also be writing customer updates. Give the communications lead the update tasks on a fixed cadence, so responders are not interrupted every ten minutes to be asked for a status.

   Carried byCollaboration
6. 6

   Make the incident statuses match reality

   Investigating, identified, mitigating, monitoring, resolved. These are not the same as a defect flow, and using the wrong statuses means the board does not tell you anything at a glance.

   Carried byCustom status workflow
7. 7

   Mitigate first, fix properly second

   Restoring service and fixing the root cause are two different pieces of work. Close the incident when service is restored, and raise the proper fix as its own defect so it goes through normal prioritisation.

   Carried byBug and issue tracking
8. 8

   Run the postmortem within a week

   While people still remember. Go through the timeline you kept, and produce actions rather than blame. Anything that does not have an owner and a due date is not an action, it is a wish.

   Carried byWikiTask management
9. 9

   Put the actions in the backlog and chase them

   This is the step everybody skips. Each postmortem action becomes a real task with an owner and a due date, linked back to the incident, and it gets reviewed monthly with the rest of the backlog.

   • Report on how many postmortem actions are still open, by age
   • An action that is six months old is a decision not to do it, so close it honestly

   Carried byAdvanced reportingReports and analytics

1. 1Create an incidents project from the Bug Tracking templateIt opens on a board, which is the right view for a queue where you want to see status at a glance.
2. 2Set the incident statusesInvestigating, identified, mitigating, monitoring, resolved. Add them from the board or the status workflow page.
3. 3Write the severity definitionsThree or four levels, each with what it obliges the team to do. Put them on a wiki page and link it from the project.
4. 4Add the fields you will want laterSeverity, affected service, customer impact, and detection method, as custom fields so you can report on them.
5. 5Decide who can be incident commanderA named list, agreed in advance. The rota itself lives in whatever on call tool you use.
6. 6Set the monthly action reviewOne recurring meeting to check open postmortem actions. Without it, the actions rot.

Orangescrum does not do alerting or paging. Keep your monitoring and on call tooling. This is where the record, the coordination, and the follow up work live.