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 Product Goal ist das Commitment des Product Backlog – ein langfristiges Ziel/ein zukünftiger Zustand des Produkts, der Wert stiften soll. Das Product Backlog entsteht, um dieses Ziel zu erreichen; seine Items sind Schritte dorthin. Jeder Sprint bringt das Produkt näher ans Product Goal. Es gibt jeweils EIN aktives Product Goal; ein neues wird erst gesetzt, wenn das vorige erreicht (oder aufgegeben) ist.

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: Folgen: Die Verantwortlichkeit ist ausgehöhlt, weil Wertentscheidung und Rechenschaft auseinanderfallen. Entscheidungen dauern so lange wie der Sitzungsrhythmus des Ausschusses, wodurch das Team wartet und der empirische Kreislauf sich verlangsamt. Da niemand einzeln für den Produkterfolg einsteht, wird selten etwas abgelehnt und das Backlog wächst unkontrolliert. Das Team erhält Spezifikationen statt Absichten und baut deshalb Beschreibungen statt Lösungen. Weg heraus: Zunächst die Kosten des Zustands belegen, etwa Wartezeiten auf Entscheidungen, Anteil kaum genutzter Funktionen, Durchlaufzeit von der Idee bis zur Auslieferung. Dann eine Verschiebung der Zusammenarbeit vorschlagen, bei der der Ausschuss Rahmen und Ziele setzt, also Budget, Strategie und Product Goal, während die Reihenfolge innerhalb dieses Rahmens beim Product Owner liegt. Vertrauen entsteht über Transparenz: regelmäßige Sprint Reviews mit echten Ergebnissen und Wirkungsdaten ersetzen Kontrolle durch Nachvollziehbarkeit. Der Scrum Master unterstützt dabei auf der organisationalen Ebene. Ein realistischer Einstieg ist ein abgegrenzter Bereich, in dem der Product Owner tatsächlich entscheidet, und dessen Ergebnisse als Beleg dienen.

Musterantwort: Wert maximieren heißt, dass das Produkt möglichst großen Nutzen für Kunden, Nutzer und Organisation stiftet – gemessen an Outcomes (Nutzung, Zufriedenheit, Geschäftsziele), nicht an Output-Menge. Mehr Features (Output) können Wert sogar mindern (Komplexität, ungenutzte Funktionen). Der PO priorisiert deshalb nach erwartetem Wert/Risiko und misst empirisch, ob der Wert tatsächlich eintritt.

Musterantwort: Zürst macht er die Kapazitätsgrenze transparent statt sie zu verdecken: Was das Team pro Sprint tatsächlich liefert, ist eine belegbare Größe. Dann macht er die Absicht hinter den Anforderungen sichtbar, denn oft verbergen sich hinter mehreren Wünschen dieselben Bedürfnisse, die sich günstiger bündeln lassen. Er ordnet nach erwartetem Nutzen, Risikoabbau und dem richtigen Zeitpunkt und dokumentiert nachvollziehbar, warum etwas oben oder unten steht. Wichtig ist, dass er auch ausdrückliche Absagen ausspricht: Ein Backlog, in dem nichts abgelehnt wird, wird unüberschaubar und verliert seine Steuerungsfunktion. Gegenüber Stakeholdern arbeitet er mit Prognosen samt Unsicherheit statt mit Zusagen und nutzt das Sprint Review, um Entscheidungen an echten Ergebnissen zu begründen. Nicht tragfähig wären: alles zusagen, Arbeit an mehreren Zielen gleichzeitig starten oder Termindruck über eine gelockerte Definition of Done aufzufangen.

Musterantwort: Der Kern des Problems ist nicht die Menge, sondern dass die Wertentscheidung bereits außerhalb getroffen wurde. Ein Product Owner ohne Entscheidungsspielraum ist ein Verwalter einer fremden Liste. Zuerst würde ich Fakten schaffen. Was ist tatsächlich zugesagt, gegenüber wem, und wie verbindlich? Erfahrungsgemäß ist ein Teil der Zusagen weniger fest, als es in der Erzählung wirkt. Parallel würde ich den tatsächlichen Durchsatz erheben und ihm den zugesagten Umfang gegenüberstellen. Wenn zwölf Monate Zusagen achtzehn Monaten Arbeit entsprechen, ist das keine Meinung mehr, sondern eine Rechnung, die jeder nachvollziehen kann. Dann würde ich die Zusagen von Terminen auf Ziele verschieben. Ein Jahresplan auf Eintragsebene ist unhaltbar, ein Plan auf Zielebene nicht. Für die nächsten Monate lässt sich Verbindlichkeit zusagen, für den Rest eine Richtung mit ausdrücklicher Unsicherheit. Drittens würde ich einen Anteil der Kapazität für nicht vorab Zugesagtes sichern, etwa zwanzig Prozent. Ohne diesen Spielraum kann auf keine Erkenntnis und keinen Marktvorfall reagiert werden, und genau das wird der Organisation früher oder später teuer. Viertens würde ich beginnen, die Wirkung des Ausgelieferten zu messen und dem Management zu berichten. Nichts verändert Zusagekultur so verlässlich wie der Nachweis, dass ein erheblicher Teil des zugesagten Umfangs keine messbare Wirkung hatte. Die Haltung dabei: Ich stelle die Zusagen nicht als Fehler dar, sondern biete ein besseres Verfahren an. Und ich bringe das Thema über den Scrum Master auch als organisationales Impediment ein, weil es nicht allein durch mein Verhandeln zu lösen ist.

Musterantwort: Der Scrum Guide sieht den Product Owner als eine Person, nicht als Gremium, vor. Der Grund liegt in der Entscheidungsfähigkeit: Die Reihenfolge des Product Backlog ist eine fortlaufende Abwägung zwischen konkurrierenden, oft widersprüchlichen Interessen. Ein Gremium kann beraten, aber es entscheidet langsam, verhandelt Kompromisse statt Prioritäten und liefert dem Team keine eindeutige Antwort auf die Frage, was als Nächstes wichtig ist. Eine klar benannte Person ist ansprechbar, rechenschaftspflichtig und kann kurzfristig entscheiden, was in der empirischen Arbeitsweise unverzichtbar ist. Delegation ist dabei ausdrücklich erlaubt: Der Product Owner kann die Pflege von Einträgen, die Ausarbeitung von Akzeptanzkriterien oder die Marktbeobachtung an andere übergeben, etwa an Business Analysten oder Fachbereichsvertreter. Was nicht delegiert werden kann, ist die Rechenschaftspflicht. Er bleibt verantwortlich dafür, dass das Product Backlog transparent, verständlich und sinnvoll geordnet ist und dass das Product Goal klar formuliert ist. Damit dies funktioniert, muss die Organisation seine Entscheidungen respektieren: Wer ihn formal einsetzt, ihm aber die Entscheidungsbefugnis entzieht, erhält einen Anforderungsverwalter ohne Handlungsspielraum. Sichtbar wird eine solche Fehlkonstruktion typischerweise daran, dass Prioritäten in einem anderen Gremium festgelegt werden und der Product Owner sie lediglich weitergibt.

Musterantwort: Output ist das, was geliefert wurde, also Funktionen, Increments oder Releases. Outcome ist die Veränderung, die dadurch beim Nutzer oder im Geschäft eintritt, etwa dass eine Aufgabe schneller erledigt wird, weniger Supportanfragen entstehen oder mehr Nutzer einen Prozess abschließen. Die Unterscheidung ist zentral, weil Output leicht zu messen und leicht zu steigern ist, ohne dass Wert entsteht: Ein Team kann viele Funktionen liefern, die kaum genutzt werden. Ein Product Owner, der nach Output steuert, optimiert Beschäftigung; wer nach Outcome steuert, optimiert Wirkung und kann Dinge auch bewusst weglassen. Praktisch heißt das, vor der Umsetzung eine überprüfbare Wirkungsannahme zu formulieren, nach der Auslieferung an echten Nutzungsdaten zu prüfen und das Product Backlog daraufhin anzupassen. Damit schließt sich der empirische Regelkreis auf Produktebene, so wie Inspektion und Adaption ihn auf Sprintebene schließen.

Musterantwort: Die Konstellation deutet darauf hin, dass Output erzeugt, aber kein Outcome erreicht wird. Mögliche Ursachen liegen auf mehreren Ebenen. Erstens könnten die gelieferten Funktionen an den tatsächlichen Bedürfnissen vorbeigehen, weil die Priorisierung auf Stakeholder-Wünschen statt auf Nutzerbeobachtung beruht. Zweitens könnten die Funktionen zwar passen, aber unbekannt oder schwer auffindbar sein, was eher ein Einführungs- als ein Entwicklungsproblem wäre. Drittens könnten grundlegende Probleme mit Bedienbarkeit, Geschwindigkeit oder Verlässlichkeit den Nutzen jeder zusätzlichen Funktion überlagern. Viertens könnte der Markt oder die Zielgruppe falsch eingeschätzt sein. Mein Vorgehen würde damit beginnen, überhaupt eine belastbare Datengrundlage herzustellen: Nutzungsdaten je Funktion, Abbruchpunkte in den zentralen Abläufen, Supportanfragen und, ergänzend, direkte Gespräche mit Nutzern. Aus der Kombination von Zahlen und Gesprächen lässt sich meist eingrenzen, auf welcher der genannten Ebenen das Problem liegt. Anschließend würde ich die Arbeitsweise anpassen, indem für künftige Einträge vorab eine erwartete Wirkung mit Messgröße formuliert wird und nach der Auslieferung geprüft wird, ob sie eingetreten ist. Ebenso würde ich Kapazität dafür reservieren, wenig genutzte Funktionen zu verbessern oder zu entfernen, statt ausschließlich Neues zu bauen. Gegenüber den Stakeholdern würde ich die Diskussion bewusst von der Liefermenge auf die Wirkung verschieben und dafür das Sprint Review nutzen.

Musterantwort: Die Konstellation deutet darauf hin, dass Output erzeugt, aber kein Outcome erreicht wird. Mögliche Ursachen liegen auf mehreren Ebenen. Erstens könnten die gelieferten Funktionen an den tatsächlichen Bedürfnissen vorbeigehen, weil die Priorisierung auf Stakeholder-Wünschen statt auf Nutzerbeobachtung beruht. Zweitens könnten die Funktionen passen, aber unbekannt oder schwer auffindbar sein, was ein Einführungs- und kein Entwicklungsproblem wäre. Drittens könnten grundlegende Probleme mit Bedienbarkeit, Geschwindigkeit oder Verlässlichkeit den Nutzen jeder zusätzlichen Funktion überlagern. Viertens könnte die Zielgruppe falsch eingeschätzt sein. Mein Vorgehen würde damit beginnen, eine belastbare Datengrundlage herzustellen: Nutzungsdaten je Funktion, Abbruchpunkte in den zentralen Abläufen, Supportanfragen und ergänzend direkte Gespräche mit Nutzern. Aus der Kombination von Zahlen und Gesprächen lässt sich meist eingrenzen, auf welcher Ebene das Problem liegt. Anschließend würde ich die Arbeitsweise ändern, indem für künftige Einträge vorab eine erwartete Wirkung mit Messgröße formuliert und nach der Auslieferung überprüft wird. Ebenso würde ich Kapazität dafür reservieren, wenig genutzte Funktionen zu verbessern oder zu entfernen, statt ausschließlich Neues zu bauen. Gegenüber den Stakeholdern würde ich die Diskussion bewusst von der Liefermenge auf die Wirkung verschieben und dafür das Sprint Review nutzen.

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: Die Reihenfolge des Product Backlog soll den Wert maximieren, den das Produkt über die Zeit erzeugt. Der erwartete Nutzen ist dabei nur einer von mehreren Gesichtspunkten. Hinzu kommt der Aufwand beziehungsweise die Größe eines Eintrags, denn bei begrenzter Kapazität zählt nicht der absolute Wert, sondern das Verhältnis von Wert zu Aufwand; genau das bildet etwa WSJF ab. Weiterhin spielt Risiko eine Rolle: Ein Eintrag, der eine große technische oder fachliche Unsicherheit auflöst, kann es rechtfertigen, früh bearbeitet zu werden, auch wenn sein unmittelbarer Nutzen gering ist, weil er alle nachfolgenden Schätzungen zuverlässiger macht. Ebenso sind Abhängigkeiten zu berücksichtigen, weil manche Einträge Voraussetzung für andere sind, sowie zeitliche Bindungen wie gesetzliche Fristen, Marktzeitpunkte oder Messetermine. Schließlich beeinflussen Lerneffekte die Reihenfolge: Ein Eintrag, der Erkenntnisse über Nutzerverhalten liefert, kann die Priorisierung aller folgenden Einträge verbessern. Geschäftswert allein reicht deshalb nicht aus, weil er weder die Kosten der Erstellung noch die Unsicherheit noch die zeitliche Dringlichkeit abbildet. Eine Liste, die streng nach geschätztem Nutzen sortiert ist, führt typischerweise dazu, dass große und riskante Vorhaben vorne stehen, während kleine Einträge mit hervorragendem Kosten-Nutzen-Verhältnis liegenbleiben.

Musterantwort: Wertmaximierung entsteht nicht dadurch, möglichst viel zu liefern, sondern dadurch, das Richtige zu liefern. Da die Kapazität eines Teams begrenzt ist, bedeutet jede Zusage zugleich eine Absage an etwas anderes; wer nichts ablehnt, entscheidet lediglich implizit und meist zugunsten des durchsetzungsstärksten Stakeholders. Hinzu kommt, dass jede ausgelieferte Funktion dauerhaft Kosten verursacht: Sie muss gepflegt, getestet, dokumentiert und bei jeder Änderung mitgedacht werden. Ein Produkt mit vielen wenig genutzten Funktionen wird dadurch langsamer weiterzuentwickeln, nicht wertvoller. Gegenüber Stakeholdern trägt die Ablehnung am ehesten, wenn sie nicht als persönliche Entscheidung, sondern als nachvollziehbare Konsequenz dargestellt wird. Hilfreich ist, das Product Goal und die verwendeten Priorisierungskriterien offenzulegen, sodass erkennbar wird, woran gemessen wird. Ebenso wirksam ist es, die Ablehnung als Reihenfolgeentscheidung zu formulieren statt als endgültiges Nein, und den Preis der Alternative zu benennen: Welcher andere Eintrag müsste zurückstehen. Ein transparentes Backlog, ein regelmäßiges Sprint Review als Ort der gemeinsamen Abstimmung und das Aufzeigen von Daten zur tatsächlichen Nutzung stützen diese Gespräche zusätzlich. Wichtig ist schließlich Verlässlichkeit: Ein Nein, das begründet ist und Bestand hat, wird auf Dauer besser akzeptiert als ein Ja, das nicht eingehalten wird.

Musterantwort: Statt die Funktion vollständig umzusetzen oder sie abzulehnen, würde ich die Annahme explizit machen und sie günstig prüfen. Der erste Schritt ist, mit dem Auftraggeber die erwartete Wirkung zu formulieren: Welches Verhalten welcher Nutzergruppe soll sich ändern, und woran würde man erkennen, dass es funktioniert hat. Daraus entsteht eine überprüfbare Hypothese mit einem vorab festgelegten Erfolgskriterium – dieser Schritt ist entscheidend, weil sich sonst im Nachhinein jedes Ergebnis als Erfolg deuten lässt. Im zweiten Schritt suche ich die kleinste Variante, die diese Hypothese prüfen kann. Das kann ein Klickmodell oder ein Prototyp sein, eine stark reduzierte Fassung für einen begrenzten Nutzerkreis, ein A/B-Test gegen die bestehende Lösung oder auch eine manuelle Umsetzung im Hintergrund, um die Nachfrage zu messen, bevor etwas gebaut wird. Im dritten Schritt wird ausgeliefert und gemessen, und zwar am vorab definierten Kriterium. Bestätigt sich die Annahme, wird ausgebaut; bestätigt sie sich nicht, wird die Funktion verworfen oder neu gedacht – und zwar zu einem Bruchteil der Kosten der vollständigen Umsetzung. Dieses Vorgehen verschiebt die Diskussion von einem Meinungsstreit zwischen Product Owner und Stakeholder hin zu einer gemeinsamen Frage an die Nutzer, was die Zusammenarbeit meist erheblich entspannt.

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.