Ein Pre-Mortem in Jira durchführen: Veröffentlichungsrisiken früh erkennen

Eine Veröffentlichung kann in Jira bereit wirken, obwohl das Team noch unausgesprochene Bedenken hat. Die Umsetzung ist fast fertig, Tests laufen und der Starttermin rückt näher. Jemand vermutet, dass ältere Kundenkonten anders reagieren. Eine andere Person befürchtet, dass der Support die neuen Steuerelemente falsch erklärt.

Ein Pre-Mortem gibt diesen Bedenken einen hilfreichen Ausgangspunkt: Stellen Sie sich vor, die Veröffentlichung sei bereits schlecht verlaufen, und beschreiben Sie dann die Ursachen. Die Übung erleichtert es, plausible Fehler zu besprechen, bevor das Team mit ihrer Behebung beschäftigt ist.

In dieser Anleitung führen wir ein praktisches Pre-Mortem für eine fiktive Kundenportal-Veröffentlichung durch und organisieren die Ergebnisse im Risk & Pre-Mortem Grid von Power Pack. Das Ergebnis ist eine kurze Risikoliste mit klaren Verantwortlichen, Warnsignalen und Maßnahmen zur Minderung.

Wählen Sie ein konkretes Veröffentlichungsergebnis

Unser Team ergänzt E-Mail-Einstellungen in einem Kundenportal. Kunden sollen optionale Konto-E-Mails ein- und ausschalten können und wesentliche Nachrichten weiterhin erhalten. Maya verantwortet das Produktergebnis, Leo setzt die Änderung um, Priya leitet die Tests und Sam bereitet den Support vor.

Als Ort für das Pre-Mortem wählt das Team den Jira-Vorgang zum gemeinsamen Veröffentlichungsergebnis. Zugehörige Entwicklungs- und Testtickets bleiben über den normalen Jira-Prozess verlinkt. Die Diskussion direkt beim Veröffentlichungsvorgang schafft einen naheliegenden Ort für spätere Prüfungen.

Vor dem Termin formuliert Maya den Umfang: Kundenerlebnis, E-Mail-Verhalten und Support-Bereitschaft für die erste Veröffentlichung der Einstellungen prüfen. Betrachtet werden der Start und die erste Nutzungswoche. Diese Grenze verhindert, dass das Gespräch zur Prüfung jedes denkbaren Portalproblems wird.

Stellen Sie sich einen Fehler vor, bevor Sie Lösungen diskutieren

Beginnen Sie mit einer konkreten Frage: „Es ist eine Woche nach dem Start. Kunden sind verwirrt, Support-Anfragen haben zugenommen und wir mussten die Einführung pausieren. Was ist passiert?“ Das vorgestellte Ergebnis sollte zum Nachdenken anregen, ohne Scheitern als unvermeidlich darzustellen.

Geben Sie allen einige ruhige Minuten, um unabhängig mögliche Ursachen aufzuschreiben. So kommen Bedenken aus Tests oder Beobachtungen des Supports zur Sprache, bevor die erste selbstsichere Erklärung das Gespräch dominiert. Bitten Sie um beschreibbare Ursachen statt allgemeiner Aussagen wie „Die Qualität war schlecht“.

Teilen Sie anschließend reihum die Szenarien. Sammeln und klären Sie in diesem ersten Durchgang die Bedenken. Die Diskussion über die beste Lösung folgt später. Beteiligte sollten eine unangenehme Möglichkeit ansprechen können, ohne sofort einen vollständigen Maßnahmenplan verteidigen zu müssen.

• Bestandskunden sehen Einstellungen, die nicht zu ihren aktuellen E-Mail-Einstellungen passen.
• Die Oberfläche vermittelt, dass wesentliche E-Mails deaktiviert werden können.
• Support-Anleitungen beschreiben Steuerelemente, die sich vor der Veröffentlichung geändert haben.
• Die Einstellungsänderung wirkt erfolgreich, obwohl die zugrunde liegende Änderung fehlschlägt.

Das sind fiktive Szenarien für unser Beispiel. Ihre eigene Liste sollte von den Personen kommen, die Arbeit, Abhängigkeiten und Kundenerlebnis kennen. Power Pack hält die Diskussion fest; das Team beurteilt, was geschehen könnte.

Formulieren Sie aus Bedenken erkennbare Risiken

Ein hilfreiches Risiko beschreibt ein mögliches Ereignis und dessen Folge. „Migration“ ist ein Thema. „Vorhandene Einstellungswerte werden falsch zugeordnet, sodass manche Kunden unerwünschte optionale E-Mails erhalten“ ist ein untersuchbares Szenario.

Führen Sie Duplikate zusammen, ohne unterschiedliche Folgen zu verlieren. Mehrere Bedenken zu älteren Konten können dieselbe Ursache haben. Eine irreführende Beschriftung und fehlgeschlagenes Speichern verwirren beide Kunden, brauchen aber andere Prüfungen und sollten meist getrennte Risiken bleiben.

Fragen Sie für jedes Szenario, was dem Team früh auffallen würde. Ein Frühwarnsignal ist eine beobachtbare Auffälligkeit, die Aufmerksamkeit verdient. In unserem Beispiel ist eine Abweichung zwischen vorhandenen Kontoeinstellungen und vorgesehenen migrierten Werten hilfreicher als „Kunden könnten sich beschweren“. Sie lässt sich vor dem Start prüfen.

Vereinbaren Sie die Bedeutung von Wahrscheinlichkeit und Auswirkung

Power Pack bietet eine 3×3- oder 5×5-Matrix und berechnet den Schweregrad als Wahrscheinlichkeit mal Auswirkung. Nutzen Sie den Wert für Diskussion und Sortierung. Er ist eine subjektive Einschätzung, keine Prognose der Fehlerhäufigkeit oder Berechnung des erwarteten Schadens.

Für den ersten Termin wählt unser Team 3×3 und einfache Bewertungsdefinitionen. Wahrscheinlichkeit eins bedeutet wenig aktuelle Anhaltspunkte; zwei bedeutet plausibel und untersuchungsbedürftig; drei bedeutet starke Gründe, ohne Maßnahmen mit dem Ereignis zu rechnen. Das sind die Arbeitsdefinitionen dieses Teams.

Die Auswirkung wird anhand von Kunden- und Veröffentlichungsfolgen definiert. Eins bedeutet begrenzte Unannehmlichkeiten, zwei eine bedeutsame Störung mit Nacharbeit und drei ein ernstes Kundenproblem oder einen Grund zum Pausieren der Veröffentlichung. Ein anderes Team benötigt möglicherweise andere Definitionen.

Priya bewertet die fehlerhafte Migration mit Wahrscheinlichkeit zwei und Auswirkung drei, also sechs Punkten. Das Team bespricht die Annahmen: Die neue Zuordnung wurde noch nicht mit repräsentativen älteren Konten erprobt. Die fehlenden Belege sind wichtiger als die scheinbare Genauigkeit der Zahl.

Behalten Sie beim ersten Risikovergleich dieselbe Skala bei. Ein Wechsel der Matrixgröße skaliert vorhandene Bewertungen um; prüfen Sie danach die Positionen. Eine neue Position ist kein neu entdeckter Beleg zur Veröffentlichung.

Tragen Sie die Risiken in Power Pack ein

Öffnen Sie Power Pack im gewählten Jira-Vorgang und wählen Sie Risk & Pre-Mortem Grid. Die Heatmap zeigt die Bewertungsverteilung, das Risikoregister die einzelnen Einträge. Wenn anfängliche Wahrscheinlichkeit und Auswirkung feststehen, können Sie ein Risiko direkt aus einer Matrixzelle hinzufügen.

Erfassen Sie je Eintrag Titel, Fehlerszenario, Frühwarnsignal und Kategorie. Ergänzen Sie vereinbarte Bewertungen, einen Maßnahmenplan und eine verantwortliche Person. Power Pack unterstützt auch Maßnahmenprüfpunkte, Status und einen optionalen Jira-Vorgangsverweis.

Die verantwortliche Person kann ein Jira-Nutzer oder ein externer Personeneintrag sein. Wählen Sie jemanden, der die Reaktion koordiniert und fehlende Belege ins Team zurückbringt. Die Benennung im Raster erstellt keine Jira-Aufgabe, weist keine vorhandene Aufgabe zu und gewährt keinen Vorgangszugriff.

Prüfen Sie den Speicherstatus, bevor Sie das aktualisierte Raster als geteilt betrachten. Änderungen werden am Vorgang gespeichert. Ein lokaler oder Wiederholungsstatus bestätigt nicht, dass andere bereits den neuesten Eintrag sehen können.

Geben Sie jedem wichtigen Risiko eine praktische Antwort

„Gründlich testen“ lässt sich schwer nachverfolgen. Für das Migrationsrisiko schlägt Priya einen Probelauf mit repräsentativen bestehenden Kontozuständen vor, gefolgt von einem Vergleich der Einstellungen und des erwarteten E-Mail-Verhaltens. Leo untersucht Abweichungen. Priya bleibt risikoverantwortlich und bringt das Ergebnis in die Veröffentlichungsprüfung ein.

Teilen Sie die Reaktion in Prüfpunkte auf, die Fortschritt sichtbar machen. Das Team könnte repräsentative Fälle wählen, den Probelauf ausführen, Abweichungen prüfen und verbleibende Unsicherheit dokumentieren. Prüfpunkte organisieren die Reaktion; die eigentlichen Belege bleiben in der zugehörigen Test- oder Umsetzungsarbeit.

Benötigt eine Maßnahme ein eigenes Jira-Ticket, erstellen Sie es und weisen Sie es über den normalen Jira-Workflow und ergänzen Sie dessen Schlüssel als Risikoverweis. Ein Verweis erleichtert das Nachvollziehen des Zusammenhangs; er erstellt die Arbeit nicht automatisch und verwaltet ihre Umsetzung nicht.

Prüfen Sie den Status bei neuen Belegen

Power Pack bietet Identified, In Progress, Mitigated und Accepted. Verwenden Sie Identified nach dem Erfassen des Szenarios und In Progress während der aktiven Bearbeitung. Vereinbaren Sie, welche Belege nötig sind, bevor ein Risiko als Mitigated gilt.

Accepted kann eine bewusste Entscheidung beschreiben, mit einem verbleibenden Risiko fortzufahren. Maya könnte beispielsweise eine kleine Lücke in der Support-Dokumentation akzeptieren, nachdem Sam eine vorübergehende Antwort bestätigt hat. Halten Sie die Begründung fest und prüfen Sie sie bei veränderten Annahmen erneut. Akzeptanz sollte eine verstandene Entscheidung sein, kein Mittel zum Aufräumen des Rasters.

Fragen Sie in der Veröffentlichungsprüfung nach Warnsignalen, Maßnahmenergebnissen und verbleibender Unsicherheit. Prüfen Sie wesentliche Umfangsänderungen, neue Abhängigkeiten und unerwartete Testergebnisse unabhängig. Aktualisieren Sie Bewertungen bei entsprechender Beweislage und erklären Sie die Änderung.

Sie können das Raster als Markdown oder CSV für eine Planungsdiskussion exportieren. Benennen Sie den Jira-Vorgang als Ort für den aktuellen Stand. Ein geteilter Export ist eine Momentaufnahme und entspricht möglicherweise nicht mehr der neuesten Einschätzung.

Verändern Sie mit dem Termin die nächsten Schritte

Ein ausgefülltes Raster ist hilfreich, wenn es die Vorbereitung beeinflusst. Für unser Portal-Team führt das Pre-Mortem zu einem Migrationsprobelauf, klareren Formulierungen und einem Abgleich zwischen Support-Anleitung und Veröffentlichungskandidat. Jede Maßnahme adressiert ein konkretes Fehlerszenario aus dem Team.

Beginnen Sie mit einer Veröffentlichung, einem kurzen moderierten Gespräch und wenigen sinnvollen Risiken. Halten Sie Szenarien, Verantwortliche und Reaktionen mit Power Pack beim Jira-Vorgang sichtbar. Nehmen Sie das Protokoll anschließend in das nächste Veröffentlichungsgespräch mit, damit das Team beurteilen kann, was sich tatsächlich verändert hat.