Fehlerbehandlung [Praxis]

4 Übungsfragen mit Lösung und Erklärung.

☝️ SingleWie geht ein Scrum Team mit Fehlern am bestehenden Produkt um?
Fehler werden als Product-Backlog-Einträge geführt und vom Product Owner mit der übrigen Arbeit gemeinsam priorisiert
Fehler werden grundsätzlich sofort und vor allen anderen Einträgen behoben
Fehler werden gesammelt und in einem eigenen Sprint abgearbeitet
Fehler werden in einem separaten Fehlerbacklog außerhalb von Scrum verwaltet
Ein separates Fehlerbacklog zerstört die Vergleichbarkeit: Der Product Owner kann Fehlerbehebung und neue Funktion nur dann gegeneinander abwägen, wenn beide in derselben Liste stehen.
☝️ SingleWas ist der Zweck einer Blameless Postmortem nach einem Produktionsvorfall?
Die Velocity-Auswirkung des Vorfalls zu berechnen
Die verantwortliche Person zu ermitteln und den Vorfall zuzuordnen
Den Vorfall für die Rechtsabteilung zu dokumentieren
Die Ursachen im System und im Ablauf zu verstehen, ohne Schuldige zu suchen, damit künftig offen gemeldet wird
Sobald Schuld gesucht wird, sinkt die Meldebereitschaft – und damit die Information, aus der man lernen könnte. Genau das ist der Grund für die Blameless-Regel.
☝️ SingleEin Team wird laufend durch dringende Produktionsstörungen aus dem Sprint gerissen. Was ist der tragfähigste Umgang?
Das Sprint-Ziel jedes Mal anpassen, wenn eine Störung eintritt
Die Störungsarbeit als wiederkehrende Größe anerkennen, bei der Sprint-Auswahl Kapazität dafür einplanen und parallel die Ursachen abbauen
Einen festen Anteil des Teams dauerhaft aus dem Scrum-Rahmen herauslösen
Störungen grundsätzlich ablehnen und auf den nächsten Sprint verweisen
Beide Extreme scheitern: Störungen zu ignorieren geht am Betrieb vorbei, sie unbegrenzt hereinzulassen macht jede Planung sinnlos. Die Ursachen abzubauen ist der einzige Weg, der die Größe dauerhaft verringert.
✍️ OffenBeschreiben Sie, wie ein Scrum Team wachsende technische Schulden sichtbar und entscheidbar macht.
Musterantwort: Der erste Schritt ist, die Schulden aus dem Bereich der Gefühle in den Bereich der Beobachtung zu holen. Dazu eignen sich konkrete Belege: Bereiche mit auffällig häufigen Fehlern, Arbeitspakete, deren Umsetzung deutlich länger dauert als vergleichbare, wiederkehrende Nacharbeit, lange Bauzeiten oder Stellen, an denen niemand mehr Änderungen vornehmen will. Diese Beobachtungen lassen sich mit einfachen Kennzahlen unterlegen, etwa der Entwicklung der Durchlaufzeit in bestimmten Bereichen oder der Fehlerdichte. Der zweite Schritt ist die Übersetzung in die Sprache der Entscheidung. Technische Schulden interessieren einen Product Owner nicht als technischer Zustand, sondern als künftige Kosten und als verlorene Geschwindigkeit; entsprechend wird formuliert, welche geplante Arbeit dadurch teurer oder riskanter wird. Der dritte Schritt ist die Verankerung, damit nicht in jedem Sprint neu verhandelt werden muss. Am wirksamsten ist, Qualitätskriterien in die Definition of Done aufzunehmen, sodass neue Schulden gar nicht erst entstehen. Für den Abbau bestehender Schulden bewährt sich die Boy-Scout-Regel, also das schrittweise Verbessern jedes berührten Bereichs, ergänzt um gezielte Einträge im Product Backlog für größere Sanierungen. Der vierte Schritt ist die Nachverfolgung: Das Team prüft in der Retrospektive, ob die Maßnahmen wirken, und passt sie an. Was nicht funktioniert, ist das stille Einplanen von Sanierungsarbeit ohne Absprache – das untergräbt das Vertrauen und die Transparenz gleichermaßen.
← Alle ThemenIm Quiz üben