Incident retro

A preview of how this template lays out — the boards, their custom workflow states, and where the sample issues land. WIP caps show a badge.

• INC-204 — checkout outage post-mortem

  Parent issue holds the timeline; action items live as sub-issues.

  P15pt

• Add synthetic check for checkout flow

  P13pt

• Document rollback runbook for payments

  P22pt

These rules aren't created when you apply the template — they're recipes you can wire up in Settings → Automations once your board exists.

• When

  Incident moves to 'Retro'

  Then

  Generate a retro template issue with timeline prompts

• When

  Action sub-issue overdue

  Then

  Notify the action owner and the incident commander

Open, Mitigated, Retro, Actions, Closed. The two columns that matter are Actions and Closed, because they encode the one rule that separates a retro practice from retro theatre: the incident is not closed until every action item is done. Most post-mortem processes produce a good document and a list of follow-ups that quietly evaporate, and the reason is almost always that the incident was closed when the document was written.

1. 1.Separate Mitigated from Closed and mean it

   Mitigated means customers are fine. Closed means the organisation has learned something and changed. Conflating them is the root failure of incident practice — the pressure to close is highest exactly when the adrenaline drops, and that is the moment the learning gets skipped.

2. 2.Build the timeline from evidence, not memory

   Reconstruct what happened from logs, deploys, alerts and chat transcripts with real timestamps, then annotate what people believed at each point. The gap between what was true and what was known is where the actual finding lives — and it is invisible if you write the timeline from recollection a week later.

3. 3.Keep it blameless in the specific technical sense

   Blameless does not mean nobody made a mistake. It means you assume everyone acted reasonably given what they could see, and you ask what made the wrong action look right. 'Engineer ran the wrong command' is not a finding; 'the staging and production consoles are visually identical' is. The first stops investigation, the second produces a fix.

4. 4.Write action items with an owner and a date, or do not write them

   An action item without a name and a date is a wish. Each becomes a sub-issue with both. Cap them at three to five — a retro that produces fourteen actions has produced zero, because nobody will do fourteen, and the team learns that this list is decorative.

5. 5.Let overdue actions be noisy

   The template's suggested rule pings the owner and the incident commander when an action slips. Keep that pressure on: the entire mechanism depends on Actions actually draining. If actions routinely go overdue, the honest reading is that you are committing to more remediation than you can staff, and the fix is to commit to less.

This board encodes one opinion about how the work should run. Here is where that opinion is wrong and something else fits better.

• You do not have an incident response process yet. A retro board is the back half of something that starts with detection, paging, and a declared commander. Retros on incidents nobody formally declared produce inconsistent input and a false sense of coverage.
• The incident has legal, regulatory or security-disclosure implications. Breach investigations, regulated outage reporting and anything heading toward litigation need counsel involved early and documentation handled with that in mind. A blameless internal retro on an open board is not the right container.
• You have a dedicated incident platform. PagerDuty, incident.io, FireHydrant and similar tie the retro to the actual incident record, auto-build the timeline from alerts and chat, and track actions from there. Duplicating that here means two sources of truth about what happened.
• You are running a general project retrospective. Sprint and project retros are a different practice — continuous improvement on a cadence, no incident, no timeline. Forcing them through incident columns produces a strange fit and a lot of empty fields.

Honest comparisons, including where the other tool wins. Planoda is pre-launch, so nothing below is a benchmark — it is a description of how each product approaches this job.

• incident.io and FireHydrant

  These build the timeline automatically from the incident channel, alerts and deploys, then generate the post-mortem document with that timeline already populated. That is a real capability gap: the most tedious part of a retro is reconstruction, and they remove it.

  Where incident.io and FireHydrant is better: Automatic timeline construction, integrated paging, and status-page updates from the same record are all things a board cannot do. If you run enough incidents to justify one, these tools are better at this specific job.

• Confluence

  The Confluence post-mortem page is the industry default, and it produces genuinely good documents — a searchable library with a consistent template. Its weakness is exactly the one this board targets: the action items are checkboxes on a page, and nothing chases them.

  Where Confluence is better: As a document and as a long-term searchable archive, Confluence is better. The strongest arrangement is often the write-up there and the action items tracked as real issues here.

• Jira

  Jira can model this with a post-mortem issue type and linked action issues, plus workflow validators that genuinely block closing the parent until children are done. That enforcement is stronger than a team norm.

  Where Jira is better: If you want the 'cannot close until actions are done' rule enforced by the tool rather than by discipline, Jira's workflow conditions do that natively.