Prüfungsreifes Wissen,
strukturiert statt gestapelt.

Musterantwort: Product Backlog → Product Goal (langfristiges Produktziel). Sprint Backlog → Sprint Goal (das eine Ziel des Sprints). Increment → Definition of Done (Qualitätsstandard für "fertig"). Die Commitments schaffen Transparenz und Fokus: Sie geben jedem Artefakt eine verbindliche Zielgröße, an der Fortschritt gemessen wird.

Musterantwort: Die Definition of Done ist teamweit und gilt für jedes Increment gleichermaßen: Sie beschreibt den Qualitätszustand, den jede Arbeit erreichen muss (z.B. getestet, dokumentiert, integriert, deploybar). Akzeptanzkriterien sind dagegen spezifisch für einen einzelnen Product-Backlog-Eintrag und beschreiben, welches fachliche Verhalten dieser eine Eintrag zeigen muss. Beide sind nötig: Die DoD sichert die durchgehende, vergleichbare Qualität und verhindert, dass Qualität unter Termindruck verhandelt wird; Akzeptanzkriterien sichern, dass der konkrete fachliche Bedarf getroffen wird. Ein Eintrag ist erst dann fertig, wenn er BEIDE erfüllt. Nur die DoD ist ein Scrum-Element (Commitment zum Increment); Akzeptanzkriterien sind eine verbreitete, aber optionale Praktik.

Musterantwort: Die drei Größen bilden eine Kette von der langfristigen Absicht bis zur Qualitätsuntergrenze. Das Product Goal ist das Commitment des Product Backlog und beschreibt den mittelfristig angestrebten Zustand des Produkts; es gibt allen Sprints eine gemeinsame Richtung. Das Sprint-Ziel ist das Commitment des Sprint Backlog und beschreibt, welchen Beitrag genau dieser Sprint zum Product Goal leisten soll; es schafft Fokus und erlaubt es den Developers, im Sprint flexibel über den Weg zu entscheiden. Die Definition of Done ist das Commitment des Increments und legt fest, welchen Qualitätszustand Arbeit erreichen muss, um überhaupt als fertig zu gelten. Fehlt das Product Goal, werden die Sprints zu einer Folge zusammenhangloser Einzellieferungen ohne erkennbare Produktrichtung. Fehlt das Sprint-Ziel, zerfällt der Sprint in eine Aufgabenliste, jede Störung wiegt gleich schwer und es gibt keinen Maßstab dafür, worauf das Team bei Engpässen verzichten kann. Fehlt die Definition of Done, ist "fertig" Auslegungssache, das Increment wird unzuverlässig, und Transparenz sowie Inspektion verlieren ihre Grundlage.

Musterantwort: Die Bitte ist abzulehnen, weil sie das Problem nicht löst, sondern verdeckt. Die Definition of Done legt fest, wann Arbeit fertig ist; wird sie für einen Termin abgesenkt, entsteht formal ein Increment, das die zugesagte Qualität nicht hat. Die weggelassene Arbeit verschwindet nicht, sondern wird zu unsichtbarer Restarbeit und technischer Schuld, die spätere Sprints belastet und deren Umfang niemand kennt. Zugleich verliert das Wort "fertig" seine Bedeutung, womit Transparenz und Prognosefähigkeit beschädigt werden. Tragfähig ist stattdessen, den Umfang zu verkleinern statt die Qualität: Das Team liefert weniger Funktionalität, diese aber vollständig nach der Definition of Done. Weitere Möglichkeiten sind, gemeinsam mit dem Product Owner die Reihenfolge neu zu ordnen und auf den wirklich termindringenden Kern zu fokussieren, den Termin mit reduziertem Umfang und offener Kommunikation gegenüber dem Kunden zu halten oder das Increment bewusst als Vorabversion mit klar benannten Einschränkungen zu zeigen. Dauerhaft darf die Definition of Done selbstverständlich verändert werden – aber als bewusste, für alle sichtbare Entscheidung des Scrum Teams und nicht als stille Ausnahme unter Termindruck.

Musterantwort: Fertig im Sinne der Definition of Done bedeutet, dass ein Increment den vereinbarten Qualitätszustand erreicht hat und damit potenziell nutzbar ist: Es ist getestet, integriert, dokumentiert und erfüllt alle Kriterien, die das Scrum Team oder die Organisation festgelegt hat. Ausgeliefert bedeutet, dass dieses Increment tatsächlich an Nutzer gegeben wurde. Scrum verlangt, dass am Sprint-Ende ein fertiges Increment vorliegt, aber es verlangt nicht, dass es ausgeliefert wird. Über die Auslieferung entscheidet der Product Owner, und zwar nach fachlichen Erwägungen wie Marktzeitpunkt, Bündelung mehrerer Funktionen oder regulatorischen Rahmenbedingungen. Die Unterscheidung ist wichtig, weil sonst zwei Fehler entstehen. Der erste besteht darin, "nicht ausgeliefert" als Rechtfertigung dafür zu nehmen, dass Arbeit auch nicht fertiggestellt werden muss; damit wächst unsichtbare Restarbeit. Der zweite besteht darin, eine Auslieferung zu erzwingen, obwohl sie fachlich unsinnig ist. Entscheidend ist die Handlungsfähigkeit: Das Produkt muss jederzeit auslieferbar sein, damit die Entscheidung über den Zeitpunkt eine freie bleibt und nicht vom technischen Zustand diktiert wird.

Musterantwort: Das Team liegt deutlich über der Orientierung von typischerweise 10 oder weniger Personen. Große Teams erzeugen überproportional viele Kommunikationswege, was Abstimmungsaufwand, Entscheidungsdauer und Event-Länge erhöht und die Kohäsion senkt. Mögliches Vorgehen: das Team selbst die Aufteilung erarbeiten lassen (Selbstverwaltung) – etwa entlang von Produktbereichen, Wertströmen oder Nutzergruppen, nicht entlang von Fachdisziplinen, damit jedes entstehende Team cross-funktional bleibt und eigenständig ein Increment liefern kann. Wichtig: bei einem gemeinsamen Produkt bleibt es bei EINEM Product Backlog und EINEM Product Owner; jedes Team braucht eine gemeinsame Definition of Done und ein integriertes Increment. Alternativ prüfen, ob das Team nur temporär gewachsen ist. Ein Skalierungsrahmenwerk (z.B. Nexus) ist erst sinnvoll, wenn mehrere Teams dauerhaft am selben Produkt arbeiten.

Musterantwort: Die fünf Werte: Commitment, Fokus, Offenheit, Respekt, Mut. Beispiel (Mut): Ein Developer spricht im Daily offen an, dass ein gewählter Lösungsweg nicht funktioniert, obwohl das unangenehm ist – so kann das Team früh adaptieren. (Jedes plausible Beispiel zu einem Wert zählt.)

Musterantwort: Verletzt werden vor allem Offenheit und Mut: Der tatsächliche Stand wird beschönigt, unangenehme Wahrheiten (Überplanung, Qualitätsprobleme, unklare Definition of Done) werden nicht ausgesprochen. Damit fällt auch die Transparenz weg, die Voraussetzung für sinnvolle Inspektion in Review und Retrospektive ist. Commitment ist ebenfalls betroffen, weil die Selbstverpflichtung auf das Sprint-Ziel ihren Ernst verliert, wenn Nichterreichen folgenlos umdeklariert wird. Häufig steckt dahinter ein Umfeld, in dem Misserfolg bestraft wird – hier ist Respekt seitens der Organisation gefragt. Konsequenz: Die Retrospektive muss das Muster selbst zum Thema machen, statt weiter Symptome zu behandeln.

Musterantwort: Mögliche Ursachen: Der Scrum Master beschränkt sich auf Organisation und Moderation, wird nur innerhalb der Events tätig, arbeitet nicht an organisationalen Hindernissen und macht seine Arbeit an Systemthemen nicht sichtbar. Häufig fehlt zudem eine klare Erwartungsklärung bei Übernahme der Verantwortlichkeit. Wirksamkeit lässt sich erhöhen, indem er erstens alle drei Dienstebenen bedient, also Team, Product Owner und Organisation, statt nur die Events; zweitens an wiederkehrenden Impediments außerhalb des Teams arbeitet, wo das Team keinen Zugriff hat; drittens Coaching und Teaching einsetzt, damit das Team Fähigkeiten aufbaut, statt Aufgaben an ihn abzugeben; viertens seine Wirkung überprüfbar macht, etwa an Lieferfähigkeit, Qualität des Increments und Selbstständigkeit des Teams; fünftens Erwartungen mit Team, Product Owner und Management ausdrücklich klärt. Entscheidend ist die Haltung: Er verbessert das System, in dem gearbeitet wird, nicht die einzelne Aufgabe.

Musterantwort: Zunächst würde ich die Frage nicht als Kapazitätsfrage führen, sondern als Wirkungsfrage. Die relevante Größe ist nicht, wie viele Teams betreut werden, sondern was sich in diesen Teams und in der Organisation tatsächlich verändert. Dann würde ich meine Arbeit sichtbar machen, denn ein Teil des Problems ist, dass Arbeit an Systemthemen von außen unsichtbar bleibt. Konkret: Welche wiederkehrenden Impediments liegen außerhalb der Teams, seit wann bestehen sie, und wieviel Kapazität kosten sie? Solche Belege verschieben das Gespräch von Empfindungen zu Fakten. Inhaltlich würde ich darlegen, was bei drei Teams bereits entfällt. Der Scrum Guide nennt drei Dienstebenen: Team, Product Owner und Organisation. Erfahrungsgemäß bleibt bei wachsender Teamzahl zuerst die Organisationsebene liegen, also genau die, auf der die teuersten Hindernisse sitzen. Was bleibt, ist Anwesenheit in Events, und das ist Moderation, nicht Scrum Mastery. Dann würde ich Alternativen anbieten statt nur abzulehnen: Erstens die Teams befähigen, Facilitation und einfache Impediments selbst zu übernehmen, damit meine Zeit frei wird für das, was sie nicht können. Zweitens die Betreuung zeitlich staffeln, etwa ein Team intensiv beim Aufbau und andere in loserer Begleitung, statt alle gleich dünn. Drittens gemeinsam vereinbaren, woran wir in drei Monaten erkennen, ob die Aufteilung trägt. Wichtig ist die Haltung im Gespräch: Die Führungskraft hat ein legitimes Problem, nämlich unbesetzte Teams. Ein reines Nein löst es nicht. Ich würde deshalb ausdrücklich benennen, worauf bei vier Teams verzichtet wird, und die Entscheidung informiert bei ihr lassen, statt sie mir aufzudrängen zu lassen.

Musterantwort: Der Scrum Master führt, indem er dient: Er schafft die Bedingungen, unter denen das Team erfolgreich selbstorganisiert arbeitet – durch Coaching, Facilitation, Hindernisbeseitigung und Schutz des Teams. Er weist keine Aufgaben zu, kontrolliert nicht und trägt keine disziplinarische Weisungsbefugnis. Ein Projektmanager plant/steuert/kontrolliert direkt; der Scrum Master befähigt das Team, sich selbst zu steuern.

Musterantwort: Ein Impediment ist ein Hindernis, das den Fortschritt des Teams zum Sprint-Ziel blockiert oder verlangsamt. Der Scrum Master hilft, es transparent zu machen und zu beseitigen – selbst, wenn es außerhalb des Teams liegt (z.B. mit anderen Abteilungen/Management verhandeln). Beispiel: fehlende Testumgebung, ständige externe Unterbrechungen, unklare Zuständigkeiten. Der SM räumt das Hindernis aus dem Weg, statt es nur zu dokumentieren.

Musterantwort: Zuerst würde ich die Beobachtung selbst zum Gegenstand machen, statt ein weiteres Format auszuprobieren. Ich benenne im Event faktisch, dass dieselben Themen wiederkehren und keine der beschlossenen Maßnahmen umgesetzt wurde, und frage das Team, woran das aus seiner Sicht liegt. Häufig zeigt sich dann eine von drei Ursachen. Erstens können die beschlossenen Maßnahmen zu groß, zu unbestimmt oder ohne Verantwortlichen gewesen sein; dann hilft es, pro Retrospektive genau eine konkrete, kleine Maßnahme mit einer verantwortlichen Person zu vereinbaren und sie in das nächste Sprint Backlog aufzunehmen, damit sie nicht neben der eigentlichen Arbeit verschwindet. Zweitens können die Themen außerhalb des Einflussbereichs des Teams liegen; dann ist der Ort der Bearbeitung falsch, und meine Aufgabe ist es, diese Impediments in der Organisation zu adressieren, statt das Team wiederholt über Unveränderliches sprechen zu lassen. Drittens kann fehlende psychologische Sicherheit dazu führen, dass die eigentlichen Themen gar nicht ausgesprochen werden und stattdessen unverfängliche Ersatzthemen kreisen; dann arbeite ich mit Formaten, die stille Stimmen strukturiert einholen, und gegebenenfalls in Einzelgesprächen. Zusätzlich würde ich sichtbar machen, was aus früheren Maßnahmen geworden ist, etwa durch eine kurze Nachschau zu Beginn jeder Retrospektive.

Musterantwort: Die Lage deutet darauf hin, dass die Rolle auf ihren sichtbarsten Anteil reduziert wurde. Die Moderation der Events ist nur ein kleiner Teil der Verantwortung; hinzu kommen die Arbeit an Impediments außerhalb des Teams, die Unterstützung des Product Owners bei Backlog-Management und Produktplanung, die Begleitung der Selbstverwaltung sowie die Arbeit an den organisatorischen Rahmenbedingungen. Genau diese Anteile fallen bei Überlast zuerst weg, weil sie weniger sichtbar sind und keinen Kalendereintrag haben. Die Folge ist ein Scrum Master, der als Meeting-Moderator wahrgenommen wird, während die eigentlichen Hindernisse unbearbeitet bleiben. Als Auswege kommen mehrere Ansätze in Betracht. Kurzfristig kann er Moderationsaufgaben schrittweise an die Teams abgeben, was ohnehin dem Ziel der Selbstverwaltung entspricht, und sich auf die Themen konzentrieren, die nur er bearbeiten kann. Mittelfristig muss er die Überlastung gegenüber dem Management transparent machen, und zwar nicht als persönliche Klage, sondern anhand konkreter Folgen: liegengebliebene Impediments, wiederkehrende Probleme, verzögerte Entscheidungen. Möglich ist auch, sich bewusst auf weniger Teams zu konzentrieren, statt alle gleich schlecht zu begleiten, oder Teammitglieder für die Rolle zu befähigen. Wichtig ist, die Frage nicht als Zeitmanagementproblem zu behandeln, sondern als Frage, welchen Anspruch die Organisation an die Rolle tatsächlich stellt.

Musterantwort: Aussagekräftig sind Größen, die zeigen, ob das System besser funktioniert: Liefert das Team regelmäßig ein Increment, das die Definition of Done erfüllt? Wird die Definition of Done über die Zeit strenger statt schwächer? Nimmt die Zahl wiederkehrender Impediments ab, und werden sie schneller gelöst? Löst das Team Probleme zunehmend selbst, ohne den Scrum Master? Kommt echtes Stakeholder-Feedback im Review an und verändert es das Product Backlog? Setzt das Team Verbesserungen aus der Retrospektive tatsächlich um? Nicht aussagekräftig sind Velocity, Auslastung, Zahl moderierter Meetings, Anwesenheitsquoten oder die Einhaltung ursprünglicher Schätzungen. Diese Größen messen Aktivität statt Wirkung und erzeugen als Ziel eingesetzt Fehlanreize. Wichtig ist außerdem, dass die Anhaltspunkte gemeinsam mit dem Team betrachtet werden, statt sie als Berichtsinstrument nach oben zu verwenden.

Musterantwort: Die Lage deutet darauf hin, dass die Rolle auf ihren sichtbarsten Teil reduziert wurde. Die Moderation der Events ist nur ein Ausschnitt der Verantwortung; hinzu kommen die Arbeit an Impediments außerhalb des Teams, die Unterstützung des Product Owners bei Backlog-Management und Produktplanung, die Entwicklung der Selbstverwaltung sowie die Arbeit an den organisatorischen Rahmenbedingungen. Genau diese Anteile fallen bei Überlast zuerst weg, weil sie keinen Kalendereintrag haben und ihr Ausbleiben nicht sofort auffällt. Die Folge ist ein Scrum Master, der als Meeting-Moderator wahrgenommen wird, während die eigentlichen Hindernisse unbearbeitet bleiben – und das wiederum bestätigt das Bild der Rolle als reiner Terminorganisation. Als Auswege kommen mehrere Ansätze in Betracht. Kurzfristig lässt sich die Moderation schrittweise an die Teams abgeben, was ohnehin dem Ziel der Selbstverwaltung entspricht, sodass Kapazität für die Themen frei wird, die nur er bearbeiten kann. Mittelfristig muss er die Überlastung gegenüber dem Management transparent machen, und zwar nicht als persönliche Klage, sondern anhand konkreter Folgen: liegengebliebene Impediments, wiederkehrende Probleme, verzögerte Entscheidungen. Möglich ist auch, sich bewusst auf weniger Teams zu konzentrieren, statt alle gleich schlecht zu begleiten. Entscheidend ist, die Frage nicht als Zeitmanagementproblem zu behandeln, sondern als Frage, welchen Anspruch die Organisation an die Rolle tatsächlich stellt.

Musterantwort: Übernommen wurden die sichtbaren Elemente, nicht die Grundlagen. Ein Lenkungsausschuss, der über Inhalte entscheidet, ersetzt faktisch den Product Owner: Der Scrum Guide sieht eine Person mit der Entscheidungsbefugnis über das Product Backlog vor, und diese Befugnis muss von der Organisation respektiert werden. Ein Gremium kann beraten, aber nicht anordnen, ohne die Rolle auszuhöhlen. Die Steuerung der Developers nach Auslastung widerspricht der Selbstverwaltung: In Scrum entscheidet das Team, wer woran arbeitet, und der Maßstab ist das Sprint-Ziel, nicht die Beschäftigung einzelner Personen. Auslastungssteuerung erzeugt zudem viel gleichzeitig begonnene Arbeit, verlängert Durchlaufzeiten und verhindert, dass das Team gemeinsam auf ein Ziel hinarbeitet. Es fehlen damit die beiden Dinge, die Scrum überhaupt wirksam machen: echte Entscheidungsbefugnis beim Product Owner und echte Selbstverwaltung bei den Developers. Ohne sie bleiben die Events Rituale – eine Form, die den alten Ablauf lediglich neu benennt. Ein wirksamer Ansatzpunkt ist, das Missverhältnis anhand konkreter Folgen sichtbar zu machen, etwa anhand von Durchlaufzeiten und nicht erreichten Sprint-Zielen, und die Diskussion mit dem Management auf Entscheidungsbefugnisse zu richten statt auf Meeting-Formate.

Musterantwort: Zunächst würde ich klären, welche Frage das Management eigentlich beantwortet haben will, denn "hat es etwas gebracht" meint je nach Gesprächspartner schnellere Auslieferung, bessere Qualität, verlässlichere Aussagen oder zufriedenere Kunden. Anschließend wähle ich Belege, die auf das Produkt und nicht auf die Teamaktivität zielen. Aussagekräftig sind Time-to-Market beziehungsweise die Zeit von der Idee bis zur Auslieferung, die Durchlaufzeit einzelner Einträge, die Häufigkeit von Auslieferungen, die Fehlerrate im Betrieb sowie die tatsächliche Nutzung ausgelieferter Funktionen. Ergänzend eignen sich die vier Wertbereiche aus Evidence-Based Management, weil sie aktuellen Wert, unrealisierten Wert, Innovationsfähigkeit und Time-to-Market getrennt betrachten und damit auch unbequeme Befunde sichtbar machen. Auf Teamebene ist die Verlässlichkeit beim Erreichen der Sprint-Ziele ein brauchbarer Indikator, ebenso die Abnahme unfertiger Restarbeit. Bewusst nicht heranziehen würde ich Velocity, Auslastung oder die Anzahl gelieferter Funktionen: Velocity ist teamspezifisch und verliert ihren Wert, sobald sie zum Ziel wird, und die Menge gelieferter Funktionen sagt nichts über deren Nutzen aus. Wichtig ist außerdem, den Ausgangszustand zu benennen und ehrlich zu sagen, welche Veränderungen sich nicht kausal auf Scrum zurückführen lassen.

Musterantwort: Zürst versteht der Scrum Master das dahinterliegende Bedürfnis, denn meist steckt echte Dringlichkeit dahinter und keine Böswilligkeit. Dann macht er die Auswirkung transparent: Zusatzarbeit im laufenden Sprint gefährdet das Sprint-Ziel, und Direktbestellungen an Einzelne untergraben die Selbstverwaltung und machen Arbeit unsichtbar. Er erklärt den vorgesehenen Weg: Bedürfnisse gehen an den Product Owner und ins Product Backlog, wo sie gegen anderes abgewogen werden. Für echte Notfälle vereinbart er mit Product Owner und Team einen ausdrücklichen Umgang, statt ihn dem Zufall zu überlassen; im Extremfall kann der Product Owner den Sprint abbrechen. Zugleich stärkt er die Developers darin, solche Anfragen selbst an den Product Owner zu verweisen, damit er nicht dauerhaft als Puffer auftritt. Wiederholt sich das Muster, ist es ein organisationales Impediment und gehört auf die Ebene, die es auflösen kann.

Musterantwort: Am Anfang überwiegt die lehrende Haltung. Das Team braucht ein gemeinsames Verständnis von Zweck und Ablauf der Events, von den Verantwortlichkeiten und vom Sinn der Artefakte und ihrer Commitments; hier wären coachende Fragen unangebracht, weil das Wissen schlicht fehlt. Parallel dazu übernimmt der Scrum Master die Moderation der Events, achtet auf die Timeboxen und macht vor, wie eine Retrospektive zu Ergebnissen führt. In der zweiten Phase verschiebt sich der Schwerpunkt zur Facilitation und zum Coaching: Das Team kennt die Regeln inzwischen und soll die Events zunehmend selbst tragen, weshalb der Scrum Master Moderationsaufgaben abgibt und stattdessen mit Fragen arbeitet, die Muster sichtbar machen. Gleichzeitig beginnt die Arbeit an der Selbstverwaltung, etwa indem er sich bewusst zurückhält, wenn das Team eine Entscheidung erwartet. In der dritten Phase verlagert sich der Fokus nach außen: Die verbleibenden Hindernisse liegen meist nicht mehr im Team, sondern in der Organisation, also bei Abhängigkeiten, Berichtspflichten oder unklaren Entscheidungsbefugnissen. Der Scrum Master arbeitet dann verstärkt mit dem Product Owner, dem Management und anderen Teams. Der rote Faden ist die abnehmende Unentbehrlichkeit: Er misst seinen Erfolg daran, wie viel das Team ohne ihn bewältigt.

Musterantwort: Der Streit ist ein Symptom, nicht das eigentliche Problem, und er deutet meist auf unklare Verantwortlichkeiten hin. Nach dem Scrum Guide entscheiden die Developers, wie viel Arbeit sie in den Sprint aufnehmen; der Product Owner bringt Reihenfolge und Sprint-Ziel ein und kann helfen, Kompromisse und Alternativen zu verstehen. Ist diese Aufteilung unklar oder wird sie nicht respektiert, wiederholt sich der Konflikt in jedem Planning. Als Erstes würde ich diese Rollenverteilung außerhalb des Events mit beiden Seiten klären, damit die Auseinandersetzung nicht jedes Mal von vorn beginnt. Als Zweites würde ich den Blick auf das Sprint-Ziel lenken. Wird zuerst gemeinsam geklärt, welchen Wert der Sprint liefern soll, verschiebt sich die Diskussion von der Menge der Einträge zur Frage, was für dieses Ziel wirklich nötig ist – und damit von einer Verhandlung zu einer gemeinsamen Gestaltungsaufgabe. Als Drittes würde ich mit Daten arbeiten: Wenn in mehreren Sprints regelmäßig Arbeit liegenbleibt, ist das eine überprüfbare Beobachtung und nicht mehr eine Meinung. Schließlich würde ich in der Retrospektive den Umgang miteinander thematisieren, falls der Ton bereits persönlich geworden ist. Meine eigene Rolle bleibt dabei allparteilich: Ich entscheide die Frage nicht, sondern sorge dafür, dass sie am richtigen Ort und mit den richtigen Informationen entschieden wird.

Musterantwort: Transparenz: Wichtige Aspekte (Artefakte, Fortschritt) sind für alle sichtbar. Inspektion: Regelmäßiges Prüfen (in den Events), ob man dem Ziel näherkommt. Adaption: Bei Abweichung wird der Plan oder das Produkt angepasst. Im Sprint wirken sie zusammen: Transparente Artefakte werden in den Events inspiziert, Abweichungen führen zur Adaption (z.B. Plan im Daily anpassen).

Musterantwort: Wahrscheinlich fällt die Transparenz aus, und in der Folge laufen Inspektion und Adaption ins Leere. Die Events finden zwar formal statt, aber es fehlt der Gegenstand, den sie inspizieren sollen: Ohne ein Increment, das der Definition of Done entspricht, hat das Sprint Review kein belastbares Ergebnis zu prüfen, und Stakeholder-Feedback bezieht sich auf Zwischenstände oder Präsentationen statt auf funktionierende Arbeit. Typische Ursachen sind eine fehlende oder zu schwache Definition of Done, systematisch in den Folgesprint verschobene Restarbeit sowie ein Sprint Backlog, das den tatsächlichen Stand beschönigt. Die Inspektion ist dadurch wertlos, weil sie auf unvollständigen Informationen beruht, und die Adaption bleibt aus, weil das Team ohne belastbare Beobachtung nicht weiß, was es anpassen müsste. Der wirksamste Ansatzpunkt ist daher nicht, weitere Events einzuführen, sondern zuerst die Definition of Done zu schärfen und sichtbar zu machen, wie viel Arbeit tatsächlich unfertig ist. Erst wenn der reale Stand transparent ist, können Inspektion und Adaption ihre Wirkung entfalten.

Musterantwort: Transparenz bedeutet, dass Probleme, Fortschritt und Qualität sichtbar gemacht werden – auch unangenehme. Das gelingt nur, wenn Beteiligte keine Nachteile befürchten müssen (psychologische Sicherheit). Fehlt Vertrauen, werden Statusberichte geschönt, Impediments verschwiegen und die Definition of Done aufgeweicht. Folge: Die Inspektion basiert auf falschen Informationen, und die daraus abgeleitete Adaption geht in die falsche Richtung. Der empirische Regelkreis läuft dann formal weiter, erzeugt aber systematisch falsche Entscheidungen. Genau deshalb sind die Scrum-Werte (besonders Offenheit, Mut, Respekt) keine Dekoration, sondern Voraussetzung für das Funktionieren der drei Säulen.

Musterantwort: Zürst wird die Lage transparent gemacht – im Daily Scrum, sobald die Erkenntnis vorliegt, nicht erst am Sprintende. Dann verhandeln die Developers mit dem Product Owner den Umfang neu: Das Sprint-Ziel bleibt bestehen, aber der konkrete Umfang der Arbeit ist im Sprint ausdrücklich verhandelbar. Möglich sind Aufteilung des Eintrags in einen kleineren, zielrelevanten Teil, Zurücknahme anderer Einträge oder eine reduzierte Lösung, die das Ziel dennoch erfüllt. Nicht scrum-konform wären: Verlängerung des Sprints, Absenken der Definition of Done, stilles Überziehen oder Nacharbeit außerhalb des Sprints. Lässt sich das Sprint-Ziel gar nicht mehr erreichen und ist es zudem obsolet geworden, kann allein der Product Owner den Sprint abbrechen. Die Ursache (Schätzung, Refinement-Tiefe) gehört in die Retrospektive.

Musterantwort: Die feste Sprint-Länge ist die Messlatte der Empirie. Würde man den Sprint verlängern, bis die geplante Arbeit fertig ist, verschwände genau die Information, um die es geht: nämlich dass mehr geplant wurde, als das Team leisten konnte. Der Vergleich zwischen Sprints wäre nicht mehr möglich, weil jeder Sprint eine andere Dauer hätte, und die Prognosefähigkeit ginge verloren. Zudem entfiele der regelmäßige Takt, auf den sich Stakeholder und Organisation verlassen. Stattdessen endet der Sprint zum festgelegten Termin. Was der Definition of Done entspricht, ist Teil des Increments; was nicht fertig ist, kehrt in das Product Backlog zurück und wird dort vom Product Owner neu bewertet und eingeordnet – es wandert also nicht automatisch in den nächsten Sprint. Im Sprint Review wird der tatsächliche Stand offen gezeigt, und die Retrospektive nimmt sich der Frage an, warum die Prognose nicht aufging. Wichtig ist die Unterscheidung: Die Sprint-Länge kann für künftige Sprints geändert werden, aber niemals während eines laufenden Sprints.

Musterantwort: Zunächst würde ich die Beobachtung von der Deutung trennen. Fünf verfehlte Ziele sind ein Muster, kein Einzelfall, und Muster haben meist systemische Ursachen. Auf Ebene des Sprint-Ziels: Ist es überhaupt ein Ziel oder nur eine Zusammenfassung der ausgewählten Einträge? Ein Ziel, das lautet "alle Einträge fertigstellen", ist konstruktionsbedingt nicht erreichbar, sobald etwas schiefgeht, weil es keinen Verhandlungsspielraum über den Umfang lässt. Auf Ebene der Planung: Wird der Umfang systematisch zu groß gewählt? Häufig steckt dahinter die Erwartung von außen, eine bestimmte Menge zuzusagen, oder die Unfähigkeit, Nein zu sagen. Zu prüfen ist auch, ob unsichtbare Arbeit anfällt, etwa Support oder Zuarbeit für andere Teams, die nie im Sprint Backlog auftaucht. Auf Ebene der Arbeit: Stauen sich Einträge am Ende des Sprints, weil alle parallel begonnen und nichts fertig wird? Werden Abhängigkeiten zu anderen Teams erst im Sprint sichtbar? Ist die Definition of Done so aufwendig, dass Fertigstellung strukturell nicht in einen Sprint passt? Auf Ebene der Organisation: Wird das Team im Sprint unterbrochen, sind Mitglieder mehreren Vorhaben zugeordnet, fehlen Entscheidungen des Product Owners? Vorgehen: Ich würde das Muster in der Retrospektive selbst zum Thema machen und dabei mit Daten arbeiten statt mit Eindrücken, etwa mit der Verteilung der Fertigstellungen über die Sprinttage und dem Anteil ungeplanter Arbeit. Dann würde ich mit dem Team eine Hypothese wählen und eine einzige Änderung ausprobieren, statt fünf Maßnahmen gleichzeitig zu beschließen. Wiederholtes Verfehlen ist außerdem oft ein Vertrauensproblem: Wenn ein verfehltes Ziel sanktioniert wird, wird das Team beim nächsten Mal ein beliebig erreichbares Ziel formulieren, und dann ist die Information endgültig verloren. Was ich nicht täte: die Auswahlmenge pauschal reduzieren, ohne die Ursache zu kennen, oder das Sprint-Ziel abschaffen, weil es ohnehin nicht erreicht wird.