Action Items Post-Mortem: Warum die meisten Teams scheitern
Zusammenfassung
Mehr als 50 % der Action Items Post-Mortem werden nie abgeschlossen. Nicht aus mangelndem Engagement -- sondern wegen Prozess: unspezifische Items, Teams statt Engineers als Eigentümer, und Docs ohne Verbindung zu Sprint-Arbeit. Items, die abgeschlossen werden, teilen drei Merkmale: ein namentlicher Engineer, eine konkrete Definition of Done und ein Ticket, das vor Ende des Meetings erstellt wurde. Dieses Playbook zeigt, wie man von 42 % auf über 75 % kommt.
Action Items Post-Mortem scheitern in den meisten Teams -- nicht weil niemand das Review macht, sondern weil die Items selbst kaputt sind: kein namentlicher Eigentümer, kein konkretes Datum, kein Anschluss an die Sprint-Planung. Laut Forschung von incident.io liegt die Abschlussquote beim typischen SRE-Team unter 50 %. Das Dokument ist nicht die Arbeit. Das Ticket ist die Arbeit.
Euer Team hat letzten Dienstag ein Post-Mortem durchgeführt. Sechs Action Items wurden dokumentiert. Inzwischen haben vielleicht zwei davon ein Jira-Ticket. Eines gehört jemandem, der gerade an einem anderen Incident sitzt. Drei stehen noch im Google Doc, unter der Überschrift "Follow-ups", unberührt.
Die Lösung ist kein besseres Template. Es ist ein anderes Verständnis davon, was ein Action Item überhaupt ist.
Warum die meisten Action Items strukturell kaputt sind
"Monitoring verbessern" in ein Post-Mortem zu schreiben fühlt sich produktiv an. Das ist kein Action Item -- das ist eine Arbeitskategorie ohne Eigentümer, ohne Deadline, ohne Definition of Done.
Wirksame Action Items haben drei unverzichtbare Bestandteile: Was muss erledigt werden (konkret und messbar), wer verantwortet es (ein namentlich genannter Engineer, kein Team), und bis wann (ein konkretes Datum, kein "Q3"). Fehlt auch nur eines dieser Elemente, wird das Item mit hoher Wahrscheinlichkeit nie geschlossen -- weil abstrakte Items nicht deprioritisiert werden. Sie lösen sich auf. Niemand entscheidet aktiv, sie nicht zu tun. Sie tauchen einfach nie in den Systemen auf, in denen tatsächlich Arbeit geplant wird.
Der Unterschied ist schärfer als er klingt. "Rate Limiting verbessern" ist Fiktion. "@anya: Circuit Breaker für upstream Search-API-Calls im Checkout-Pfad hinzufügen -- Ziel: gemergt bis 2026-09-19" ist ein Action Item. Eines davon wird im Standup auftauchen. Das andere nicht.
Das strukturelle Scheitern passiert im Moment des Schreibens -- wenn die Engineers müde sind, das Meeting zu lang läuft und der Druck abzuschließen höher ist als der Druck präzise zu sein. Genau dann ist Präzision am wichtigsten -- weil Kontext schnell zerfällt und das Detail, das man um 23 Uhr überspringt, das ist, nach dem @anya in drei Wochen fragen muss.
Die Zahl, die jeden Engineering Lead beunruhigen sollte
Mehr als 50 % der Action Items Post-Mortem werden in typischen SRE-Teams nie abgeschlossen. In Organisationen mit schwacher Incident-Kultur übersteigt dieser Wert 70 %.
Was das für Reliability im Maßstab bedeutet: Wenn eure Post-Mortems im Schnitt vier Action Items pro Incident ergeben und ihr zehn Incidents pro Quartal habt, generiert ihr 40 Items, schließt weniger als 20 ab und tragt einen wachsenden Rückstand ungelöster Failure Modes mit euch. Der nächste Incident ist statistisch gesehen wahrscheinlich eine Variante von etwas, das ihr bereits diagnostiziert habt.
DORA-Forschung zeigt konsistent, dass hochperformante Engineering-Organisationen niedrigere Change Failure Rates haben -- nicht weil sie bessere Post-Mortems schreiben, sondern weil sie ihre Action Items schließen. Das Dokument ist nicht die Arbeit. Das Ticket ist die Arbeit.
Wenn die Abschlussquote unter 50 % fällt, werden Post-Mortems zum Theater -- geschrieben, um einen Prozess zu erfüllen, nicht um etwas zu verändern. Das Team weiß es. Die Engineers, die sorgfältige Items schreiben, sehen, wie sie verwelken. Irgendwann sinkt die Qualität der geschriebenen Items auf das Niveau der Abschlussquote. Warum ein präzises, zuweisbares Item schreiben, wenn niemand die vorhandenen schließt?
Mitigativ und Präventiv sind nicht dieselbe Queue
Action Items Post-Mortem lassen sich in zwei Kategorien aufteilen -- und beide gleich zu behandeln ist ein Planungsfehler, der sich mit der Zeit verstärkt.
Mitigative Items reduzieren den Blast Radius des nächsten Auftretens, bevor die Ursache beseitigt wurde. Fallback hinzufügen. Timeout setzen. Circuit Breaker verdrahten. Diese Items sind fast immer dringend und sollten innerhalb eines Sprints geshippt werden -- idealerweise noch vor Ende des Post-Mortem-Meetings, wenn sie klein genug sind.
Präventive Items beseitigen den Failure Mode vollständig: Queue Consumer refactoren, Retry-Logik überarbeiten, den SLO-Gap instrumentieren, der bei eurem Burn Rate Alert durchgerutscht ist. Diese dauern länger, erfordern ein Design Review und konkurrieren direkt mit Feature-Arbeit.
Beide in einem einzigen "post-mortem actions"-Label zu mischen bedeutet: Die langen präventiven Items hängen so lange auf der Liste, bis das Team vergessen hat, warum sie geschrieben wurden -- während die mitigativen dahinter in derselben Queue warten. Trennt sie explizit. Mitigative Items kommen vor dem Sprint Planning in den aktuellen Sprint. Präventive Items werden nach eigenem Rhythmus gegen euren Roadmap priorisiert -- als Reliability-Investition behandelt, nicht als Post-it-Notizen, die an einem längst geschlossenen Incident kleben.
Wo Action Items begraben werden
Das Google Doc ist das häufigste Grab.
Teams erstellen Post-Mortems in gemeinsamen Dokumenten, weil Docs während eines Incidents unkompliziert sind. Das Problem: Das Doc ist nicht dort, wo Engineering-Arbeit tatsächlich stattfindet. Jira ist es. Linear ist es. GitHub Issues ist es. Wo auch immer euer Sprint Planning stattfindet -- dort muss ein Action Item landen, bevor das Post-Mortem-Meeting endet.
Die Integrationslücke ist der vorhersehbarste Schwachpunkt im gesamten Workflow. Incident passiert. Post-Mortem läuft. Gute Action Items werden geschrieben. Dann muss jemand sie manuell in ein Ticket-System kopieren. Dieser Kopierschritt hat eine Abschlussquote von grob 40 % bei Teams, die ihn nicht automatisieren oder erzwingen.
Die Lösung ist kein neues Tool -- es geht darum, die Lücke zwischen dem Post-Mortem-Dokument und dem Sprint-System zu schließen. Mehrere Incident-Management-Plattformen schreiben mittlerweile Jira- oder Linear-Tickets direkt aus Post-Mortem-Templates. Notiz-Tools, die strukturierte Items mit Eigentümern erzeugen und in euren Tracker integrieren, leisten dasselbe. Das Grundprinzip: Kein Engineer sollte nach einem 90-minütigen Review-Meeting am Ende einer On-Call-Schicht aus einem Doc in ein Ticket kopieren.
Meetings, die Action Items einfangen, bevor sie verfliegen
Ein unterschätztes Problem: Die Action Items, die in einem Post-Mortem-Meeting festgehalten werden, sind nicht immer dieselben, die am Ende im Dokument stehen.
In einer Runde von vier Engineers, die sich nach einem harten Incident sammeln, tauchen die wichtigsten Items oft im Gespräch auf, bevor jemand einen Laptop aufgeklappt hat. "Wir hätten das im Canary abfangen müssen" -- ist das ein Action Item? Kommt darauf an, wer es gehört hat, ob jemand es aufgeschrieben hat und ob der Moderator am Ende gefragt hat.
Die Moderator-Rolle im Post-Mortem ist schwieriger, als sie aussieht. Man managt Gruppendynamiken, hält die Timeline ehrlich, beobachtet den Raum auf Attribution Drift -- und soll gleichzeitig jedes Follow-up erfassen, das auftaucht. Irgendetwas entgleitet. Das ist keine Nachlässigkeit; das ist kognitive Last.
KI-Notiztools, die im Hintergrund laufen und strukturierte Items aus Meeting-Transkripten destillieren, sind eine praktische Lösung für dieses Problem geworden. Nicht weil sie smarter als Engineers sind, sondern weil sie nicht müde sind, nicht den Raum managen und nicht zwischen Moderieren und Dokumentieren hin- und herspringen. Das Ergebnis braucht weiterhin menschliche Überprüfung. Aber einen First-Pass-Entwurf der Items aus dem vollständigen Gespräch zu haben -- einschließlich des beiläufigen Kommentars nach 45 Minuten -- verändert, was das Meeting überlebt.
Das Eigentümer-Problem: Teams schließen keine Aufgaben ab
Einem Team ein Action Item zuzuweisen ist das organisatorische Äquivalent davon, es niemandem zuzuweisen.
Teams haben keine Kalendererinnerungen. Sie werden nicht in Jira angezeigt. Sie tauchen nicht im Standup auf, wenn ein Item überfällig ist. "Das Platform-Team" hat keinen Notification-Eingang. @carlos hat einen.
Namentlich genannte Eigentümer sind wichtig -- aber namentlich genannte Eigentümer mit Kontext sind noch wichtiger. "@carlos: SQS-Consumer in payments-worker um exponentielles Backoff erweitern -- siehe Incident-Timeline für das Burst-Muster, das um 14:23 UTC auftrat. Ziel: gemergt vor Sprint-Close am 2026-09-26, Jira: PAY-2891" ist etwas, das @carlos ohne ein weiteres Gespräch ausführen kann.
Das Post-Mortem ist der Moment, in dem Kontext am höchsten ist. Dann schreibt man das Item. Der Detailgrad zerfällt schnell -- innerhalb von 48 Stunden hat die Hälfte des Raums das spezifische Burst-Muster vergessen, das den Failure ausgelöst hat. Nach zwei Wochen ist der Incident Hintergrundrauschen. Das Item, das mit vollem Kontext am Ende des Post-Mortem-Meetings geschrieben wurde, wird abgeschlossen. Das Item, das "wir schreiben das später sauber auf" bekommt, wird verwaist.
Observability-Lücken sind ein Sonderfall
Ein erheblicher Anteil der Action Items Post-Mortem betrifft Observability-Lücken: eine Metrik, die nicht instrumentiert war, ein Alert-Threshold, der zu locker war, ein Dashboard, das existierte, aber nicht im Runbook verlinkt war, ein SLO-Fenster, das zu breit war, um die Degradation zu erkennen, bevor Nutzer sie bemerkten.
Diese Items haben ein vorhersehbares Scheitermuster. Sie erfordern Zugang zum Monitoring-Stack. Sie sind nicht dringend, sobald der Incident geschlossen und das unmittelbare Feuer gelöscht ist. Und sie erfordern häufig Koordination zwischen dem Product-Team, das den Incident hatte, und dem Platform-Team, das das Observability-Tooling verantwortet -- ein Übergabepunkt, an dem oft niemand formell die Verantwortung für den Abschluss übernimmt.
Die Lösung: Observability-Action-Items als First-Class-Kategorie behandeln -- mit einem direkten Eigentümer im Platform-Team, nicht im Product-Team, das den Incident hatte. "P99-Latenz-Alert auf search-service Checkout-Pfad hinzufügen" sollte einen Eigentümer in eurer Observability-Plattform haben -- jemanden, der tatsächlich den Zugang und den Kontext hat, die Alert-Regel zu schreiben -- nicht einen Product-Engineer, der erst drei Rückfragen stellen muss, bevor er anfangen kann.
Den Feedback-Loop schließen, den niemand schließt
Es gibt einen Schritt nach dem Abschluss, den die meisten Teams komplett überspringen: ihn anzuerkennen.
Wenn ein Action Item aus Post-Mortem #47 das Wiederauftreten verhindert, das zu Incident #58 geworden wäre, sollte diese Verbindung sichtbar gemacht werden. Schreibt es in euren Incident-Channel. Nehmt es in das nächste Engineering All-Hands auf. Lasst den On-Call-Engineer, der PAY-2891 besaß, wissen, dass sein Circuit Breaker letzten Donnerstag einen Burst absorbiert hat und nichts gepaged hat.
Engineering-Teams schließen mehr Action Items ab, wenn sie sehen, dass ihre Arbeit sich auszahlt. Teams, die Items in ein Doc schreiben, das niemand mehr aufruft, hören irgendwann auf, sie sorgfältig zu schreiben -- die Form bleibt, aber die Qualität sinkt auf das Niveau der wahrgenommenen Wirkung. So kann eine Blameless-Post-Mortem-Kultur immer noch eine Reliability-Kultur ohne Gedächtnis produzieren.
Der Feedback-Loop ist das, was Post-Mortem-Kulturen, die sich verbessern, von denen unterscheidet, die nur die Form wahren. Um 3 Uhr morgens weiß der On-Call-Engineer, der letztes Quartal einen Timeout wegen eines eigenen Items gefixt hat, genau, wofür die Arbeit war. Macht diese Verbindung für das gesamte Team sichtbar -- nicht nur für die Person, die zufällig On-Call war, als der Fix seinen Wert bewies.
So sieht ein funktionierendes Action Item aus
Das Format, das konsequent abgeschlossen wird:
Item: Circuit Breaker für search-service-Upstream-Calls hinzufügen (payments path)
Eigentümer: @danielle
Typ: mitigativ
Fällig: 2026-09-12 (vor nächstem Deploy nach prod)
Ticket: PAY-2891
Kontext: search-service-Timeouts haben um 14:23 UTC kaskadierende Fehler im Checkout
verursacht; Circuit Breaker begrenzt Blast Radius bei erneutem Auftreten,
während das Refactoring gescoped wirdSieben Felder. Das "Kontext"-Feld ist nicht optional. Es ist das, was die drei Wochen Lücke zwischen dem Post-Mortem und dem Sprint überlebt, in dem @danielle endlich Bandwidth hat. Ohne es ist das Item eine Aufgabe ohne Geschichte. Mit ihm kann @danielle PAY-2891 kalt öffnen und genau wissen, was sie baut und warum es wichtig ist.
Was das vom Engineering Lead fordert
Abschlussquoten bei Action Items sind eine Team-Lead-Metrik, keine Engineer-Metrik.
Die Engineers schreiben die Items. Der Lead ist verantwortlich für das System, das sicherstellt, dass sie geschlossen werden. Konkret bedeutet das vier Dinge:
Erstens, Sprint-Kapazität für mitigative Items, die reserviert wird, bevor das Planning startet -- nicht nachdem das Team seine Velocity für Feature-Arbeit vergeben hat. Wenn mitigative Items um Reste konkurrieren müssen, verlieren sie.
Zweitens, ein fester Fünf-Minuten-Review offener Post-Mortem-Items beim wöchentlichen Team-Sync. Keine Zeremonie. Nur ein Scan: Alles älter als 14 Tage ohne Ticket, alles Überfällige, das eine Entscheidung braucht.
Drittens, explizite Deprioritisierung, wenn etwas wirklich nicht erledigt werden kann. "Wir machen PAY-2891 dieses Quartal nicht, weil der Payments-Refactor in Q4 kommt und das redundant macht" ist eine Entscheidung. "PAY-2891 liegt seit drei Monaten im Backlog" ist ein Prozessversagen.
Viertens, die Abschlussquote von Action Items als Team-Health-Metrik verfolgen -- neben Deployment Frequency und MTTR. Teams, die es messen, stellen fest, dass sie ohne bewussten Prozess bei etwa 42 % liegen. Mit namentlichen Eigentümern, Sprint-Integration und wöchentlichem Review steigt diese Zahl innerhalb von zwei Quartalen über 75 %. Der Unterschied in Reliability-Hinsicht entspricht in etwa der Verhinderung eines weiteren schwerwiegenden Incidents pro Quartal bei einem Team mit zehn Incidents.
Das Post-Mortem hat euch gesagt, was kaputt war. Das Action Item ist der Vertrag, es zu reparieren. Ob dieser Vertrag abgeschlossen wird, ist eine Management-Entscheidung -- kein Problem mit der Dokumentqualität.