Product Discovery

Alle Prüfungsfragen Product Discovery
225 Fragen 183 Single 24 Multi 18 Offen

Allgemein

Discovery-Grundlagen [Discovery] 2 Unterseite →

☝️ Single Was ist der Zweck von Product Discovery?

✅ Die Unsicherheit über Problem, Lösung und Geschäftsmodell so weit zu senken, dass eine Investitionsentscheidung vertretbar wird

❌ Den Umfang eines Releases verbindlich festzulegen

❌ Die Anforderungen vollständig zu erheben, bevor die Umsetzung beginnt

❌ Die Akzeptanzkriterien der obersten Backlog-Einträge auszuarbeiten

Discovery beseitigt Unsicherheit nicht, sie senkt sie. Wird daraus eine vollständige Vorab-Erhebung, ist es Anforderungsanalyse unter neuem Namen, und der eigentliche Vorteil, nämlich frühes und billiges Irren, geht verloren.

☝️ Single Warum ist die Aussage "Wir haben die Anforderungen validiert" methodisch fragwürdig?

❌ Anforderungen dürfen in Scrum nicht verwendet werden

✅ Anforderungen sind bereits Lösungsbeschreibungen; validieren lassen sich Annahmen über Probleme, Verhalten und Wirkung

❌ Validierung ist grundsätzlich nur für technische Machbarkeit möglich

❌ Validierung setzt eine statistisch belastbare Stichprobe voraus

Wer Anforderungen validiert, prüft, ob die eigene Lösung gefällt, nicht ob das Problem existiert. Die validierbare Einheit ist die Annahme, und zwar in der Form: Wenn wir X liefern, erwarten wir bei Gruppe Y die Veränderung Z.

Annahmen [Discovery] 2 Unterseite →

☝️ Single Welche Annahme sollte bei einer neuen Produktidee zuerst überprüft werden?

❌ Diejenige, die der wichtigste Stakeholder benennt

❌ Diejenige, die das Team fachlich am meisten interessiert

❌ Diejenige, die sich am schnellsten überprüfen lässt

✅ Diejenige, deren Widerlegung das Vorhaben am stärksten gefährden würde und über die am wenigsten bekannt ist

Maßgeblich ist die Kombination aus Tragweite und Unwissen. Nur die schnellste Prüfung zuerst zu wählen fühlt sich produktiv an, lässt aber das eigentliche Risiko unberührt; die teuerste Annahme bleibt dann bis zuletzt unangetastet.

✍️ Offen Ein Unternehmen plant ein neues digitales Angebot und möchte zwölf Monate entwickeln, bevor es an den Markt geht. Entwickeln Sie ein Vorgehen, das die wesentlichen Annahmen deutlich früher prüft.

Musterantwort: Zuerst würde ich die Annahmen sichtbar machen, auf denen der Plan ruht, und sie nach zwei Größen ordnen: Wie sehr gefährdet eine Widerlegung das Vorhaben, und wie wenig wissen wir bislang darüber? Geprüft wird in der Reihenfolge dieses Produkts, nicht in der Reihenfolge der Bequemlichkeit. Typischerweise stehen vier Risikoarten im Raum: Wollen genügend Menschen das überhaupt, kommen sie damit zurecht, lässt es sich mit vertretbarem Aufwand bauen, und trägt es sich wirtschaftlich, rechtlich und betrieblich für uns. In den meisten gescheiterten Vorhaben war nicht die Umsetzbarkeit das Problem, sondern der Wert. Dann würde ich je Annahme das kleinste Experiment wählen, das eine belastbare Antwort liefert. Für die Wertfrage etwa ein echtes Angebot mit Zahlungsschritt statt einer Befragung; für den Ablauf eine manuell erbrachte Variante für die ersten Kunden; für die Nutzbarkeit einen Prototypentest mit Beobachtung statt Bewertung; für die Tragfähigkeit eine Durchrechnung mit den tatsächlich beobachteten Abschlussquoten. Jedes Experiment bekommt vorab eine benannte Zielgruppe, eine erwartete Verhaltensänderung und einen Schwellenwert, ab dem die Annahme als widerlegt gilt. Ohne diesen Schwellenwert lässt sich jedes Ergebnis nachträglich als Bestätigung deuten. Zeitlich schlage ich vor, den Zwölfmonatsplan durch Entscheidungspunkte zu ersetzen: nach etwa vier bis sechs Wochen eine belegte Entscheidung über Weiterführung, Richtungswechsel oder Abbruch, danach in ähnlichem Takt. Die Investitionsfreigabe erfolgt stufenweise, nicht in einer Summe. Dem Vorstand gegenüber würde ich die Rechnung offenlegen: Zwölf Monate Entwicklung binden die Mittel vollständig, bevor die erste belastbare Rückmeldung vorliegt. Der Vorschlag verringert nicht die Ambition, sondern die Höhe des Einsatzes, mit dem sie geprüft wird. Wichtig ist schließlich, den Abbruch ausdrücklich als zulässiges Ergebnis zu vereinbaren. Wo er nicht vorgesehen ist, wird aus Validierung eine Beschaffung von Rechtfertigungen.

Bewertet werden: Annahmen nach Tragweite und Unwissen ordnen + vier Risikoarten mit Schwerpunkt Wertrisiko + je Annahme kleinstes geeignetes Experiment mit Beispiel + Zielgruppe, Erwartung und Schwellenwert vorab + gestufte Investitionsfreigabe statt Zwölfmonatsplan + Abbruch als zulässiges Ergebnis.

Risikoarten [Discovery] 1 Unterseite →

✌️ Multi Welche Risikoarten sind bei der Produktvalidierung zu unterscheiden? (Mehrere richtig)

✅ Nutzbarkeitsrisiko: Können Nutzer damit umgehen?

✅ Umsetzbarkeitsrisiko: Lässt es sich mit vertretbarem Aufwand bauen?

❌ Schätzrisiko: Weicht der Aufwand von der Story-Point-Schätzung ab?

❌ Terminrisiko: Hält das Team die zugesagte Lieferwoche ein?

✅ Wertrisiko: Wollen Nutzer das Produkt überhaupt?

Die drei ersten Risikoarten werden üblicherweise um das Tragfähigkeitsrisiko ergänzt, also die Frage, ob die Lösung für das Unternehmen wirtschaftlich, rechtlich und betrieblich funktioniert. Schätz- und Terminabweichungen sind Ausführungsrisiken und betreffen nicht die Frage, ob das Richtige gebaut wird.

Experimente [Discovery] 2 Unterseite →

☝️ Single Ein Team baut eine voll funktionsfähige Version einer unsicheren Funktion, um sie zu validieren. Welcher Einwand ist am stärksten?

❌ Ohne Kontrollgruppe ist jede Validierung wertlos

❌ Die Validierung hätte vor dem Sprint Planning stattfinden müssen

❌ Funktionsfähige Software darf nicht für Experimente verwendet werden

✅ Der Aufwand steht in keinem Verhältnis zum Erkenntnisziel; ein Experiment sollte so klein sein, wie es für eine belastbare Antwort nötig ist

Der Maßstab ist nicht Vollständigkeit, sondern Aussagekraft je aufgewendeter Einheit. Oft genügt eine manuell bediente Variante, eine Vorschaltseite oder ein Angebot ohne dahinterliegende Umsetzung, um die entscheidende Frage zu beantworten.

☝️ Single Was kennzeichnet ein "Concierge"-Experiment?

❌ Ein Prototyp wird ausgewählten Nutzern zur Bewertung vorgelegt

❌ Eine Vorschaltseite bewirbt ein Produkt, das es noch nicht gibt

✅ Die Leistung wird für echte Kunden zunächst manuell erbracht, um Bedarf und Ablauf zu prüfen, bevor etwas automatisiert wird

❌ Zwei Varianten werden gleichzeitig an verschiedene Nutzergruppen ausgeliefert

Die manuelle Erbringung ist der Kern: Sie liefert echte Kundeninteraktion ohne Entwicklungsaufwand und deckt zugleich auf, wie der Ablauf tatsächlich aussieht. Die anderen drei beschreiben Vorschaltseite, A/B-Test und Prototypentest.

Evidenzqualität [Discovery] 2 Unterseite →

☝️ Single Welche Evidenz ist für die Frage, ob Nutzer für eine Leistung zahlen würden, am belastbarsten?

❌ Die Zahl der Anmeldungen auf einer Warteliste

❌ Die Angabe in einer Befragung, man würde dafür zahlen

❌ Die Zustimmung von Vertrieb und Marketing zur Preisannahme

✅ Ein tatsächlich abgeschlossener Kauf oder eine verbindliche Vorbestellung

Die Evidenzstärke steigt mit dem Einsatz, den eine Person tatsächlich erbringt. Eine Warteliste ist besser als eine Aussage, weil sie eine Handlung erfordert, bleibt aber deutlich schwächer als eine Zahlung.

✍️ Offen Erläutern Sie, warum Aussagen aus Kundeninterviews eine schwächere Evidenz darstellen als beobachtetes Verhalten, und wie sich Interviews dennoch nutzbringend einsetzen lassen.

Musterantwort: Aussagen sind schwächer, weil zwischen Absicht und Handlung mehrere Verzerrungen liegen. Menschen wollen höflich sein und bestätigen deshalb Ideen, besonders gegenüber demjenigen, der sichtbar daran hängt. Sie sagen ungern Unangenehmes und sagen eher zu, was sie für erwartet halten. Sie sagen ihr künftiges Verhalten schlecht voraus, weil im Gespräch die Kosten fehlen, die in der Realität anfallen: Zeit, Geld, Umgewöhnung. Und sie rationalisieren im Nachhinein, sodass auch Berichte über eigenes Verhalten geglättet sind. Suggestive Fragen und die Reihenfolge der Fragen verstärken all das. Beobachtetes Verhalten umgeht diese Schicht: Ein abgeschlossener Kauf, eine Anmeldung, ein tatsächlicher Abbruch an einer bestimmten Stelle sind Handlungen mit Einsatz. Nutzbringend bleiben Interviews trotzdem, wenn man ihre Stärke richtig ansetzt. Sie eignen sich schlecht für die Frage "Würden Sie", aber gut für die Frage "Wie sind Sie das letzte Mal vorgegangen". Rückblickende, konkrete Schilderungen erheben Verhalten, das bereits stattgefunden hat, einschließlich der Behelfslösungen, die jemand sich gebaut hat, und der Kosten, die er dafür in Kauf nimmt. Sie erklären außerdem das Warum hinter beobachteten Daten: Ein A/B-Test sagt, welche Variante besser abschneidet, aber nicht, weshalb. Praktisch heißt das: Interviews zur Problemerkundung und zur Deutung von Daten einsetzen, nicht zur Bestätigung von Lösungsideen; nach konkreten letzten Vorkommnissen fragen statt nach Einschätzungen; die eigene Lösung möglichst spät oder gar nicht zeigen; vorab notieren, welche Antwort die eigene Annahme widerlegen würde; und die Interviews von jemandem führen lassen, der kein Interesse an einem bestimmten Ergebnis hat.

Bewertet werden: mindestens drei Verzerrungsmechanismen (Höflichkeit, fehlende Kosten im Gespräch, schlechte Vorhersage eigenen Verhaltens, nachträgliche Rationalisierung, Suggestion) + Verhalten als Handlung mit Einsatz + sinnvoller Einsatz für Problemerkundung und Deutung von Daten + rückblickend-konkrete Fragetechnik + Widerlegungskriterium vorab.

Kundengespräche [Discovery] 1 Unterseite →

☝️ Single Welche Frage liefert in einem Kundeninterview die belastbarste Information?

❌ "Wie wichtig ist Ihnen dieses Problem auf einer Skala von eins bis zehn?"

✅ "Erzählen Sie mir, wie Sie das letzte Mal vorgegangen sind, als dieses Problem auftrat."

❌ "Was halten Sie von unserem Lösungsvorschlag?"

❌ "Würden Sie eine Funktion nutzen, die dieses Problem löst?"

Die Frage nach dem konkreten letzten Vorkommnis erhebt Verhalten statt Meinung. Die anderen drei erfragen hypothetische Zukunft oder Bewertungen und liefern systematisch zu positive Antworten, weil Menschen höflich sind und ihre künftigen Handlungen schlecht vorhersagen.

Discovery & Scrum [Discovery] 2 Unterseite →

☝️ Single Wie verhält sich Product Discovery zum Sprint?

✅ Discovery findet innerhalb der Sprints statt und konkurriert im selben Product Backlog um dieselbe Kapazität wie Umsetzungsarbeit

❌ Discovery ist von Scrum unabhängig und wird außerhalb der Sprints betrieben

❌ Discovery ersetzt das Product Backlog Refinement

❌ Discovery findet in einem vorgelagerten Sprint statt, bevor die Umsetzung beginnt

Getrennte Zeitstränge oder ein eigenes Discovery-Backlog erzeugen wieder eine Übergabe und zwei Prioritätslisten für dieselbe Kapazität. Sichtbarkeit im einen Backlog zwingt zur bewussten Abwägung zwischen Lernen und Liefern.

☝️ Single Welcher Anteil der Sprint-Kapazität sollte in Discovery fließen?

❌ Konstant etwa zwanzig Prozent, damit Discovery nicht vernachlässigt wird

✅ Das hängt von der Unsicherheit ab: Bei einem neuen Produkt deutlich mehr als bei einem ausgereiften in einem bekannten Markt

❌ Der Scrum Guide gibt hierfür einen Richtwert vor

❌ So wenig wie möglich, da Discovery keinen Increment-Beitrag leistet

Ein fester Anteil ist eine Faustregel, kein Prinzip. Der eigentliche Maßstab ist das Verhältnis der Kosten eines Irrtums zu den Kosten des Herausfindens: Wo Irren billig ist, ist Ausliefern die schnellere Erkenntnis.

Bestätigungsfehler [Discovery] 1 Unterseite →

☝️ Single Ein Team führt zehn Interviews und berichtet, alle Befragten hätten die Idee positiv aufgenommen. Welche methodische Vorsichtsmaßnahme hätte am meisten geholfen?

❌ Mehr Interviews zu führen, um eine belastbare Stichprobe zu erreichen

❌ Die Interviews von einer neutralen Stelle durchführen zu lassen

✅ Vorab festzulegen, welches Ergebnis die Idee widerlegen würde, und gezielt nach solchen Hinweisen zu suchen

❌ Die Interviews aufzuzeichnen und wörtlich zu protokollieren

Ohne vorab definiertes Widerlegungskriterium bestätigt jede Erhebung die eigene Erwartung, weil die Deutung offen bleibt. Mehr Interviews vervielfachen bei suggestiver Fragestellung nur den Bestätigungsfehler.

Validierung [Discovery] 2 Unterseite →

☝️ Single Ein Experiment zeigt ein Ergebnis knapp unterhalb des vorab festgelegten Schwellenwerts. Das Team schlägt vor, den Schwellenwert zu senken, da das Ergebnis "fast erreicht" wurde. Wie ist das zu bewerten?

✅ Unzulässig: Ein nachträglich angepasster Schwellenwert hebt den Erkenntniswert des Experiments auf; die Annahme gilt als nicht bestätigt

❌ Zulässig, wenn der Product Owner zustimmt

❌ Zulässig, wenn die Abweichung unter zehn Prozent liegt

❌ Zulässig, weil Schwellenwerte ohnehin geschätzt sind

Das nachträgliche Verschieben des Maßstabs ist der häufigste Weg, ein Experiment wertlos zu machen. Vertretbar ist stattdessen, das Ergebnis als nicht bestätigt zu werten und offen zu entscheiden: Abbruch, Anpassung der Lösung oder ein besser zugeschnittenes zweites Experiment.

✌️ Multi Welche Kennzeichen hat ein gut gestaltetes Produktexperiment? (Mehrere richtig)

✅ Ein vorab festgelegtes Kriterium, ab dem die Annahme als widerlegt gilt

✅ Der geringstmögliche Aufwand für eine belastbare Antwort

✅ Eine vorab formulierte Annahme mit benannter Zielgruppe

❌ Eine möglichst realitätsnahe, funktionsfähige Umsetzung

❌ Eine Laufzeit von mindestens einem vollen Sprint

Funktionsnähe ist kein Selbstzweck und oft der teuerste Weg zur selben Antwort. Eine Mindestlaufzeit gibt es nicht; die Dauer richtet sich danach, wann genügend Daten für eine Entscheidung vorliegen.

Problemverständnis [Discovery] 2 Unterseite →

☝️ Single Ein Stakeholder bringt eine konkrete Lösungsidee ins Backlog ein. Wie geht ein Product Owner in der Discovery angemessen damit um?

✅ Er fragt nach dem Problem und dem angestrebten Ergebnis hinter der Idee, damit Alternativen überhaupt beurteilbar werden

❌ Er leitet die Idee zur technischen Bewertung an die Developers weiter

❌ Er lehnt Lösungsvorschläge von Stakeholdern grundsätzlich ab

❌ Er nimmt die Idee als Anforderung auf, da der Stakeholder seinen Bedarf am besten kennt

Lösungsideen von Stakeholdern sind wertvoll, aber sie sind bereits eine Antwort auf eine unausgesprochene Frage. Ohne diese Frage lässt sich weder eine bessere Lösung finden noch der Nutzen beurteilen.

☝️ Single Ein Team stellt fest, dass Nutzer sich bereits mit einer Tabellenkalkulation selbst behelfen. Wie ist dieser Befund einzuordnen?

❌ Als Hinweis darauf, dass die Nutzer technisch nicht versiert genug sind

❌ Als Zeichen dafür, dass das Problem bereits gelöst ist und kein Bedarf besteht

✅ Als starkes Signal für echten Bedarf, weil Nutzer bereits Aufwand investieren, um das Problem zu lösen

❌ Als irrelevant, da Tabellenkalkulationen kein Wettbewerbsprodukt sind

Eine selbstgebaute Behelfslösung ist einer der verlässlichsten Bedarfsnachweise überhaupt: Jemand hat Zeit investiert, ohne dass ein Produkt ihn dazu aufgefordert hätte. Sie zeigt zugleich, welche Teilaufgabe wirklich zählt.

Ergebnisse [Discovery] 2 Unterseite →

☝️ Single Was ist das eigentliche Ergebnis eines Discovery-Vorhabens?

❌ Ein abgestimmtes Lastenheft für die Umsetzung

❌ Ein Prototyp, der den Stakeholdern vorgeführt werden kann

✅ Eine belegte Entscheidung, ob und wie weitergearbeitet wird, einschließlich der ausdrücklichen Option, das Vorhaben einzustellen

❌ Ein verfeinertes Product Backlog für die nächsten Sprints

Wenn das Einstellen nicht zu den möglichen Ergebnissen gehört, war es keine Validierung, sondern eine Rechtfertigung. Prototypen und verfeinerte Einträge sind Nebenprodukte, nicht das Ziel.

☝️ Single Nach drei Experimenten spricht die Evidenz gegen die ursprüngliche Produktidee. Das Team hat bereits vier Monate investiert. Was ist die angemessene Entscheidung?

❌ Weitermachen, um die Investition nicht zu verlieren

✅ Die Richtung anhand der Evidenz ändern oder das Vorhaben beenden; die bereits investierten vier Monate sind für die Entscheidung unerheblich

❌ Die Entscheidung dem wichtigsten Stakeholder überlassen

❌ Ein viertes Experiment ansetzen, bis ein positives Ergebnis vorliegt

Versunkene Kosten sind für die künftige Entscheidung ohne Bedeutung. Experimente so lange zu wiederholen, bis das gewünschte Ergebnis eintritt, verwandelt Validierung in Rechtfertigung.

Messung [Discovery] 1 Unterseite →

☝️ Single Eine Vorschaltseite für ein neues Angebot erzielt eine Anmeldequote von acht Prozent. Welche Zusatzinformation ist für die Deutung am wichtigsten?

✅ Woher die Besucher kamen und wie gezielt sie angesprochen wurden, da die Quote ohne Herkunft nicht interpretierbar ist

❌ Wie hoch die Quote vergleichbarer Angebote am Markt ist

❌ Wie lange die Seite online war

❌ Wie viele Besucher die Seite insgesamt hatte

Acht Prozent aus einer vorqualifizierten Empfängerliste bedeuten etwas völlig anderes als acht Prozent aus breit gestreuter Werbung. Die Gesamtzahl der Besucher ist zwar für die Belastbarkeit relevant, aber nachrangig gegenüber der Frage, wer da überhaupt geklickt hat.

Artefakte & Commitments

Artefakte [Artefakte] 5 Unterseite →

☝️ Single Welche drei Artefakte kennt Scrum und welche Commitments gehören dazu?

❌ Epics, Stories, Tasks

✅ Product Backlog (Product Goal), Sprint Backlog (Sprint Goal), Increment (Definition of Done)

❌ Backlog, Board, Burndown

❌ Vision, Roadmap, Release-Plan

Die drei Artefakte mit ihren Commitments: Product Backlog → Product Goal, Sprint Backlog → Sprint Goal, Increment → Definition of Done.

✍️ Offen Was sind die drei Commitments der Scrum-Artefakte und wozu dienen sie?

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.

Bewertet werden: die drei Artefakt-Commitment-Paare korrekt zugeordnet + Zweck (Transparenz/Fokus/Messbarkeit).

Merksatz: Drei Artefakte, drei Versprechen: Product Backlog → Product Goal, Sprint Backlog → Sprint Goal, Increment → Definition of Done. „PSI“ – wie die griechische Buchstabe, die Einheit des Drucks: Jedes Artefakt steht unter dem „Druck“ eines Commitments. Die drei Goals geben Richtung (Product), Fokus (Sprint) und Qualität (Done) – Transparenz durch Verbindlichkeit.

☝️ Single Welche drei Artefakte kennt Scrum?

❌ Product Backlog, Sprint Backlog, Burndown Chart

❌ Product Backlog, Definition of Done, Increment

✅ Product Backlog, Sprint Backlog, Increment

❌ Produktvision, Roadmap, Release-Plan

Die drei Artefakte sind Product Backlog, Sprint Backlog und Increment. Die Definition of Done ist kein Artefakt, sondern das Commitment zum Increment.

✍️ Offen Erklären Sie den Unterschied zwischen Definition of Done und Akzeptanzkriterien und begründen Sie, warum beide nebeneinander sinnvoll sind.

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.

Bewertet werden: DoD = teamweit und für alle Increments, Akzeptanzkriterien = pro Eintrag und fachlich + Notwendigkeit beider + Hinweis, dass nur die DoD ein Scrum-Element ist.

✍️ Offen Erklären Sie, wie Product Goal, Sprint-Ziel und Definition of Done zusammenwirken, und was fehlt, wenn eines davon nicht vorhanden ist.

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.

Merksatz: Drei Versprechen, eine Kette: Produktziel = Kompass (wohin?), Sprintziel = Etappenziel (was jetzt?), Definition of Done = Qualitätsboden (wann fertig?). Fehlt der Kompass, irrt das Team; fehlt das Etappenziel, zerfasert der Sprint in Aufgabenlisten; fehlt der Qualitätsboden, ist „fertig“ Auslegungssache. Merke: Ziel oben, Ziel jetzt, Boden unten – fehlt ein Glied, reißt die Kette.

Definition of Done [Artefakte] 9 Unterseite →

☝️ Single Was ist die Definition of Done?

❌ Die persönliche Meinung des Product Owners, wann etwas gut ist

❌ Eine Liste aller offenen Aufgaben

✅ Eine formale Beschreibung des Zustands, den ein Increment erfüllen muss, um als fertig zu gelten

❌ Das Sprint-Ziel

Die Definition of Done ist ein verbindliches Qualitäts-Commitment für das Increment: Nur was die DoD erfüllt, gilt als fertig und Teil des Increments.

✌️ Multi Welche Aussagen zur Definition of Done (DoD) treffen zu? (Mehrere richtig)

❌ Jeder Developer darf seine eigene DoD frei wählen

✅ Sie schafft Transparenz über den Zustand des Increments

❌ Die DoD ist optional und kann weggelassen werden

✅ Wenn eine Organisation eine DoD-Vorgabe hat, ist sie das Minimum

✅ Ein Increment muss die DoD erfüllen, um als fertig zu gelten

Die DoD schafft Transparenz, ist Voraussetzung für "fertig", und ein Organisationsstandard ist das Minimum. Sie gilt fürs ganze Team (nicht individuell) und ist verbindlich, nicht optional.

☝️ Single Worauf bezieht sich die Definition of Done?

❌ Das Kriterium für das Erreichen des Sprint-Ziels

✅ Eine formale Beschreibung des Qualitätszustands, den das Increment erfüllen muss

❌ Die Abnahmekriterien eines einzelnen Backlog-Eintrags

❌ Eine Checkliste, wann ein Backlog-Eintrag in den Sprint darf

Die DoD gilt für das Increment als Ganzes. Akzeptanzkriterien beziehen sich dagegen auf einzelne Einträge; eine "Definition of Ready" gibt es in Scrum nicht.

Merksatz: Die Definition of Done ist der Qualitäts-Stempel fürs ganze Increment – nicht fürs Sprint-Ziel, nicht für einzelne Einträge.

Warum die anderen falsch sind:

Sprint-Ziel: hat eigene Kriterien, nicht die DoD.

Einzelner Backlog-Eintrag: das sind Akzeptanzkriterien.

Sprint-Aufnahme: das regelt die Ready-Definition.

☝️ Single Wer erstellt die Definition of Done, wenn die Organisation keinen Standard vorgibt?

❌ Der Scrum Master

❌ Der Product Owner allein

✅ Das Scrum Team

❌ Die Qualitätssicherung

Existiert ein Organisationsstandard, muss er als Minimum eingehalten werden. Fehlt er, erstellt das Scrum Team eine eigene DoD.

☝️ Single Ein Organisationsstandard für die Definition of Done existiert. Darf ein Scrum Team strengere Kriterien festlegen?

❌ Nein, der Standard ist verbindlich und abschließend

✅ Ja – der Standard ist das Minimum, strengere Kriterien sind erlaubt

❌ Nur wenn alle Teams derselben Organisation zustimmen

❌ Nur mit Genehmigung des Managements

Der Organisationsstandard ist die Untergrenze. Ein Team darf sie verschärfen, aber nicht unterschreiten.

Merksatz: Die Definition of Done ist ein Mindeststandard – nach oben offen, nach unten dicht. Stell dir ein Fundament vor: Das Organisations-DoD ist der Boden, jedes Team darf höher bauen.

Warum die anderen falsch sind:

„Bindung und final" – verwechselt Mindeststandard mit Höchstgrenze.

„Alle Teams zustimmen" – DoD ist Team-Entscheidung, keine Konsensrunde.

„Management-Freigabe" – Scrum gibt dem Team Autonomie, nicht der Hierarchie.

☝️ Single Mehrere Scrum Teams arbeiten am selben Produkt. Was gilt für die Definition of Done?

✅ Sie müssen eine gemeinsame Definition of Done haben, damit ein integriertes Increment entstehen kann

❌ Die DoD wird pro Sprint neu ausgehandelt

❌ Jedes Team definiert seine eigene, unabhängige DoD

❌ Der Product Owner legt für jedes Team eine eigene DoD fest

Ohne gemeinsame DoD lässt sich die Arbeit mehrerer Teams nicht zu einem einheitlich fertigen Increment integrieren.

✍️ Offen Ein Product Owner bittet darum, die Definition of Done für einen wichtigen Kundentermin einmalig zu lockern. Bewerten Sie diese Bitte und beschreiben Sie tragfähige Alternativen.

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.

Merksatz: „Lieber weniger fertig als fertig weniger" – Umfang senken, nie die Done-Qualität. Die DoD ist das Qualitätssiegel: Wer sie für einen Termin aufweicht, tauscht Transparenz gegen unsichtbare Schulden.

Kern: DoD = Fertig-Definition, nicht Verhandlungsmasse. Termindruck löst man über Scope, nicht über Qualität.

Alternativen:

Umfang verkleinern, Rest voll nach DoD

Backlog neu priorisieren, Termin-Kern fokussieren

Termin halten mit reduziertem Umfang + offener Kommunikation

Increment als Vorabversion mit klaren Einschränkungen zeigen

Änderung der DoD: erlaubt – aber bewusst, sichtbar, vom ganzen Scrum Team, nie als stille Ausnahme.

☝️ Single Kann die Definition of Done während eines laufenden Sprints geändert werden?

❌ Nein, sie ist während des gesamten Produktlebenszyklus unveränderlich

❌ Ja, der Product Owner kann sie jederzeit anpassen

❌ Nein, nur die Organisation darf sie ändern

✅ Formal ja, aber es ist unüblich – üblicherweise wird sie in der Retrospektive angepasst und gilt ab dem nächsten Sprint

Eine Änderung mitten im Sprint macht die bereits geleistete Arbeit unvergleichbar. Ein Verschärfen für künftige Arbeit ist dagegen jederzeit möglich.

☝️ Single Die Organisation gibt eine Definition of Done vor. Ein Team stellt fest, dass es diese in der aktuellen Systemlandschaft nicht vollständig erfüllen kann. Was folgt daraus?

❌ Das Team definiert eine eigene, erreichbare Definition of Done und arbeitet danach

❌ Der Product Owner entscheidet, welche Punkte des Standards entfallen

✅ Das Team kann kein Increment liefern, das dem Standard entspricht; das ist ein Impediment, das transparent gemacht und beseitigt werden muss, nicht durch eine eigene, schwächere Definition ersetzt

❌ Das Team liefert das Increment und kennzeichnet die nicht erfüllten Punkte

Der Organisationsstandard ist die Untergrenze, nicht der Verhandlungsrahmen. Ein Team darf ihn verschärfen, aber nicht unterschreiten. Die Unfähigkeit, ihn zu erfüllen, ist die eigentliche Information und gehört sichtbar gemacht.

Merksatz: Organisations-DoD ist Pflicht, nicht Wunsch — fehlende Systemlandschaft ist ein Hindernis, kein Freibrief für eine eigene, weichere DoD.

Warum die anderen falsch sind:

Eigene DoD: unterläuft die Organisationsvorgabe.

PO entscheidet: PO besitzt keine Hoheit über die DoD.

Increment mit Lücken liefern: verletzt die DoD, kein „Increment“.

Product Backlog [Artefakte] 4 Unterseite →

☝️ Single Wer ist für den Inhalt und die Reihenfolge des Product Backlog verantwortlich?

❌ Die Developers

❌ Der Kunde direkt

✅ Der Product Owner

❌ Der Scrum Master

Der Product Owner verantwortet das Product Backlog: Inhalt, Verfügbarkeit und Reihenfolge. Andere können beitragen, aber die Verantwortung liegt allein beim PO.

☝️ Single Wie beschreibt der Scrum Guide das Product Backlog?

✅ Als geordnete, emergente Liste dessen, was zur Verbesserung des Produkts nötig ist – die einzige Arbeitsquelle des Scrum Teams

❌ Als Sammlung aller offenen Aufgaben aller Teams im Unternehmen

❌ Als Liste, die nach Aufwand sortiert ist

❌ Als vollständige, zu Projektbeginn fixierte Anforderungsspezifikation

Das Product Backlog ist emergent (es entwickelt sich fortlaufend), geordnet – nicht zwingend nach Aufwand – und die einzige Quelle der Arbeit für das Scrum Team.

☝️ Single Wer ordnet das Product Backlog?

❌ Die Developers

❌ Der Scrum Master

✅ Der Product Owner

❌ Die Stakeholder gemeinsam

Der Product Owner verantwortet die Ordnung. Er kann sich beraten lassen, entscheidet aber selbst; andere dürfen die Reihenfolge nicht überstimmen.

✌️ Multi Welche Eigenschaften sollte ein Product-Backlog-Eintrag erkennen lassen? (Mehrere richtig)

✅ Eine Reihenfolge im Verhältnis zu den übrigen Einträgen.

❌ Die Person, die den Eintrag umsetzen wird.

✅ Eine Beschreibung, die den Zweck verständlich macht.

✅ Eine Größenangabe sowie einen erkennbaren Wert.

Die Zuordnung zu Personen widerspricht der Selbstverwaltung: Wer woran arbeitet, entscheiden die Developers im Sprint – nicht das Backlog.

Merksatz: Jeder Backlog-Eintrag ist wie ein DHL-Paket: Reihenfolge (Priorität), Inhalt (Zweck verständlich), Gewicht & Wert (Größe + Nutzen) – aber nicht der Zusteller (wer es umsetzt).

Warum die anderen falsch sind:

„Person, die umsetzt" – Zuordnung erfolgt erst im Sprint, nicht im Backlog.

Increment [Artefakte] 7 Unterseite →

☝️ Single Wann entsteht ein Increment?

❌ Nur am Ende des Sprints

❌ Beim Sprint Planning

✅ Sobald ein Product-Backlog-Item die Definition of Done erfüllt

❌ Erst beim Release an den Kunden

Ein Increment entsteht, sobald ein Backlog-Item die Definition of Done erfüllt – das kann mehrmals pro Sprint passieren. Es muss nicht bis Sprint-Ende warten.

Merksatz: „Done ist der Geburtstag des Increments“ – jederzeit, sobald ein Item die Definition of Done erfüllt, wächst das Increment.

Warum die anderen falsch sind:

Nur am Sprintende: verwechselt Sprint-Review mit Entstehung.

Sprint Planning: da wird geplant, nicht geliefert.

Release: Auslieferung ≠ Fertigstellung; Increment existiert vorher.

☝️ Single Was ist ein Increment?

❌ Die Summe aller im Sprint begonnenen Aufgaben

❌ Die im Sprint Planning ausgewählte Arbeitsmenge

✅ Ein konkreter Schritt in Richtung Product Goal, der nutzbar ist und die Definition of Done erfüllt

❌ Ein Prototyp zur Demonstration im Sprint Review

Ein Increment ist additiv zu allen vorherigen Increments, verifiziert nutzbar und erfüllt zwingend die Definition of Done.

☝️ Single Wie viele Increments können in einem Sprint entstehen?

❌ Keines, wenn das Sprint-Ziel nicht erreicht wurde

❌ Genau eines, am Sprintende

❌ Höchstens eines pro Woche

✅ Mehrere – ein Increment kann geliefert werden, sobald es fertig ist

Mehrere Increments pro Sprint sind ausdrücklich möglich. Die Auslieferung darf nicht bis zum Sprint Review warten.

Merksatz: Increments sind wie Pizzen aus dem Ofen – jede fertige Pizza darf sofort raus, nicht erst alle zusammen am Sprintende.

Warum die anderen falsch sind:

Keines bei verfehltem Ziel: Sprint-Ziel und Increment sind entkoppelt.

Genau eines am Ende: verwechselt Increment mit Sprint-Ergebnis.

Höchstens eines pro Woche: erfundene Zeitregel, Scrum kennt keine Wochenquote.

☝️ Single Arbeit, die die Definition of Done nicht erfüllt – wie ist damit umzugehen?

✅ Sie gilt nicht als Teil des Increments, wird nicht präsentiert und geht zurück ins Product Backlog

❌ Sie kann übergeben werden, wenn der Product Owner zustimmt

❌ Sie wird ins nächste Sprint Backlog übernommen und dort weitergezählt

❌ Sie wird als "zu 90 % fertig" im Sprint Review gezeigt

Es gibt kein "fast fertig". Arbeit ohne erfüllte Definition of Done ist kein Increment und kehrt ins Product Backlog zurück.

✍️ Offen Erklären Sie den Unterschied zwischen "fertig" im Sinne der Definition of Done und "ausgeliefert", und warum diese Unterscheidung wichtig ist.

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.

☝️ Single Kann ein Increment ausgeliefert werden, bevor der Sprint endet?

❌ Nein, pro Sprint darf nur ein Increment entstehen

❌ Ja, aber nur mit Zustimmung des Scrum Masters

❌ Nein, eine Auslieferung ist erst nach dem Sprint Review möglich

✅ Ja – sobald Arbeit die Definition of Done erfüllt, kann sie ausgeliefert werden; darüber entscheidet der Product Owner

Der Sprint ist ein Takt für Inspektion und Adaption, keine Auslieferungssperre. Mehrere Increments je Sprint sind ausdrücklich möglich.

☝️ Single Ein Team liefert im Sprint ein Increment, das die Definition of Done erfüllt, aber nicht zum Sprint-Ziel beiträgt, weil das Ziel verfehlt wurde. Wie ist das einzuordnen?

❌ Es ist kein Increment, da es nicht zum Sprint-Ziel beiträgt

❌ Es darf im Sprint Review nicht gezeigt werden

❌ Es muss im nächsten Sprint erneut bearbeitet werden

✅ Es bleibt ein gültiges Increment; Definition of Done und Sprint-Ziel sind zwei verschiedene Commitments und werden unabhängig voneinander beurteilt

Die Definition of Done ist das Commitment zum Increment, das Sprint-Ziel das Commitment zum Sprint Backlog. Fertige Arbeit bleibt fertig, auch wenn das Ziel verfehlt wurde. Warum es verfehlt wurde, gehört in die Retrospektive.

Sprint-Ziel [Artefakte] 4 Unterseite →

☝️ Single Wann entsteht das Sprint-Ziel?

❌ Im Daily Scrum des ersten Sprinttags

❌ Vor dem Sprint Planning durch den Product Owner allein

❌ Erst im Sprint Review

✅ Im Sprint Planning – es wird vom gesamten Scrum Team erarbeitet

Das Sprint-Ziel entsteht gemeinsam im Sprint Planning und ist das Commitment zum Sprint Backlog.

☝️ Single Darf das Sprint-Ziel während des Sprints geändert werden?

❌ Ja, sobald sich Prioritäten ändern

❌ Ja, wenn die Developers zustimmen

❌ Ja, einmal pro Sprint

✅ Nein – das Sprint-Ziel bleibt bestehen; verhandelbar ist der Umfang

Das Sprint-Ziel gibt dem Sprint Kohärenz und Fokus. Ändert sich die Lage so stark, dass das Ziel sinnlos wird, kann der Product Owner den Sprint abbrechen.

Merksatz: Das Sprint-Ziel ist der Kompass, der Kurs bleibt – nur die Route (Scope) darf sich ändern.

Warum die anderen falsch sind:

Prioritäten ändern den Kurs, nicht das Ziel – Sprint-Ziel ist Stabilitätsanker.

Developers allein dürfen das Sprint-Ziel nicht kippen – es gehört dem Scrum Team.

„Einmal pro Sprint" erfindet eine Regel, die es nicht gibt.

Nur das Sprint-Ziel selbst ist fix; Scope verhandelbar mit Product Owner.

☝️ Single Was geschieht, wenn sich während des Sprints herausstellt, dass weniger Arbeit nötig ist als angenommen?

❌ Der Scrum Master weist zusätzliche Arbeit zu

❌ Der Sprint wird vorzeitig beendet

✅ Die Developers verhandeln mit dem Product Owner über den Umfang des Sprint Backlog und können weitere Einträge aufnehmen

❌ Die freie Kapazität bleibt ungenutzt, da der Umfang festgelegt wurde

Das Sprint Backlog ist ein lebender Plan, kein Vertrag. Verbindlich ist ausschließlich das Sprint-Ziel.

Merksatz: Das Sprint-Ziel ist der Anker – der Umfang darf sich bewegen. Weniger Arbeit? Dann verhandeln die Developers mit dem PO und ziehen Neues ins Sprint Backlog.

Warum die anderen falsch sind:

Scrum Master weist zu: Der SM ist Diener, kein Vorgesetzter – er verteilt keine Arbeit.

Sprint vorzeitig beenden: Nur der PO kann abbrechen, und nur bei obsoletem Sprint-Ziel.

Kapazität ungenutzt: Der Umfang ist flexibel, nicht in Stein gemeißelt.

☝️ Single Woran erkennt man ein gutes Sprint-Ziel?

❌ Es nennt die Anzahl der zu erreichenden Story Points

✅ Es beschreibt einen angestrebten Nutzen oder Zustand und lässt offen, über welche Einträge er erreicht wird

❌ Es listet alle im Sprint ausgewählten Backlog-Einträge auf

❌ Es wird vom Product Owner allein festgelegt

Ein Ziel, das nur die Einträge aufzählt, gibt keinen Handlungsspielraum: Fällt ein Eintrag weg, ist das Ziel automatisch verfehlt, obwohl der Nutzen vielleicht erreichbar wäre.

Commitments [Artefakte] 2 Unterseite →

☝️ Single Welches Commitment gehört zum Product Backlog?

❌ Das Sprint-Ziel

❌ Die Definition of Done

❌ Die Definition of Ready

✅ Das Product Goal

Product Backlog → Product Goal, Sprint Backlog → Sprint-Ziel, Increment → Definition of Done. Eine "Definition of Ready" kennt Scrum nicht.

Merksatz: Product Backlog → Product Goal. „Product“ steckt in beiden – das Ziel des Products steht im Backlog.

Warum die anderen falsch sind:

Sprint-Ziel: gehört zum Sprint Backlog, nicht zum Product Backlog.

Definition of Done: Commitment des Increments.

Definition of Ready: kein Scrum-Artefakt, nur gängige Praxis.

☝️ Single Wozu dienen die Commitments der Artefakte?

❌ Sie verpflichten das Team vertraglich zur Lieferung

✅ Sie schaffen Transparenz und einen Fokus, an dem der Fortschritt gemessen werden kann

❌ Sie ersetzen die Sprint-Planung

❌ Sie dienen dem Management zur Leistungskontrolle

Jedes Artefakt hat ein Commitment, das es fokussiert und messbar macht – ohne die Artefakte in Lieferzusagen zu verwandeln.

Refinement [Artefakte] 3 Unterseite →

☝️ Single Was ist Product Backlog Refinement?

❌ Eine einmalige Aufbereitung des gesamten Backlogs vor dem ersten Sprint

✅ Eine laufende Aktivität, bei der Einträge zerlegt, präzisiert und geschätzt werden – kein Event mit fester Timebox

❌ Die Aufgabe des Scrum Masters

❌ Ein Pflicht-Event am Anfang jedes Sprints

Refinement ist eine fortlaufende Aktivität ohne vorgeschriebene Timebox. Scrum schreibt weder Häufigkeit noch Format vor.

☝️ Single Wer schätzt die Größe von Product-Backlog-Einträgen?

✅ Die Developers, die die Arbeit ausführen werden

❌ Ein Schätzausschuss aus Fachexperten

❌ Der Product Owner

❌ Der Scrum Master

Die Größe schätzen ausschließlich die Developers. Der Product Owner kann sie beeinflussen, indem er Kompromisse aufzeigt – schätzen darf er nicht.

Merksatz: Wer die Arbeit tut, schätzt die Arbeit – die Developers schätzen, weil sie liefern.

Warum die anderen falsch sind:

Schätzausschuss: Scrum kennt keine separaten Expertengremien.

Product Owner: priorisiert, schätzt aber nicht selbst.

Scrum Master: coacht den Prozess, schätzt nicht inhaltlich.

☝️ Single Ein Team hält jeden Dienstag ein zweistündiges Refinement-Meeting ab und bezeichnet es als fünftes Scrum-Event. Wie ist das zu bewerten?

✅ Ein fester Termin ist unproblematisch, die Bezeichnung als Event nicht: Refinement ist eine laufende Aktivität ohne vorgeschriebene Timebox und ohne definiertes Ergebnis

❌ Ein fester Termin widerspricht dem Scrum Guide und muss entfallen

❌ Refinement darf ausschließlich im Sprint Planning stattfinden

❌ Das ist korrekt, Refinement ist seit 2020 ein eigenständiges Event

Der Unterschied ist nicht bloß begrifflich: Ein Event hat einen definierten Zweck, ein Ergebnis und eine Timebox. Refinement als Event zu behandeln führt dazu, dass Klärungsbedarf bis Dienstag aufgestaut wird, statt dann zu entstehen, wenn er auftritt.

Product Goal [Artefakte] 4 Unterseite →

☝️ Single Was beschreibt das Product Goal?

✅ Den zukünftigen Zustand des Produkts, der als langfristiges Ziel dient

❌ Die Summe aller Sprint-Ziele eines Quartals

❌ Die Vision der Organisation

❌ Den Umfang des nächsten Sprints

Das Product Goal ist das langfristige Ziel des Scrum Teams und befindet sich im Product Backlog.

☝️ Single Wie viele Product Goals verfolgt ein Scrum Team gleichzeitig?

❌ So viele, wie das Backlog hergibt

❌ Eines pro Sprint

✅ Genau eines – es muss erfüllt oder verworfen werden, bevor das nächste begonnen wird

❌ Eines pro Stakeholder-Gruppe

Ein Scrum Team fokussiert auf ein Product Goal. Erst wenn es erreicht oder aufgegeben wurde, wird das nächste angegangen.

Merksatz: Ein Nordstern, ein Ziel: Das Product Goal ist der eine Leuchtturm – erst erreichen oder aufgeben, dann den nächsten ansteuern.

Warum die anderen falsch sind:

Backlog-Menge: Das Backlog ist Mittel, nicht Ziel – es definiert keine Zielanzahl.

Pro Sprint: Das Product Goal überdauert mehrere Sprints, nicht sprintgebunden.

Pro Stakeholder: Stakeholder haben Wünsche, aber nur ein gemeinsames Produktziel.

☝️ Single Ein Team hat sein Product Goal erreicht. Was geschieht als Nächstes?

❌ Das Team arbeitet ohne Product Goal weiter, bis ein neues genehmigt wird

❌ Das Produkt gilt als abgeschlossen und das Team wird aufgelöst

✅ Der Product Owner formuliert ein neues Product Goal; das Product Backlog wird darauf ausgerichtet

❌ Das bisherige Product Goal bleibt bestehen, bis das Budget endet

Ein Scrum Team verfolgt genau ein Product Goal zur Zeit. Es muss erreicht oder verworfen sein, bevor das nächste an seine Stelle tritt.

Merksatz: Ziel erreicht? PO setzt neues Ziel – das Backlog folgt dem Kompass.

Warum die anderen falsch sind:

Ohne Product Goal: Scrum verlangt immer ein Ziel, kein zielloses Treiben.

Produkt abgeschlossen: Product Goal ist Etappenziel, nicht Endstation.

Altes Ziel bis Budgetende: Ziele sind nicht statisch, sondern werden erneuert.

☝️ Single Ein Scrum Team arbeitet an zwei Produkten mit je eigenem Backlog und wechselt je nach Dringlichkeit. Welche Aussage trifft zu?

❌ Das ist zulässig, solange jedes Produkt einen eigenen Product Owner hat

❌ Das ist zulässig, solange je Sprint nur an einem Produkt gearbeitet wird

❌ Das ist zulässig, solange beide Backlogs geordnet sind

✅ Das widerspricht der Ausrichtung auf ein Product Goal; das Team kann nicht gleichzeitig zwei langfristige Ziele verfolgen

Ein Scrum Team fokussiert auf ein Product Goal. Zwei Produkte bedeuten zwei Ziele, zwei Stakeholder-Kreise und laufenden Kontextwechsel. Eigene Product Owner verschärfen das Problem sogar, weil dann zwei Personen um dieselbe Kapazität konkurrieren.

Sprint Backlog [Artefakte] 3 Unterseite →

☝️ Single Woraus besteht das Sprint Backlog?

❌ Ausschließlich aus den ausgewählten Product-Backlog-Einträgen

✅ Sprint-Ziel (warum), ausgewählte Backlog-Einträge (was) und dem Plan zur Umsetzung (wie)

❌ Aus dem Sprint-Ziel und dem Burndown Chart

❌ Aus allen Aufgaben, die im Sprint anfallen könnten

Das Sprint Backlog ist Warum + Was + Wie. Es gehört allein den Developers und wird während des Sprints laufend aktualisiert.

☝️ Single Wem gehört das Sprint Backlog?

✅ Den Developers

❌ Dem Product Owner

❌ Dem Scrum Master

❌ Dem gesamten Scrum Team gemeinsam

Das Sprint Backlog ist ein Plan von und für die Developers. Nur sie ändern es – auch während des Sprints.

Merksatz: Das Sprint Backlog ist der Bauplan der Handwerker – es gehört allein den Developers, denn nur sie bauen das Increment.

Warum die anderen falsch sind:

Product Owner: verwaltet das Product Backlog, nicht das Sprint-Backlog.

Scrum Master: coacht den Prozess, besitzt aber kein Artefakt.

Gesamtes Team: „gemeinsam" klingt gut, doch das Sprint Backlog ist exklusiv Eigentum der Developers.

☝️ Single Darf sich das Sprint Backlog während des Sprints ändern?

❌ Nein, es ist nach dem Sprint Planning eingefroren

❌ Nur wenn der Scrum Master es freigibt

✅ Ja – es wird laufend aktualisiert, wenn die Developers mehr lernen

❌ Nur mit Zustimmung des Product Owners

Das Sprint Backlog ist ein hochsichtbares Echtzeitbild der Arbeit. Es ändert sich, sobald neue Erkenntnisse vorliegen – solange das Sprint-Ziel bestehen bleibt.

Transparenz [Artefakte] 1 Unterseite →

✌️ Multi Welche Situationen untergraben die Transparenz der Artefakte? (Mehrere richtig)

✅ Eine Definition of Done, die je nach Termindruck unterschiedlich ausgelegt wird

❌ Ein Increment, das vor dem Sprint Review ausgeliefert wird

❌ Ein Product Backlog, dessen Einträge unterschiedlich detailliert sind

✅ Ein Sprint Backlog, das nicht aktualisiert wird

✅ Ein Product Backlog, das nur der Product Owner kennt

Unterschiedliche Detailtiefe im Backlog ist normal (oben fein, unten grob), und früh auszuliefern ist erwünscht. Die anderen drei Punkte zerstören dagegen die Aussagekraft der Artefakte.

Merksatz: Transparenz stirbt durch drei W: Willkür (DoD), Winterschlaf (Sprint Backlog) und Wissensmonopol (Backlog nur beim PO).

Warum die anderen falsch sind:

Frühe Auslieferung: fördert sogar Feedback, kein Transparenzproblem.

Ungleiche Detaillierung: normal im Backlog, kein Verstoß.

Das Scrum-Team & Rollen

Scrum-Team [Rollen] 16 Unterseite →

☝️ Single Aus welchen Verantwortlichkeiten besteht ein Scrum-Team nach dem Scrum Guide 2020?

❌ Product Owner, Scrum Master, Projektleiter

❌ Product Owner, Team Lead, Stakeholder

✅ Product Owner, Scrum Master, Developers

❌ Scrum Master, Developers, Tester, Architekt

Das Scrum-Team besteht aus einem Product Owner, einem Scrum Master und den Developers. Es gibt keine weiteren Rollen und keine Sub-Teams oder Hierarchien.

☝️ Single Wie groß sollte ein Scrum-Team laut Scrum Guide 2020 typischerweise sein?

❌ Genau 7 Personen

❌ Unbegrenzt, je größer desto besser

✅ Klein genug, um agil zu bleiben, meist 10 oder weniger Personen

❌ Mindestens 15 Personen

Der Scrum Guide 2020 nennt "typischerweise 10 oder weniger" Personen. Klein genug für Agilität, groß genug, um im Sprint bedeutende Arbeit zu leisten.

✌️ Multi Welche Merkmale beschreiben das Scrum-Team nach dem Scrum Guide 2020? (Mehrere richtig)

❌ Es wird von einem Teamleiter geführt

✅ Es ist cross-funktional

✅ Es umfasst typischerweise 10 oder weniger Personen

✅ Es hat keine Sub-Teams oder Hierarchien

✅ Es ist selbstverwaltend

Das Scrum-Team ist cross-funktional, selbstverwaltend, ohne Sub-Teams/Hierarchien und typischerweise ≤10 Personen. Einen Teamleiter gibt es nicht.

☝️ Single Wie groß sollte ein Scrum Team typischerweise sein?

❌ Mindestens 12 Personen

✅ 10 Personen oder weniger

❌ Genau 7 plus/minus 2 Personen

❌ Zwischen 15 und 20 Personen

Der Scrum Guide 2020 nennt "typischerweise 10 oder weniger" Personen. Die früher verbreitete Formel 7±2 steht nicht mehr im Guide.

☝️ Single Wie viele Verantwortlichkeiten (Accountabilities) kennt Scrum?

❌ Zwei: Scrum Master und Entwicklungsteam

❌ Vier: Product Owner, Scrum Master, Developers, Stakeholder

✅ Drei: Product Owner, Scrum Master, Developers

❌ Fünf: zusätzlich Projektleiter und Architekt

Scrum kennt genau drei Verantwortlichkeiten. Stakeholder sind wichtig, gehören aber nicht zum Scrum Team.

☝️ Single Der Scrum Guide 2020 spricht nicht mehr von "Rollen", sondern von Accountabilities. Was ist die Absicht dahinter?

❌ Rollen dürfen jetzt beliebig getauscht werden

❌ Accountabilities sind formale Positionen in der Organisationshierarchie

❌ Die Begriffe wurden nur sprachlich modernisiert, inhaltlich ändert sich nichts

✅ Es geht um Verantwortlichkeiten im Team, nicht um Stellenbeschreibungen oder Hierarchiestufen

Der Begriffswechsel betont, dass es um Rechenschaftspflicht innerhalb eines Teams geht – nicht um Jobtitel. Eine Person kann Accountability tragen und trotzdem operativ mitarbeiten.

Merksatz: Accountability = Verantwortung, nicht Visitenkarte. Der Scrum Guide 2020 ersetzt „Rolle" durch „Accountability", um zu betonen: Es geht um übernommene Verantwortung im Team, nicht um Titel, Stellen oder Hierarchie.

Warum die anderen falsch sind:

Rollen tauschen: Verwechsle Verantwortung nicht mit Beliebigkeit.

Hierarchie: Accountabilities sind gerade KEINE Organigramm-Positionen.

Nur Kosmetik: Der Wechsel ist bewusst inhaltlich gewollt.

☝️ Single Was gilt für Sub-Teams innerhalb eines Scrum Teams?

❌ Sub-Teams sind ab acht Personen vorgeschrieben

❌ Sub-Teams sind erlaubt, solange jedes ein eigenes Sprint-Ziel hat

❌ Der Scrum Master bildet Sub-Teams nach Fachgebieten

✅ Es gibt keine Sub-Teams und keine Hierarchien innerhalb des Scrum Teams

Ein Scrum Team ist eine geschlossene Einheit ohne Sub-Teams und ohne interne Hierarchien, die alle auf ein Product Goal fokussiert ist.

☝️ Single Was bedeutet "cross-funktional" bezogen auf ein Scrum Team?

❌ Das Team arbeitet in mehreren Abteilungen gleichzeitig

❌ Das Team wechselt seine Zusammensetzung in jedem Sprint

❌ Jedes Teammitglied beherrscht jede Aufgabe gleich gut

✅ Das Team verfügt über alle Fähigkeiten, die nötig sind, um in jedem Sprint Wert zu schaffen

Cross-funktional heißt: die nötigen Fähigkeiten sind im Team vorhanden, nicht dass jeder alles kann. Externe Übergaben je Sprint wären ein Zeichen fehlender Cross-Funktionalität.

Merksatz: Cross-functional = alle Skills im Team, um jeden Sprint Wert zu liefern. Denk an ein Schweizer Taschenmesser: Ein Team, alle Werkzeuge drin.

Warum die anderen falsch sind:

Mehrere Abteilungen gleichzeitig: verwechselt mit Matrixorganisation, nicht Skillbreite.

Zusammensetzung wechselt: das wäre Instabilität, nicht Cross-Funktionalität.

Alle gleich gut: T-Shape, nicht Gleichheit – Generalisten mit Spezialisierung.

☝️ Single Kann eine Person gleichzeitig Scrum Master und Developer in demselben Team sein?

❌ Nur wenn das Team kleiner als fünf Personen ist

✅ Ja, das ist möglich, birgt aber Zielkonflikte, weil beide Verantwortlichkeiten volle Aufmerksamkeit brauchen

❌ Ja, das ist der empfohlene Normalfall

❌ Nein, der Scrum Guide verbietet das ausdrücklich

Der Guide verbietet es nicht. In der Praxis leidet aber meist eine der beiden Verantwortlichkeiten – vor allem, wenn Lieferdruck entsteht.

☝️ Single Wie viele Product Owner hat ein Scrum Team?

❌ So viele, wie das Team für sinnvoll hält

✅ Genau einen – eine Person, kein Gremium

❌ Einen pro Produktbereich

❌ Zwei, damit Vertretung gesichert ist

Der Product Owner ist eine Person. Er kann Backlog-Arbeit delegieren, bleibt aber allein rechenschaftspflichtig. Ein Ausschuss als PO widerspricht Scrum.

☝️ Single Wer ist im Scrum Team für die Qualität des Produkts verantwortlich?

❌ Der Product Owner, weil er das Increment abnimmt

❌ Ausschließlich eine dedizierte QA-Abteilung

❌ Der Scrum Master

✅ Das gesamte Scrum Team, wobei die Developers die Einhaltung der Definition of Done sicherstellen

Qualität ist Teamsache. Die Developers verpflichten sich der Definition of Done; eine externe Abnahmeinstanz ist in Scrum nicht vorgesehen.

☝️ Single Ein Manager möchte den Developers direkt Aufgaben zuweisen. Was ist die scrum-konforme Reaktion?

❌ Die Zuweisung akzeptieren, da Manager weisungsbefugt sind

✅ Transparent machen, dass Arbeitszuweisung die Selbstverwaltung untergräbt, und den Bedarf über den Product Owner ins Backlog führen

❌ Den Sprint abbrechen

❌ Den Manager aus allen Scrum-Events ausschließen

Bedürfnisse von außen sind legitim – sie gehören aber über den Product Owner ins Product Backlog, nicht als Direktauftrag an einzelne Developers.

✌️ Multi Welche Aussagen über das Scrum Team sind korrekt? (Mehrere richtig)

❌ Es besteht aus mehreren Sub-Teams mit eigenen Zielen

✅ Es trägt gemeinsam die Verantwortung, in jedem Sprint ein wertvolles, nutzbares Increment zu schaffen

✅ Es ist cross-funktional und selbstverwaltend

✅ Es ist auf jeweils ein Product Goal fokussiert

❌ Es wird vom Scrum Master geleitet

Ein Product Goal, keine Sub-Teams, keine Leitung durch den Scrum Master – der Scrum Master führt im Dienst, ohne Weisungsbefugnis.

Merksatz: Ein Team, ein Ziel, eine Verantwortung – cross-funktional, selbstverwaltend, auf ein Product Goal ausgerichtet, liefert gemeinsam jedes Increment.

Warum die anderen falsch sind:

Sub-Teams mit eigenen Zielen: widerspricht dem einen fokussierten Team.

Scrum Master leitet: er dient/dient coachend, führt aber nicht das Team.

✍️ Offen Ein Scrum Team ist auf 14 Personen angewachsen. Die Daily Scrums dauern 30 Minuten, Entscheidungen ziehen sich hin. Beschreiben Sie das Problem und mögliche Vorgehensweisen.

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.

Bewertet werden: Bezug zur Größenorientierung (10 oder weniger) + Kommunikationsaufwand als Ursache + Aufteilung durch das Team selbst + Schnitt nach Wert statt nach Fachdisziplin + gemeinsames Product Backlog/PO/DoD bei einem Produkt.

Merksatz: „10 ist die Wohlfühlgrenze – 14 sprengt sie. Teile nach Wert, nicht nach Fach: ein Backlog, ein PO, ein DoD, ein Increment."

Kernpunkte:

Zu groß → Kommunikationswege explodieren (n·(n-1)/2), Daily wird lang, Entscheidungen zäh.

Lösung: Team selbst teilen lassen (Selbstverwaltung).

Schnitt nach Produktbereich/Wertstrom/Nutzer – nie nach Disziplin.

Jedes neue Team bleibt cross-funktional und liefert eigenständig.

Bei einem Produkt: EIN Backlog, EIN PO, gemeinsame DoD, integriertes Increment.

Skalierung (Nexus) erst bei dauerhaft mehreren Teams.

☝️ Single Ein Scrum Team hat keinen Product Owner, der Scrum Master übernimmt die Priorisierung mit. Wie ist das zu bewerten?

❌ Unproblematisch, wenn der Scrum Master fachlich qualifiziert ist

✅ Es ist kein Scrum mehr: Die Verantwortlichkeiten sind bewusst getrennt, weil sonst niemand die Entscheidungen des anderen hinterfragt

❌ Zulässig als Übergangslösung für maximal drei Sprints

❌ Unproblematisch, solange das Team liefert

Die Trennung ist kein Formalismus: Der Scrum Master soll auch den Product Owner hinterfragen können. In Personalunion entfällt genau dieses Korrektiv.

☝️ Single Ein Product Owner ist zugleich Linienvorgesetzter der Developers seines Scrum Teams. Welche Wirkung ist die gravierendste?

❌ Der Product Owner darf dann nicht mehr über die Reihenfolge des Backlogs entscheiden

✅ Die Developers können Umfang und Machbarkeit nicht mehr frei verhandeln, weil Widerspruch arbeitsrechtliche Folgen haben kann

❌ Das Team überschreitet die zulässige Zahl von Verantwortlichkeiten

❌ Der Scrum Master verliert seine Zuständigkeit für die Wirksamkeit des Teams

Der Scrum Guide verbietet die Kombination nicht, aber sie hebt faktisch die Selbstverwaltung auf. Die Verhandlung über Umfang im Sprint setzt voraus, dass ein Nein folgenlos bleibt. Genau das ist hier nicht mehr gesichert.

Selbstverwaltung [Rollen] 4 Unterseite →

☝️ Single Was bedeutet "selbstverwaltend" (self-managing) für ein Scrum-Team?

❌ Der Product Owner verteilt die Tasks

❌ Ein Manager weist die Aufgaben zu

✅ Das Team entscheidet selbst, wer was wann und wie tut

❌ Der Scrum Master plant die Arbeit der Developers

Selbstverwaltung heißt: Das Team entscheidet intern, wer woran wie arbeitet. Weder Scrum Master noch Product Owner noch externe Manager verteilen die Aufgaben.

☝️ Single Was bedeutet "selbstverwaltend" (self-managing) im Scrum Guide 2020?

❌ Das Team braucht keinerlei Führung mehr

❌ Das Team entscheidet auch über Budget und Personalentscheidungen

✅ Das Team entscheidet intern, wer was wann und wie macht

❌ Der Scrum Master verteilt die Arbeit nach Kompetenz

Selbstverwaltung betrifft das Wer/Was/Wann/Wie der eigenen Arbeit. 2020 wurde der Begriff von "selbstorganisierend" zu "selbstverwaltend" geschärft, weil er das ganze Scrum Team umfasst.

☝️ Single Warum verteilt in Scrum niemand von außen die Aufgaben im Sprint?

❌ Weil dadurch die Velocity steigt

❌ Weil Aufgabenverteilung im Scrum Guide verboten ist

❌ Weil der Scrum Master dafür keine Zeit hat

✅ Weil die Developers als Fachleute am besten beurteilen können, wie die Arbeit erledigt wird

Selbstverwaltung beruht auf der Annahme, dass die Ausführenden die besten Entscheidungen über ihre Arbeit treffen. Fremdzuweisung nimmt Verantwortung und Motivation.

☝️ Single Welche Entscheidung liegt NICHT in der Selbstverwaltung des Scrum Teams?

❌ Die Wahl der technischen Umsetzung eines Backlog-Eintrags

❌ Die Entscheidung, wie das Daily Scrum strukturiert wird

❌ Die Verteilung der Arbeit innerhalb des Sprints

✅ Die Festlegung, welches Produkt entwickelt wird und welches Budget dafür zur Verfügung steht

Selbstverwaltung bezieht sich auf das Wer, Was, Wann und Wie der eigenen Arbeit, nicht auf Produktstrategie und Mittelzuweisung. Diese Grenze zu kennen ist wichtig, weil überzogene Erwartungen an Selbstverwaltung regelmäßig zu Enttäuschungen führen.

Developers [Rollen] 4 Unterseite →

✌️ Multi Wofür sind die Developers im Scrum-Team verantwortlich? (Mehrere richtig)

✅ Sich gegenseitig als Fachleute zur Rechenschaft ziehen

❌ Die Reihenfolge des Product Backlog festlegen

✅ Qualität durch Einhalten der Definition of Done

✅ Einen Plan für den Sprint erstellen (Sprint Backlog)

❌ Stakeholder-Erwartungen final entscheiden

Developers erstellen das Sprint Backlog, sichern Qualität (Definition of Done) und halten sich gegenseitig verantwortlich. Die Backlog-Reihenfolge verantwortet der Product Owner.

Merksatz: „Devs bauen, planen, prüfen – PO sortiert, Stakeholder entscheiden nie." Die Developers sind Handwerker UND Team: Sie erstellen den Sprint-Plan, halten die Definition of Done ein und ziehen sich gegenseitig zur Rechenschaft.

Warum die anderen falsch sind:

Backlog-Reihenfolge = alleinige Aufgabe des Product Owners.

Stakeholder-Erwartungen final entscheiden = Product Owner bzw. Stakeholder selbst, nicht die Developers.

✌️ Multi Wofür sind die Developers laut Scrum Guide verantwortlich? (Mehrere richtig)

✅ Den Plan für den Sprint zu erstellen (Sprint Backlog)

✅ Qualität durch Einhaltung der Definition of Done sicherzustellen

❌ Die Reihenfolge des Product Backlogs festzulegen

✅ Den Plan täglich in Richtung Sprint-Ziel anzupassen

❌ Die Stakeholder-Kommunikation zu verantworten

Backlog-Reihenfolge und Stakeholder-Verantwortung liegen beim Product Owner. Die Developers verantworten Sprint Backlog, Qualität und die tägliche Anpassung.

Merksatz: Die Developers sind die "Macher der DoD": Sie planen den Sprint, halten die Qualität und justieren täglich Richtung Ziel.

Warum die anderen falsch sind:

Product-Backlog-Reihenfolge = Aufgabe des Product Owners

Stakeholder-Kommunikation = PO-Aufgabe, nicht der Developers

☝️ Single Wer gilt in Scrum als "Developer"?

❌ Nur Personen mit einem Entwickler-Arbeitsvertrag

✅ Jede Person im Scrum Team, die an einem nutzbaren Increment arbeitet – unabhängig von Fachgebiet

❌ Nur Personen, die programmieren

❌ Alle Teammitglieder außer Testern und Designern

Der Begriff ist bewusst weit gefasst: Tester, UX-Designer, Analysten, Techniker – wer zum Increment beiträgt, ist Developer im Sinne von Scrum.

☝️ Single Wie viele Developers muss ein Scrum Team mindestens haben?

❌ Mindestens sieben

✅ Der Scrum Guide nennt keine Mindestzahl, das Team muss aber groß genug sein, um pro Sprint Wert zu liefern

❌ Mindestens fünf

❌ Mindestens drei

Die früheren Grenzen 3–9 für das Development Team wurden 2020 entfernt. Maßgeblich ist die Gesamtgröße des Scrum Teams (typischerweise 10 oder weniger).

Stakeholder [Rollen] 2 Unterseite →

☝️ Single Wie ist das Verhältnis zwischen Scrum Team und Stakeholdern?

❌ Stakeholder dürfen an keinem Scrum-Event teilnehmen

❌ Stakeholder kommunizieren ausschließlich mit dem Scrum Master

❌ Stakeholder sind Teil des Scrum Teams

✅ Stakeholder gehören nicht zum Scrum Team, werden aber aktiv einbezogen – vor allem im Sprint Review

Stakeholder stehen außerhalb des Scrum Teams. Das Sprint Review ist die formale Gelegenheit zur gemeinsamen Inspektion und Zusammenarbeit.

☝️ Single Ein Stakeholder möchte während des Sprints direkt mit den Developers sprechen. Wie ist das zu bewerten?

❌ Jeder Kontakt zwischen Stakeholdern und Developers ist zu unterbinden

❌ Der Kontakt ist nur im Sprint Review zulässig

✅ Direkter Austausch ist erwünscht; problematisch wird es erst, wenn daraus Arbeitsaufträge am Product Owner vorbei entstehen

❌ Der Scrum Master muss bei jedem Gespräch anwesend sein

Scrum schirmt die Developers nicht ab. Geschützt wird das Sprint-Ziel, nicht die Erreichbarkeit der Menschen.

Merksatz: Stakeholder dürfen reden – nur nicht heimlich steuern. Kontakt ja, Auftrag nein: Der PO hält die Richtung, die Developers den Austausch.

Warum die anderen falsch sind:

Totalverbot: Scrum fördert Transparenz, keine Abschottung.

Nur im Review: Austausch ist jederzeit erlaubt, nicht terminlich begrenzt.

SM-Pflicht: Der SM moderiert, ist aber kein Türsteher.

Die 5 Scrum-Werte

Scrum-Werte [Werte] 13 Unterseite →

☝️ Single Wie viele Scrum-Werte nennt der Scrum Guide, und welche sind es?

✅ Fünf: Commitment, Fokus, Offenheit, Respekt, Mut

❌ Fünf: Planung, Kontrolle, Qualität, Zeit, Kosten

❌ Vier: Individuen, Zusammenarbeit, Software, Reaktion

❌ Drei: Transparenz, Inspektion, Adaption

Die fünf Scrum-Werte sind Commitment, Fokus, Offenheit, Respekt und Mut. Transparenz/Inspektion/Adaption sind die drei Säulen (nicht die Werte).

☝️ Single Ein Teammitglied macht ein Hindernis im Daily transparent, obwohl es unangenehm ist. Welcher Scrum-Wert zeigt sich hier am deutlichsten?

❌ Respekt allein

❌ Commitment allein

❌ Fokus

✅ Mut (und Offenheit)

Ein unangenehmes Hindernis offen anzusprechen zeigt vor allem Mut und Offenheit. Diese Werte ermöglichen die Transparenz, die Scrum braucht.

✍️ Offen Nennen Sie die fünf Scrum-Werte und erläutern Sie einen davon an einem Beispiel.

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.)

Bewertet werden: alle fünf Werte korrekt benannt + ein Wert nachvollziehbar an einem Beispiel erläutert.

Merksatz: „CORF-M“ – Commitment, Offenheit, Respekt, Fokus, Mut. Bild: Ein Chef mit Ohren, Rücken, Fernrohr und Megafon. Reihenfolge egal – Hauptsache fünf Werte plus ein konkretes Beispiel.

Beispiel-Anker: Mut = unbequeme Wahrheit im Daily sagen. Commitment = Sprint-Ziel halten. Fokus = nur Sprint-Ziel. Offenheit = Blocker zeigen. Respekt = Meinung achten.

☝️ Single Welche fünf Werte nennt der Scrum Guide?

❌ Vertrauen, Ehrlichkeit, Disziplin, Offenheit, Respekt

❌ Commitment, Qualität, Tempo, Offenheit, Mut

✅ Commitment, Fokus, Offenheit, Respekt, Mut

❌ Transparenz, Inspektion, Adaption, Fokus, Mut

Die fünf Werte sind Commitment (Selbstverpflichtung), Fokus, Offenheit, Respekt und Mut. Transparenz/Inspektion/Adaption sind dagegen die drei Säulen der Empirie.

Merksatz: „COFReMu" – Commitment, Offenheit, Fokus, Respekt, Mut. Bild: Ein Team hält Fokus und Respekt, öffnet sich ehrlich, zeigt Mut und committet sich – fünf Finger einer Hand.

Warum die anderen falsch sind:

Vertrauen/Ehrlichkeit/Disziplin: klingen edel, stehen aber nicht im Guide.

Qualität/Tempo: sind Ergebnisse, keine Werte.

Transparenz/Inspektion/Adaption: das sind die drei Säulen der Empirie, keine Werte.

☝️ Single Ein Developer merkt, dass eine vom Team gewählte technische Lösung in eine Sackgasse führt, spricht es aber nicht an, um niemanden zu verärgern. Welcher Scrum-Wert fehlt hier am deutlichsten?

❌ Respekt

❌ Commitment

❌ Fokus

✅ Mut

Mut bedeutet, das Richtige zu tun und schwierige Themen anzusprechen. Schweigen aus Konfliktscheu untergräbt zugleich die Transparenz.

☝️ Single Das Team nimmt zusätzlich zum Sprint-Ziel laufend Sonderwünsche aus der Linie an. Welcher Wert wird verletzt?

✅ Fokus

❌ Respekt

❌ Mut

❌ Offenheit

Fokus bedeutet, die Arbeit auf das Sprint-Ziel zu konzentrieren. Ständige Nebenaufgaben zerstören den Fokus und gefährden das Ziel.

☝️ Single Wie wirken die Scrum-Werte mit den drei Säulen der Empirie zusammen?

✅ Gelebte Werte machen Transparenz, Inspektion und Adaption überhaupt erst wirksam

❌ Die Werte sind eine unverbindliche Empfehlung ohne Bezug zur Empirie

❌ Die Werte gelten nur für den Scrum Master

❌ Die Werte ersetzen die Säulen in reifen Teams

Ohne Offenheit gibt es keine echte Transparenz, ohne Mut keine ehrliche Inspektion, ohne Commitment und Fokus keine konsequente Adaption.

☝️ Single Worauf bezieht sich der Wert "Commitment" im Scrum Guide 2020?

✅ Auf die Selbstverpflichtung zu den Zielen des Teams und zur gegenseitigen Unterstützung

❌ Auf die Einhaltung von Terminzusagen gegenüber dem Management

❌ Auf die vertragliche Bindung an das Product Backlog

❌ Auf die Zusage, alle im Sprint Planning ausgewählten Backlog-Einträge garantiert zu liefern

Committed wird auf Ziele und aufeinander – nicht auf eine garantierte Menge an Backlog-Einträgen. Der Umfang bleibt im Sprint verhandelbar, das Sprint-Ziel nicht.

✌️ Multi Welche Verhaltensweisen zeigen den Wert "Offenheit"? (Mehrere richtig)

❌ Probleme erst nennen, wenn eine Lösung bereitliegt

✅ Impediments und Fehleinschätzungen frühzeitig ansprechen

✅ Den tatsächlichen Stand der Arbeit ungeschönt zeigen

✅ Offen für Feedback von Stakeholdern sein

❌ Schätzungen bewusst höher ansetzen, um Puffer zu sichern

Offenheit heißt, Arbeit und Herausforderungen sichtbar zu machen. Verdeckte Puffer und zurückgehaltene Probleme sind das Gegenteil.

☝️ Single Ein Teammitglied unterbricht andere regelmäßig und wertet deren Vorschläge ab. Welcher Wert ist am unmittelbarsten betroffen?

❌ Fokus

✅ Respekt

❌ Commitment

❌ Offenheit

Respekt bedeutet, einander als fähige, eigenständige Menschen zu behandeln. Ohne Respekt entsteht keine Sicherheit für Offenheit und Mut.

✍️ Offen Ein Team behauptet, "die Scrum-Werte" zu leben, verschiebt aber regelmäßig unfertige Arbeit in den nächsten Sprint und meldet den Sprint trotzdem als erfolgreich. Analysieren Sie, welche Werte hier tatsächlich verletzt werden.

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.

Bewertet werden: Offenheit und Mut als Kern + Folge für Transparenz/Empirie + Aushöhlung des Commitments + Hinweis auf organisationale Ursachen oder Retrospektive als Ansatzpunkt.

☝️ Single Ein Team meldet ein Problem erst, als es nicht mehr zu verbergen ist. Welche Werte fehlen hier am deutlichsten?

❌ Fokus und Commitment

❌ Respekt und Fokus

✅ Offenheit und Mut

❌ Commitment und Respekt

Die Werte sind keine Dekoration: Ohne Offenheit und Mut entsteht keine Transparenz, und ohne Transparenz laufen Inspektion und Adaption ins Leere.

☝️ Single Ein Team einigt sich in der Retrospektive schnell und ohne Widerspruch auf eine Maßnahme, die niemand umsetzt. Welcher Wert fehlt am wahrscheinlichsten bereits in der Retrospektive selbst?

✅ Mut: Die Zustimmung war vermutlich Konfliktvermeidung, nicht Überzeugung

❌ Fokus: Das Team hat zu viele Themen gleichzeitig behandelt

❌ Respekt: Die Beiträge einzelner wurden übergangen

❌ Commitment: Das Team hat sich nicht ausreichend auf die Maßnahme verpflichtet

Commitment ist das sichtbare Symptom, nicht die Ursache. Schnelle, widerspruchsfreie Einigkeit bei anschließender Untätigkeit deutet auf unausgesprochene Vorbehalte hin. Die wirksame Intervention setzt deshalb in der Retrospektive an, nicht bei der Nachverfolgung.

Merksatz: Schnelle Einigkeit ohne Widerspruch = fehlender Mut. Wer nicht widerspricht, stimmt nicht zu, sondern weicht aus. Courage heißt: unbequeme Wahrheit sagen.

Warum die anderen falsch sind:

Focus: Thema ist Themenmenge, nicht Konfliktvermeidung.

Respect: Hier geht's um Übergangenwerden, nicht um Zustimmung.

Commitment: Fehlt erst bei der Umsetzung, nicht in der Retro selbst.

Praxis & Prüfungsfallen

Anti-Pattern [Praxis] 3 Unterseite →

☝️ Single Ein Team plant vor dem ersten Sprint einen "Sprint Zero" für Architektur und Setup. Wie ist das zu bewerten?

❌ Sprint Zero ist erlaubt, wenn er kürzer als eine Woche ist

❌ Sprint Zero ist im Scrum Guide als Vorbereitungssprint vorgesehen

❌ Sprint Zero ist Pflicht bei neuen Produkten

✅ "Sprint Zero" ist kein Scrum-Element – auch der erste Sprint muss ein nutzbares Increment liefern

Jeder Sprint – auch der erste – erzeugt ein nutzbares Increment. Setup-Arbeit wird als Teil regulärer Sprints erledigt.

Merksatz: Kein „Sprint Zero“ – der erste Sprint zählt wie jeder andere: Am Ende steht ein nutzbares Increment, nicht nur Setup.

Warum die anderen falsch sind:

Kürzer als eine Woche – Länge heilt kein Anti-Pattern.

Im Guide vorgesehen – Sprint Zero existiert dort nicht.

Pflicht bei neuen Produkten – Scrum kennt keine Pflicht-Vorbereitungssprints.

☝️ Single Wie ist ein separater "Hardening Sprint" zur Fehlerbehebung am Ende einer Release zu bewerten?

✅ Als Symptom einer zu schwachen Definition of Done – jeder Sprint sollte bereits ein potenziell auslieferbares Increment liefern

❌ Als bewährte Praxis vor jedem Release

❌ Als Pflicht bei sicherheitskritischen Produkten

❌ Als scrum-konform, solange er kürzer ist als ein regulärer Sprint

Ein Hardening Sprint zeigt an, dass die Arbeit in den vorherigen Sprints nicht wirklich fertig war. Die Lösung liegt in einer strengeren DoD, nicht in einem Zusatzsprint.

✌️ Multi Welche Muster deuten auf ein Scrum in Namen, aber nicht in der Sache hin? (Mehrere richtig)

✅ Der Product Owner darf die Reihenfolge des Backlogs nicht selbst bestimmen.

✅ Am Sprint-Ende liegt regelmäßig kein fertiges Increment vor.

❌ Das Team passt seine Arbeitsweise in der Retrospektive an.

✅ Das Daily Scrum wird als Statusbericht an eine Führungskraft geführt.

Alle drei Muster haben dieselbe Wurzel: Die Form wurde übernommen, die Entscheidungsbefugnis nicht verlagert.

Metriken [Praxis] 3 Unterseite →

☝️ Single Wie sollte mit der Velocity umgegangen werden?

❌ Als verbindliche Zusage gegenüber dem Management

✅ Als teaminterne Planungshilfe – nicht als Leistungsmaß und nicht zum Vergleich zwischen Teams

❌ Als zentrale Kennzahl zur Bewertung der Teamleistung

❌ Als vom Scrum Guide vorgeschriebene Pflichtmetrik

Velocity kommt im Scrum Guide gar nicht vor. Als Ziel eingesetzt führt sie zu Schätz-Inflation und Qualitätsverlust.

☝️ Single Welche Aussage zur Messung des Fortschritts trifft zu?

✅ Scrum schreibt keine bestimmte Prognosetechnik vor; entscheidend bleibt die empirische Überprüfung an realer Arbeit

❌ Fortschritt wird ausschließlich im Sprint Review gemessen

❌ Der Fortschritt wird über die Zahl abgeschlossener Story Points gemessen

❌ Burndown Charts sind in Scrum verpflichtend

Burndown, Burnup und Cumulative Flow sind hilfreiche Praktiken, ersetzen aber nicht die Inspektion des tatsächlichen Increments.

☝️ Single Ein Team hat über acht Sprints eine stark schwankende Velocity. Wie ist das zu deuten?

❌ Als Zeichen für zu lange Sprints

❌ Als Beleg mangelnder Disziplin im Team

✅ Als Hinweis auf uneinheitliche Zuschnitte, wechselnde Verfügbarkeiten oder viele Störungen – nicht als Leistungsproblem

❌ Als normales Verhalten ohne Aussagewert

Die Schwankung selbst ist die interessante Information: Sie macht Prognosen unmöglich, und ihre Ursache ist fast immer außerhalb der Arbeitsleistung zu finden.

Merksatz: Velocity ist ein Wetterbericht, kein Zeugnis – schwankt sie stark, ändern sich Rahmenbedingungen (Schnitt, Verfügbarkeit, Störungen), nicht der Mensch.

Warum die anderen falsch sind:

Zu lange Sprints: Sprintlänge erklärt keine Schwankung, nur das Zeitfenster.

Mangelnde Disziplin: Velocity misst Umfang, nicht Fleiß – typischer Kausalitätsfehler.

Ohne Aussagewert: Schwankung ist ein Signal, kein Rauschen – wegsehen ist der Fehler.

Praxis [Praxis] 7 Unterseite →

☝️ Single Was bedeutet "potenziell auslieferbar"?

❌ Das Increment ist automatisch beim Kunden im Einsatz

❌ Das Increment wartet noch auf die Freigabe durch die Qualitätssicherung

❌ Das Increment ist ein Prototyp für die Demo

✅ Das Increment ist so fertig, dass es ausgeliefert werden könnte – ob es ausgeliefert wird, entscheidet der Product Owner

Fertigstellung und Auslieferungsentscheidung sind zwei verschiedene Dinge: Die technische Auslieferbarkeit verantwortet das Team, den Auslieferungszeitpunkt der Product Owner.

☝️ Single Ein Team führt Scrum ein und möchte zunächst nur die Events übernehmen, ohne Product Owner. Was ist die Konsequenz?

❌ Das Team entscheidet die Reihenfolge künftig per Abstimmung – das ersetzt den PO

❌ Der Scrum Master übernimmt dauerhaft die PO-Verantwortung

❌ Das ist ein sinnvoller erster Schritt und voll scrum-konform

✅ Ohne Product Owner fehlt die klare Verantwortung für Wert und Backlog-Ordnung – das Ergebnis ist nicht Scrum

Die Events ohne die Verantwortlichkeiten zu übernehmen ("Mechanical Scrum") erzeugt Meetings ohne empirische Steuerung.

☝️ Single Wie geht Scrum mit Fehlern (Bugs) am bestehenden Produkt um?

❌ Sie werden außerhalb des Backlogs in einem separaten Fehlerprozess bearbeitet

✅ Sie werden als Product-Backlog-Einträge geführt und vom Product Owner eingeordnet

❌ Sie werden gesammelt und im Hardening Sprint behoben

❌ Sie werden immer sofort und unabhängig vom Sprint-Ziel behoben

Alles, was am Produkt zu tun ist, läuft über das Product Backlog – das ist die einzige Quelle der Arbeit. Dringlichkeit bildet der PO über die Reihenfolge ab.

✍️ Offen Ein Unternehmen hat Scrum eingeführt: Es gibt Sprints, Dailys und Reviews, aber Entscheidungen über Inhalte trifft weiterhin ein Lenkungsausschuss, und die Developers werden nach Auslastung gesteuert. Analysieren Sie, was hier fehlt.

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.

Merksatz: Events ohne Macht = Theater. Der Lenkungsausschuss klaut dem PO das Backlog, die Auslastungssteuerung klaut den Developers die Selbstverwaltung. Scrum lebt von zwei Säulen: eine Stimme entscheidet (PO), das Team organisiert sich selbst. Fehlen sie, bleiben Dailys und Reviews leere Rituale – Form ohne Fundament.

Kategorie: Praxis [Praxis]

☝️ Single Ein Team arbeitet mit einwöchigen Sprints. Wie lang darf das Sprint Planning maximal dauern?

❌ Es gibt keine Timebox bei kurzen Sprints

❌ Unverändert acht Stunden

✅ Anteilig kürzer als die acht Stunden bei einem Monatssprint, typischerweise etwa zwei Stunden

❌ Maximal 15 Minuten wie das Daily Scrum

Der Scrum Guide nennt Maximalwerte für den Monatssprint; bei kürzeren Sprints sind die Events üblicherweise kürzer. Es sind Obergrenzen, keine Sollzeiten.

☝️ Single Wie geht ein Scrum Team mit Arbeit um, die am Sprint-Ende nicht fertig geworden ist?

✅ Sie kehrt ins Product Backlog zurück und wird vom Product Owner neu bewertet und eingeordnet

❌ Sie wird gelöscht, da sie ihre Gelegenheit hatte

❌ Sie wandert automatisch in den nächsten Sprint

❌ Sie wird als teilweise fertig im Increment ausgewiesen

Der Automatismus ist der häufigste Fehler: Die Rückgabe ins Product Backlog stellt sicher, dass die Arbeit erneut gegen alles andere abgewogen wird – vielleicht ist sie inzwischen nicht mehr die wichtigste.

☝️ Single Was unterscheidet ein Impediment von einem normalen Problem im Sprint?

✅ Ein Impediment behindert den Fortschritt des Teams und kann von ihm nicht ohne Weiteres selbst beseitigt werden

❌ Ein Impediment ist immer technischer Natur

❌ Ein Impediment betrifft ausschließlich externe Beteiligte

❌ Ein Impediment dauert länger als einen Sprint

Die Grenze verläuft an der Selbstwirksamkeit. Ein Scrum Master, der jedes Problem übernimmt, erzeugt ein Team, das keines mehr selbst löst.

Skalierung [Praxis] 4 Unterseite →

☝️ Single Mehrere Scrum Teams arbeiten am selben Produkt. Was gilt für Product Backlog und Product Owner?

✅ Ein Produkt hat ein Product Backlog, ein Product Goal und einen Product Owner

❌ Jedes Team führt ein eigenes Product Backlog mit eigenem Product Owner

❌ Jedes Team hat ein eigenes Product Goal

❌ Das Backlog wird pro Team kopiert und synchronisiert

Auch bei mehreren Teams bleibt es bei einem Product Backlog, einem Product Goal und einem Product Owner. Jedes Team hat aber ein eigenes Sprint-Ziel und Sprint Backlog.

Merksatz: Ein Produkt = ein Backlog, ein Goal, ein Owner – wie ein Steuerrad für ein Schiff, egal wie viele Ruderer.

Warum die anderen falsch sind:

Eigenes Backlog pro Team: widerspricht „ein Produkt, eine Quelle“.

Eigenes Product Goal pro Team: zersplittert das eine Produktziel.

Backlog kopieren/synchronisieren: erzeugt Duplikate statt einer Wahrheit.

☝️ Single Was bleibt bei mehreren Scrum Teams an einem Produkt gemeinsam?

❌ Nichts – jedes Team arbeitet vollständig eigenständig

❌ Nur die Definition of Done, alles Weitere wird je Team geführt

❌ Nur das Product Goal, jedes Team hat ein eigenes Backlog

✅ Ein Product Backlog, ein Product Owner, ein Product Goal und eine gemeinsame Definition of Done

Das ist der Kern jeder Skalierung mit Scrum. Sobald jedes Team ein eigenes Backlog und einen eigenen Product Owner bekommt, entstehen faktisch mehrere Produkte und die gemeinsame Priorisierung geht verloren.

☝️ Single Was ist der grundsätzliche Unterschied zwischen Nexus und LeSS?

❌ Nexus ersetzt Scrum, LeSS ergänzt es

❌ Nexus ist für Software, LeSS ausschließlich für Hardware

❌ Beide sind Methoden des klassischen Projektmanagements

✅ Beide sind Skalierungsrahmen auf Scrum-Basis: Nexus ergänzt Scrum um ein Integrationsteam und zusätzliche Events, LeSS setzt auf möglichst wenige Zusatzregeln und starke Vereinfachung der Organisation

Die Gemeinsamkeit ist wichtiger als der Unterschied: Beide halten am einen Product Backlog und am einen Product Owner fest und wachsen von Scrum aus nach oben, statt einen eigenen Prozess darüberzulegen.

☝️ Single Eine Organisation möchte Scrum auf zwölf Teams skalieren, obwohl ein einzelnes Team die Grundlagen noch nicht beherrscht. Was ist die naheliegende Empfehlung?

❌ Ein Skalierungsrahmen ersetzt die fehlenden Grundlagen

❌ Sofort skalieren, weil größere Strukturen die Probleme einzelner Teams ausgleichen

✅ Zuerst Scrum auf Teamebene wirksam machen – Skalierung vervielfältigt bestehende Probleme, sie löst sie nicht

❌ Zusätzliche Scrum Master einsetzen und ansonsten wie geplant vorgehen

Skalierung ist ein Verstärker. Fehlende Definition of Done, unklare Product Ownership und Restarbeit am Sprint-Ende werden bei zwölf Teams nicht kleiner, sondern zwölfmal so teuer.

Schätzung & Prognose [Praxis] 8 Unterseite →

☝️ Single Wer schätzt in Scrum den Aufwand bzw. die Größe von Product-Backlog-Einträgen?

✅ Die Developers – sie führen die Arbeit aus und verantworten daher die Schätzung

❌ Der Product Owner, da er die Reihenfolge festlegt

❌ Die Stakeholder gemeinsam im Sprint Review

❌ Der Scrum Master als neutraler Moderator

Der Scrum Guide ist hier eindeutig: Die Developers schätzen. Der Product Owner kann die Developers beeinflussen, indem er hilft, Kompromisse zu verstehen und Alternativen zu wählen – aber die Schätzung selbst bleibt bei den Developers.

☝️ Single Was sind Story Points?

❌ Ein vom Scrum Guide vorgeschriebenes Schätzverfahren

❌ Die Anzahl der Akzeptanzkriterien eines Eintrags

❌ Eine feste Umrechnung: ein Story Point entspricht einem Personentag

✅ Ein relatives Maß für Größe und Komplexität eines Eintrags im Vergleich zu anderen Einträgen – keine Zeiteinheit

Story Points sind eine verbreitete Praktik, aber kein Scrum-Bestandteil – der Scrum Guide schreibt kein Schätzverfahren vor. Ihr Vorteil liegt im Vergleich: Menschen schätzen relative Größen zuverlässiger als absolute Dauern.

Merksatz: Story Points sind wie Kleidergrößen: relativ, vergleichend, ohne Zentimeter – S, M, L statt Stunden.

Warum die anderen falsch sind:

Nicht vorgeschrieben – Scrum lässt die Methode offen.

Akzeptanzkriterien messen Fertigstellung, nicht Größe.

Keine Zeitumrechnung – Punkte ≠ Personentage.

☝️ Single Was ist der Kerngedanke von Planning Poker?

❌ Der Mittelwert aller genannten Zahlen ist automatisch das Ergebnis

✅ Alle Schätzenden legen ihre Einschätzung gleichzeitig offen, und Abweichungen werden als Anlass für ein klärendes Gespräch genutzt

❌ Der Product Owner nennt die Zahl, das Team prüft sie

❌ Die erfahrenste Person schätzt, die anderen bestätigen

Der Wert liegt nicht in der Zahl, sondern im Gespräch. Weit auseinanderliegende Schätzungen sind der eigentliche Gewinn: Sie decken auf, dass die Beteiligten den Eintrag unterschiedlich verstehen.

☝️ Single Warum wird bei Story Points häufig eine Fibonacci-ähnliche Reihe verwendet?

❌ Weil die Fibonacci-Reihe eine mathematisch exakte Aufwandsberechnung erlaubt

❌ Weil der Scrum Guide sie vorschreibt

✅ Weil die Unsicherheit mit der Größe wächst und größere Einträge deshalb nicht mehr fein unterschieden werden sollten

❌ Weil die Zahlen sich leichter addieren lassen

Die wachsenden Abstände bilden die reale Schätzunsicherheit ab. Ob ein großer Eintrag 19 oder 21 Punkte hat, ist eine Scheingenauigkeit; die eigentliche Konsequenz lautet: zu groß, muss zerlegt werden.

Merksatz: Je größer der Berg, desto nebliger der Gipfel – bei großen Storys verschwimmt der Unterschied zwischen 21 und 34, also grob bleiben.

Warum die anderen falsch sind:

Exakte Berechnung: Story Points sind relativ, nicht mathematisch exakt.

Scrum Guide: schreibt keine Schätzskala vor.

Leichter addieren: Addition ist kein Zweck von Story Points.

☝️ Single Was ist Velocity und wofür darf sie verwendet werden?

❌ Ein im Scrum Guide vorgeschriebenes Artefakt

❌ Eine Leistungskennzahl, mit der Teams miteinander verglichen werden

❌ Eine Zielvorgabe, die von Sprint zu Sprint gesteigert werden muss

✅ Die durchschnittlich pro Sprint fertiggestellte Menge eines Teams – nutzbar als grobe Prognosehilfe für genau dieses Team

Velocity kommt im Scrum Guide nicht vor. Als teaminterne Prognosehilfe ist sie brauchbar; als Zielvorgabe zerstört sie sich selbst, weil Teams dann einfach großzügiger schätzen.

☝️ Single Was zeigt ein Burn-up-Chart im Unterschied zu einem Burn-down-Chart?

✅ Es zeigt die fertiggestellte Arbeit UND den Gesamtumfang als eigene Linie, wodurch Umfangsänderungen sichtbar werden

❌ Es zeigt die Auslastung der einzelnen Teammitglieder

❌ Es zeigt ausschließlich die verbleibende Restarbeit

❌ Es zeigt die Anzahl der offenen Fehler im Produkt

Genau das ist der praktische Vorteil: Im Burn-down sieht eine Umfangserweiterung wie ein stehengebliebener Fortschritt aus. Im Burn-up hebt sich stattdessen sichtbar die obere Linie.

✌️ Multi Welche Aussagen zum Umgang mit Prognosen in Scrum treffen zu? (Mehrere richtig)

❌ Die Developers verpflichten sich verbindlich, alle ausgewählten Einträge fertigzustellen.

✅ Eine Prognose ist eine Aussage unter Unsicherheit und wird mit jedem Sprint genauer.

✅ Die Auswahl der Einträge für den Sprint ist eine Prognose der Developers, keine Garantie.

✅ Das einzige verbindliche Commitment im Sprint ist das Sprint-Ziel.

Der Scrum Guide 2011 ersetzte das Wort "Commitment" für den Sprint-Umfang bewusst durch "Forecast". Verbindlich ist das Sprint-Ziel; welche Einträge dafür nötig sind, kann sich im Sprint ändern.

Merksatz: Prognose = Wetterbericht, nicht Garantieschein. Nur das Sprint-Ziel ist verbindlich – wie ein Kompass, der die Richtung hält, während der Weg sich zeigt.

Warum die anderen falsch sind:

„Verpflichtung, alles fertigzustellen" – verwechselt Prognose mit Vertrag; Scrum kennt kein Fertigstellungs-Commitment.

☝️ Single Ein Team soll für sechs Monate im Voraus verbindlich zusagen, welche Funktionen fertig sein werden. Was ist die fachlich korrekte Antwort?

❌ Eine feste Zusage geben und den Umfang notfalls durch Überstunden halten

❌ Die Schätzungen pauschal verdoppeln und das Ergebnis als Zusage abgeben

❌ Die Frage ablehnen, weil Prognosen in Scrum nicht vorgesehen sind

✅ Eine Prognose mit Bandbreite anbieten, die auf empirischen Daten beruht, und sie nach jedem Sprint aktualisieren

Agilität heißt nicht, keine Aussagen zu treffen. Sie heißt, Aussagen als das zu kennzeichnen, was sie sind: Prognosen mit Unsicherheit, die regelmäßig neu berechnet werden.

Merksatz: Scrum liefert Prognosen mit Bandbreite statt fester Zusagen – wie ein Wetterbericht: „70 % Regen“ ist ehrlich, „es regnet garantiert“ wäre gelogen. Empirie schlägt Hellseherei, jeder Sprint justiert neu.

Warum die anderen falsch sind:

Überstunden als Puffer: missbraucht Team, ignoriert Unsicherheit.

Schätzung verdoppeln: willkürlich, keine empirische Basis.

Prognose ablehnen: Scrum kennt sehr wohl Prognosen – nur keine Garantien.

Backlog-Einträge [Praxis] 6 Unterseite →

☝️ Single Wofür steht das Akronym INVEST bei der Bewertung von Backlog-Einträgen?

❌ Initiate, Norm, Verify, Execute, Ship, Test

❌ Inspect, Validate, Notify, Evaluate, Sort, Track

✅ Independent, Negotiable, Valuable, Estimable, Small, Testable

❌ Integrate, Navigate, Visualize, Estimate, Simplify, Transform

INVEST ist eine Prüfliste, keine Scrum-Vorgabe. Besonders wertvoll sind "Valuable" (jeder Eintrag muss für sich Nutzen stiften) und "Testable" (ohne überprüfbares Kriterium ist ein Eintrag nicht abnehmbar).

Merksatz: „INVEST = Ein guter Backlog-Eintrag ist wie ein guter Kunde: unabhängig, verhandelbar, wertvoll, schätzbar, klein, testbar."

Warum die anderen falsch sind:

Initiate/Norm/Verify/Execute/Ship/Test – klingt nach Prozessphasen, nicht nach Qualitätskriterien.

Inspect/Validate/Notify/Evaluate/Sort/Track – mischt Scrum-Zeremonien mit Backlog-Pflege.

Integrate/Navigate/Visualize/Estimate/Simplify/Transform – typische Verwechslung mit agilen Prinzipien.

☝️ Single Wie ist eine klassische User Story aufgebaut?

❌ Gegeben Zustand A, wenn Ereignis B, dann Ergebnis C

✅ Als Rolle möchte ich ein Ziel erreichen, damit ein bestimmter Nutzen entsteht

❌ Das System muss die Funktion X gemäß Spezifikation Y bereitstellen

❌ Aufgabe, Verantwortlicher, Aufwand, Termin

Der dritte Teil ("damit...") ist der wichtigste und wird am häufigsten weggelassen. Ohne ihn fehlt der Nutzen, und der Eintrag lässt sich weder priorisieren noch sinnvoll diskutieren. Die dritte Option beschreibt das Gherkin-Format für Akzeptanzkriterien.

☝️ Single Was sind Akzeptanzkriterien eines Backlog-Eintrags?

✅ Eintragsspezifische, überprüfbare Bedingungen, die erfüllt sein müssen, damit genau dieser Eintrag als fachlich erfüllt gilt

❌ Die Schätzung des Eintrags in Story Points

❌ Die Liste der Stakeholder, die dem Eintrag zugestimmt haben

❌ Die für alle Einträge gleichermaßen geltenden Qualitätsstandards des Teams

Die zweite Option beschreibt die Definition of Done. Beide werden gebraucht: Die Akzeptanzkriterien klären das WAS für einen einzelnen Eintrag, die Definition of Done das WIE GUT für alle.

☝️ Single Ein Backlog-Eintrag ist zu groß für einen Sprint. Welche Zerlegung ist im Sinne von Scrum am sinnvollsten?

❌ Nach Kalenderwochen, damit jede Woche ein Eintrag fertig wird

✅ Vertikal entlang des fachlichen Nutzens, sodass jedes Teilstück für sich ein nutzbares Ergebnis liefert

❌ Horizontal nach technischen Schichten: ein Eintrag für die Datenbank, einer für die Oberfläche

❌ Nach Teammitgliedern, damit jeder seinen eigenen Eintrag hat

Die Zerlegung nach technischen Schichten ist der häufigste Fehler: Erst wenn alle Schichten fertig sind, entsteht Nutzen – und damit wieder kein Increment. Vertikale Schnitte liefern in jedem Sprint etwas Überprüfbares.

Merksatz: Zerlege wie eine Pizza, nicht wie eine Zwiebel: Jedes Stück ist für sich genießbar – vertikal am Nutzen entlang, nicht in Schichten.

Warum die anderen falsch sind:

Kalenderwochen: Zeit ist kein Wertmaßstab, Scrum liefert Inkremente, keine Wochenhäppchen.

Horizontale Schichten: Datenbank allein nutzt niemandem – kein fertiges Inkrement.

Nach Teammitgliedern: Scrum-Teams liefern gemeinsam, keine Einzel-Silos.

✌️ Multi Welche Aussagen zu Product-Backlog-Einträgen treffen zu? (Mehrere richtig)

✅ Der Scrum Guide schreibt kein bestimmtes Format wie User Stories vor.

✅ Ein Eintrag sollte Beschreibung, Reihenfolge, Größe und Wert erkennen lassen.

❌ Jeder Eintrag muss zwingend im Format "Als … möchte ich … damit …" formuliert sein.

✅ Einträge weiter oben im Backlog sind in der Regel kleiner und genauer beschrieben.

User Stories stammen aus Extreme Programming, nicht aus Scrum. Sie sind eine hilfreiche, aber austauschbare Praktik – auch Job Stories, Use Cases oder schlichte Beschreibungen sind zulässig.

Merksatz: Der Backlog ist ein lebendes Werkzeug, kein Formular: Format frei, aber Inhalt klar – oben klein und fein, unten grob und vage.

Warum die anderen falsch sind:

„As a…, I want…" ist nur EIN mögliches Format, kein Muss.

Kein Formatzwang: Der Scrum Guide schreibt User Stories nicht vor.

☝️ Single Was beschreibt eine "Definition of Ready"?

❌ Ein verbindliches Scrum-Artefakt mit eigenem Commitment

❌ Die Bedingung, unter der ein Increment ausgeliefert werden darf

✅ Eine vom Team vereinbarte, nicht im Scrum Guide vorgeschriebene Prüfliste, wann ein Eintrag als ausreichend geklärt für die Sprint-Auswahl gilt

❌ Die Zusage des Product Owners, dass ein Eintrag bezahlt wird

Nützlich als Orientierung, gefährlich als Tor: Wird die Definition of Ready zur harten Übergabehürde, entsteht wieder ein Phasenmodell mit Wartezeiten zwischen Anforderung und Umsetzung.

Merksatz: „Ready" ist kein Scrum-Werkzeug, sondern ein team-eigenes Ticket-Gate: erst wenn die Checkliste abgehakt ist, darf der Backlog-Eintrag in den Sprint.

Warum die anderen falsch sind:

Kein Artefakt, kein Commitment – DoR steht nirgends im Scrum Guide.

Verwechslung mit DoD/Increment-Lieferbedingung.

„Bezahlt" ist kein Scrum-Konzept, PO committet Ziele, nicht Rechnungen.

Flow & Lean [Praxis] 4 Unterseite →

☝️ Single Was bedeutet ein WIP-Limit (Work in Progress)?

❌ Die maximale Anzahl an Einträgen im Product Backlog

✅ Eine Obergrenze für die Anzahl gleichzeitig begonnener, aber noch nicht fertiger Arbeit

❌ Die maximale Anzahl an Stunden pro Sprint

❌ Die maximale Anzahl an Teammitgliedern

Der Effekt ist kontraintuitiv: Weniger gleichzeitig begonnene Arbeit führt zu schnellerer Fertigstellung, weil Wartezeiten und Umschaltverluste sinken. "Stop starting, start finishing."

Merksatz: WIP-Limit = „Stoppschild für Baustellen“: Nur X Aufgaben dürfen gleichzeitig angefangen und noch nicht fertig sein – erst fertigstellen, dann Neues ziehen.

Warum die anderen falsch sind:

Product Backlog: Backlog ist die Ideensammlung, kein Arbeitsfluss-Limit.

Stunden pro Sprint: Das ist Zeitbudget, nicht Anzahl paralleler Aufgaben.

Teamgröße: Das regelt Teamzusammensetzung, nicht den Arbeitsfluss.

☝️ Single Was besagt Little's Law im Kontext der Produktentwicklung?

❌ Kleine Einträge haben immer den höchsten Geschäftswert

❌ Jedes Team benötigt mindestens drei Developers

✅ Die durchschnittliche Durchlaufzeit ergibt sich aus der Menge gleichzeitig laufender Arbeit geteilt durch den Durchsatz

❌ Die Velocity eines Teams steigt proportional zur Teamgröße

Praktische Folge: Um schneller zu liefern, kann man entweder den Durchsatz erhöhen (schwer) oder die parallel laufende Arbeit reduzieren (sofort möglich). Deshalb wirken WIP-Limits so schnell.

☝️ Single Was ist der Unterschied zwischen Durchlaufzeit (Cycle Time) und Vorlaufzeit (Lead Time)?

❌ Die Vorlaufzeit betrifft nur Hardwareprojekte

❌ Die Durchlaufzeit misst in Story Points, die Vorlaufzeit in Tagen

✅ Die Durchlaufzeit misst ab Arbeitsbeginn, die Vorlaufzeit ab dem Zeitpunkt, an dem der Wunsch geäußert wurde

❌ Die Begriffe sind gleichbedeutend

Für Stakeholder ist die Vorlaufzeit die gefühlte Wartezeit, für das Team die Durchlaufzeit die steuerbare Größe. Eine große Differenz zwischen beiden weist auf ein überfülltes Backlog hin.

✌️ Multi Welche Aussagen zum Verhältnis von Scrum und Kanban treffen zu? (Mehrere richtig)

✅ Kanban-Praktiken wie Visualisierung, WIP-Limits und Flow-Metriken lassen sich innerhalb von Scrum einsetzen.

✅ Beide Ansätze beruhen auf Transparenz und regelmäßiger Inspektion.

❌ Wer Kanban-Praktiken nutzt, verletzt damit automatisch den Scrum Guide.

✅ Scrum ist iterationsbasiert mit festen Sprints, Kanban ist flussbasiert ohne vorgeschriebene Iteration.

Scrum ist bewusst unvollständig und lässt ergänzende Praktiken ausdrücklich zu. Solange Events, Artefakte, Commitments und Verantwortlichkeiten unangetastet bleiben, ist die Kombination unproblematisch.

Merksatz: Scrum und Kanban sind Geschwister, keine Rivalen: Scrum gibt den Takt (Sprint), Kanban schmiert die Maschine (WIP-Limits, Flow). Beide lieben Transparenz und Inspektion – kombinierbar!

Warum die anderen falsch sind:

„Verletzt automatisch den Scrum Guide" – falsch: Der Guide erlaubt ergänzende Praktiken, solange Scrum-Werte und -Regeln gewahrt bleiben.

Technische Exzellenz [Praxis] 3 Unterseite →

☝️ Single Was sind technische Schulden?

❌ Nicht fertiggestellte Backlog-Einträge am Sprint-Ende

❌ Die Differenz zwischen geschätzter und tatsächlicher Velocity

✅ Zusätzlicher künftiger Aufwand, der dadurch entsteht, dass heute eine schnellere statt einer sauberen Lösung gewählt wurde

❌ Offene Rechnungen gegenüber externen Dienstleistern

Wie bei echten Schulden fallen Zinsen an: Jede weitere Änderung am belasteten Bereich wird teurer. Deshalb ist die Definition of Done das wirksamste Instrument gegen unbemerktes Anwachsen.

Merksatz: Technische Schulden sind wie ein Kredit: Schnell gebaut, später teuer zurückgezahlt – der Zins ist der Zusatzaufwand.

Warum die anderen falsch sind:

Unfertige Backlog-Einträge: Das ist Scope, kein Schuldenberg.

Velocity-Differenz: Schätzabweichung, nichts mit Code-Qualität.

Offene Rechnungen: Buchhaltung, nicht Software-Handwerk.

☝️ Single Welches agile Prinzip begründet die Bedeutung technischer Praktiken wie Refactoring und Testautomatisierung?

❌ Geschäftsleute und Entwickler müssen täglich zusammenarbeiten

✅ Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität

❌ Die besten Anforderungen entstehen durch selbstorganisierte Teams

❌ Einfachheit ist essenziell

Der Zusammenhang ist direkt: Nur eine wartbare Codebasis erlaubt es, Anforderungsänderungen auch spät noch günstig aufzunehmen. Ohne technische Exzellenz wird Agilität mit der Zeit unbezahlbar.

Merksatz: „Sauberer Code bleibt flink" – wie ein gepflegtes Fahrrad schnell bleibt, hält technische Exzellenz (Refactoring, Tests) das Team agil.

Warum die anderen falsch sind:

Tägliche Zusammenarbeit: betrifft Kommunikation, nicht Codequalität.

Selbstorganisation: betrifft Teamstruktur, nicht Technik.

Einfachheit: meint Weglassen von Unnötigem, nicht Exzellenz.

☝️ Single Ein Team liefert am Sprint-Ende Code, der erst in einer separaten Testphase nach dem Sprint geprüft wird. Wie ist das zu bewerten?

✅ Es entsteht kein Increment im Sinne von Scrum, weil die Definition of Done im Sprint nicht erfüllt wird

❌ Korrekt, weil Testen laut Scrum Guide nach dem Sprint stattfindet

❌ Unproblematisch, wenn der Product Owner zustimmt

❌ Unproblematisch, solange die Tests vor der nächsten Release laufen

Genau hier entstehen Hardening-Sprints und unsichtbare Restarbeit. Was am Sprint-Ende nicht der Definition of Done entspricht, ist nicht fertig – unabhängig davon, wie weit es gediehen ist.

Scrum-Theorie & Empirie

Empirie [Theorie] 11 Unterseite →

☝️ Single Auf welchen drei Säulen beruht die empirische Prozesssteuerung in Scrum?

❌ Rollen, Events, Artefakte

✅ Transparenz, Inspektion, Adaption

❌ Planung, Ausführung, Kontrolle

❌ Commitment, Fokus, Mut

Die drei Säulen der Empirie sind Transparenz, Inspektion und Adaption. Rollen/Events/Artefakte sind der Aufbau des Rahmenwerks, nicht die Säulen der Empirie.

☝️ Single Ein Scrum-Team stellt beim Daily Scrum fest, dass es das Sprint-Ziel voraussichtlich nicht erreicht. Welche Säule der Empirie wird als Nächstes wirksam?

✅ Adaption – der Plan wird angepasst

❌ Inspektion – nur beobachten

❌ Keine, das Daily dient nur dem Status

❌ Transparenz – nichts ändern

Nach der Inspektion (Erkennen der Abweichung im Daily) folgt die Adaption: Die Developers passen ihren Plan an, um das Sprint-Ziel bestmöglich zu erreichen.

✌️ Multi Welche Bedingungen müssen für funktionierende Empirie in Scrum gegeben sein? (Mehrere richtig)

❌ Ein detaillierter Gesamtplan zu Projektbeginn

❌ Feste Vorgaben, die sich nie ändern

✅ Regelmäßige Inspektion durch die Beteiligten

✅ Bereitschaft zur Adaption bei Abweichungen

✅ Ausreichende Transparenz der Artefakte

Empirie braucht Transparenz, Inspektion und Adaption. Ein starrer Gesamtplan und unveränderliche Vorgaben widersprechen dem empirischen, adaptiven Ansatz.

✍️ Offen Erklären Sie die drei Säulen der Empirie und wie sie im Sprint zusammenwirken.

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).

Bewertet werden: alle drei Säulen korrekt benannt und erklärt + Zusammenwirken (Transparenz ermöglicht Inspektion, Inspektion löst Adaption aus).

Merksatz: Drei Säulen wie ein Arztbesuch: Transparenz = Röntgenbild (alles sichtbar), Inspektion = Untersuchung (regelmäßig prüfen), Adaption = Behandlung (anpassen). Ohne klares Bild keine Diagnose, ohne Diagnose keine Therapie. Im Sprint: Daily & Review zeigen offen den Fortschritt, das Team erkennt Abweichungen und passt Plan oder Produkt sofort an. TIA – Transparenz ermöglicht Inspektion, Inspektion ermöglicht Adaption.

☝️ Single Welche Säule der Empirie ist die Voraussetzung für die beiden anderen?

❌ Commitment

❌ Inspektion

✅ Transparenz

❌ Adaption

Ohne Transparenz ist jede Inspektion irreführend und jede daraus abgeleitete Adaption falsch. Transparenz ist deshalb die Grundlage der beiden anderen Säulen.

☝️ Single Was passiert, wenn bei einer Inspektion eine Abweichung außerhalb akzeptabler Grenzen festgestellt wird?

✅ Der Prozess oder das entstehende Produkt muss angepasst werden – so schnell wie möglich

❌ Die Abweichung wird dokumentiert und am Sprintende gesammelt behandelt

❌ Der Scrum Master eskaliert an das Management

❌ Der Sprint wird abgebrochen

Adaption bedeutet: sobald erkannt wird, dass etwas außerhalb der akzeptablen Grenzen liegt, wird möglichst schnell angepasst, um weitere Abweichung zu vermeiden.

Merksatz: Inspektion ohne Anpassung ist wie Fieber messen ohne Handeln – Abweichung erkannt, sofort justieren, nicht warten.

Warum die anderen falsch sind:

Sammeln am Sprintende: widerspricht „so schnell wie möglich".

Eskalation an Management: Scrum Master löst im Team, nicht top-down.

Sprint-Abbruch: zu radikal; Anpassung, nicht Abbruch ist die Antwort.

☝️ Single Warum sind die Scrum-Events fest getaktet und wiederkehrend?

❌ Weil Kalenderplanung für das Management einfacher wird

❌ Weil agile Frameworks möglichst viele Meetings vorsehen

✅ Sie schaffen regelmäßige Gelegenheiten zur Inspektion und Adaption und reduzieren den Bedarf an weiteren Meetings

❌ Weil der Scrum Master sonst keine Kontrolle über das Team hat

Jedes Event ist eine formale Gelegenheit zu inspizieren und anzupassen. Genau deshalb macht Scrum sie regelmäßig – und macht andere Meetings dadurch weitgehend überflüssig.

☝️ Single Welches Scrum-Element dient primär der Inspektion des Fortschritts in Richtung Sprint-Ziel?

❌ Das Product Backlog Refinement

✅ Das Daily Scrum

❌ Das Sprint Planning

❌ Die Sprint Retrospective

Im Daily Scrum inspizieren die Developers den Fortschritt zum Sprint-Ziel und passen den Plan für den nächsten Arbeitstag an.

✍️ Offen Ein Team hält alle Scrum-Events pünktlich ab, liefert aber seit Monaten kein nutzbares Increment. Analysieren Sie, welche Säule der Empirie hier vermutlich ausfällt, und begründen Sie Ihre Antwort.

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.

☝️ Single Warum genügt Transparenz allein nicht für funktionierende Empirie?

✅ Weil Transparenz nur die Voraussetzung ist – ohne Inspektion in festen Abständen und daraus folgende Adaption bleibt sie folgenlos

❌ Weil Transparenz erst ab einer bestimmten Teamgröße wirkt

❌ Weil Transparenz nur für Artefakte gilt, nicht für den Prozess

❌ Weil Transparenz durch die Definition of Done ersetzt wird

Die drei Säulen wirken nur zusammen: Inspektion ohne Transparenz prüft Falsches, Inspektion ohne Adaption ändert nichts.

Merksatz: Transparenz ist das Fenster – Inspektion der Blick, Adaption die Handlung. Ohne Schauen und Ändern bleibt das Fenster nur Glas.

Warum die anderen falsch sind:

Teamgröße spielt keine Rolle – Empirie gilt immer.

Transparenz betrifft Artefakte UND Prozess.

DoD schafft Transparenz, ersetzt sie nicht.

☝️ Single Ein Team arbeitet an einer Aufgabe, die vollständig verstanden und mehrfach identisch durchgeführt wurde. Was folgt daraus für den Einsatz von Scrum?

❌ Scrum ist dennoch vorzuziehen, weil es in jedem Kontext funktioniert

❌ Scrum ist einsetzbar, sofern auf Retrospektiven verzichtet wird

✅ Der empirische Aufwand bringt hier wenig Nutzen; bei wiederholbarer Arbeit ist ein festgelegter Ablauf oder ein Flusssystem meist überlegen

❌ Scrum ist einsetzbar, sofern die Sprint-Länge auf eine Woche verkürzt wird

Scrum adressiert komplexe Probleme, bei denen mehr unbekannt als bekannt ist. Bei vollständig verstandener Arbeit erzeugen Inspektion und Adaption Aufwand ohne Erkenntnisgewinn. Das ehrlich zu benennen gehört zur Beratungskompetenz.

Scrum-Definition [Theorie] 3 Unterseite →

☝️ Single Was beschreibt Scrum am treffendsten?

✅ Ein leichtgewichtiges Rahmenwerk zur Lösung komplexer adaptiver Probleme

❌ Ein Software-Entwicklungsprozess nur für IT

❌ Eine Sammlung von Best Practices ohne Regeln

❌ Eine detaillierte Projektmanagement-Methode mit festen Prozessschritten

Der Scrum Guide definiert Scrum als leichtgewichtiges Rahmenwerk für komplexe adaptive Probleme. Es ist bewusst KEINE vollständige Methode und nicht auf IT beschränkt.

Merksatz: Scrum ist kein Rezept, sondern ein Rahmen – leicht, adaptiv, für komplexe Probleme.

Warum die anderen falsch sind:

Nur IT: Scrum ist branchenunabhängig.

Best Practices ohne Regeln: Scrum hat klare Regeln und Werte.

Detaillierte Methode mit festen Schritten: Scrum ist bewusst schlank und nicht deterministisch.

☝️ Single Wie definiert der Scrum Guide Scrum am treffendsten?

❌ Ein Software-Entwicklungsprozess für IT-Projekte

✅ Ein leichtgewichtiges Rahmenwerk, das Menschen hilft, komplexe Probleme adaptiv zu lösen

❌ Ein Werkzeugkasten agiler Techniken wie Planning Poker und Burndown Charts

❌ Eine Projektmanagement-Methode mit vorgeschriebenen Prozessschritten

Scrum ist ein leichtgewichtiges Rahmenwerk (Framework), keine Methode und kein Prozess. Es gibt einen Rahmen vor, innerhalb dessen das Team eigene Praktiken wählt.

☝️ Single In welchen Bereichen außerhalb der Softwareentwicklung wird Scrum eingesetzt?

✅ In allen Bereichen mit komplexer Arbeit – etwa Marketing, Forschung, Bildung, Hardware oder Organisationsentwicklung

❌ Ausschließlich in der Softwareentwicklung

❌ Nur in Bereichen mit mindestens 50 Mitarbeitenden

❌ Nur dort, wo ein zertifizierter Scrum Master vorhanden ist

Der Scrum Guide 2020 wurde gezielt von Software-Begriffen befreit, um genau das zu unterstreichen. Entscheidend ist die Komplexität der Arbeit, nicht die Branche.

Scrum-Theorie [Theorie] 7 Unterseite →

✌️ Multi Welche Aussagen über Scrum sind korrekt? (Mehrere richtig)

❌ Scrum funktioniert nur mit mindestens 20 Personen

✅ Scrum ist immutable – die definierten Elemente sind verbindlich

❌ Scrum schreibt jeden Arbeitsschritt genau vor

✅ Scrum ist bewusst unvollständig

✅ Scrum baut auf kollektiver Intelligenz der Beteiligten

Scrum ist absichtlich unvollständig, baut auf kollektiver Intelligenz und seine Elemente sind verbindlich ("immutable"). Es schreibt NICHT jeden Schritt vor und hat keine Mindestgröße von 20.

Merksatz: Scrum ist ein Gerüst, kein Rezept: unveränderlich im Kern, bewusst unvollständig im Detail – die Intelligenz kommt vom Team, nicht vom Framework.

Warum die anderen falsch sind:

Mindestgröße 20: Scrum skaliert klein, typisch 3–9 im Team.

Jeden Schritt vorschreiben: Scrum lässt Freiraum, keine Mikro-Vorgaben.

☝️ Single Was bedeutet es, dass Scrum "bewusst unvollständig" ist?

❌ Einzelne Scrum-Elemente dürfen weggelassen werden, wenn sie nicht passen

✅ Scrum definiert nur das Nötigste; Praktiken und Techniken wählen die Anwender selbst

❌ Scrum funktioniert nur in Kombination mit einem zweiten Rahmenwerk

❌ Scrum ist noch in Entwicklung und wird jährlich um Elemente ergänzt

Unvollständig heißt: Scrum schreibt keine konkreten Techniken vor. Es heißt NICHT, dass man Elemente weglassen darf – die definierten Elemente sind verbindlich.

☝️ Single Ein Team lässt die Sprint Retrospective dauerhaft weg, weil "gerade keine Zeit" ist. Wie ist das zu bewerten?

❌ Das ist erlaubt, wenn der Scrum Master zustimmt

✅ Das Ergebnis ist nicht mehr Scrum; die Elemente von Scrum sind verbindlich

❌ Das ist erlaubt, solange das Team seine Sprint-Ziele erreicht

❌ Das ist erlaubt, solange die anderen Events stattfinden

Scrum ist "immutable": Einzelne Elemente wegzulassen ist möglich, aber das Ergebnis ist dann nicht Scrum. Weggelassene Elemente verdecken genau die Probleme, die sie sichtbar machen sollen.

✌️ Multi Welche Aussagen zum Verhältnis von Scrum und agilen Praktiken sind korrekt? (Mehrere richtig)

✅ Techniken wie Planning Poker sind Ergänzungen, kein Scrum-Bestandteil

✅ Scrum kann mit Kanban-Praktiken kombiniert werden

❌ Ohne User Stories ist Scrum nicht anwendbar

❌ Velocity ist ein im Scrum Guide definiertes Pflichtmaß

✅ Scrum schreibt weder User Stories noch Story Points vor

User Stories, Story Points, Planning Poker und Velocity kommen im Scrum Guide nicht vor. Sie sind verbreitete, aber optionale Ergänzungen.

☝️ Single Wer darf Scrum verwenden?

✅ Jede Organisation und jedes Team, das komplexe Arbeit adaptiv angehen will – Scrum ist nicht auf IT beschränkt

❌ Nur Organisationen mit agiler Transformationsstrategie

❌ Nur Softwareentwicklungsteams

❌ Nur Teams mit zertifiziertem Scrum Master

Scrum wird in Marketing, Forschung, Bildung, Hardware und vielen anderen Bereichen eingesetzt. Eine Zertifizierung ist keine Voraussetzung.

✍️ Offen Erklären Sie, warum Transparenz ohne Vertrauen in einer Organisation kaum herstellbar ist, und welche Folgen fehlende Transparenz für die Empirie hat.

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.

Bewertet werden: Transparenz als Sichtbarmachen auch unangenehmer Fakten + Zusammenhang zu psychologischer Sicherheit/Vertrauen + konkrete Folge für Inspektion und Adaption + Bezug zu den Scrum-Werten.

Merksatz: Transparenz ist ein Fenster – Vertraün ist der Rahmen. Ohne Rahmen zerbricht das Glas: Man zeigt nur Geschöntes, verschweigt Probleme, weicht die DoD auf. Dann inspiziert man Lügen und adaptiert in die falsche Richtung – der empirische Kreislauf dreht sich, aber ins Verderben. Deshalb sind Offenheit, Mut und Respekt keine Deko, sondern Fundament der drei Säulen.

☝️ Single Was bedeutet der Satz, dass die Elemente von Scrum "immutable" (unveränderlich) sind?

✅ Einzelne Teile dürfen weggelassen werden, aber das Ergebnis ist dann kein Scrum mehr und verdeckt Probleme, statt sie sichtbar zu machen

❌ Der Scrum Guide darf nicht überarbeitet werden

❌ Die Sprint-Länge darf nach der ersten Festlegung nicht mehr geändert werden

❌ Scrum darf unter keinen Umständen durch weitere Praktiken ergänzt werden

Der Scrum Guide formuliert es als Warnung, nicht als Verbot: Teile wegzulassen ist möglich, hebt aber genau den Nutzen auf, für den die Teile da sind.

Grundlagen [Theorie] 1 Unterseite →

☝️ Single Auf welchen beiden Fundamenten beruht Scrum laut Scrum Guide 2020?

❌ Kanban und Extreme Programming

✅ Empirie und Lean Thinking

❌ Empirie und Wasserfallplanung

❌ Lean Thinking und Six Sigma

Scrum gründet auf Empirie (Wissen entsteht aus Erfahrung) und Lean Thinking (Verschwendung reduzieren, auf das Wesentliche fokussieren).

Komplexität [Theorie] 7 Unterseite →

☝️ Single Für welche Art von Arbeit ist Scrum in erster Linie gedacht?

❌ Ausschließlich Softwareentwicklung

❌ Einfache, gut verstandene Routinearbeit

❌ Arbeit mit vollständig bekannten Anforderungen und stabilem Umfeld

✅ Komplexe Arbeit, bei der mehr unbekannt als bekannt ist

Scrum adressiert komplexe adaptive Probleme. Bei einfachen, wiederholbaren Aufgaben ist der empirische Overhead unnötig.

☝️ Single Ein Auftraggeber fordert einen verbindlichen Fixpreis und Fixumfang für ein Vorhaben mit vielen Unbekannten. Was ist die scrum-konforme Haltung?

❌ Den Auftrag ablehnen, da Scrum Festpreise ausschließt

❌ Scrum verwenden, aber alle Anforderungen vorab vollständig spezifizieren

✅ Transparent machen, dass Umfang bei komplexer Arbeit nicht verlässlich vorab fixierbar ist, und stattdessen iterative Lieferung mit fester Taktung anbieten

❌ Den Umfang schätzen, fixieren und im Sprint durchziehen

Bei komplexer Arbeit ist der Umfang die unsicherste Größe. Scrum macht das transparent und liefert stattdessen regelmäßig nutzbare Inkremente, an denen der Kunde steuern kann.

☝️ Single Was ordnet die Stacey-Matrix ein?

✅ Vorhaben nach Klarheit der Anforderungen und Klarheit der Technologie/Lösung, um das passende Vorgehen abzuleiten

❌ Teammitglieder nach Erfahrung und Motivation

❌ Stakeholder nach Macht und Interesse

❌ Backlog-Einträge nach Aufwand und Nutzen

Je weiter ein Vorhaben von "beides klar" entfernt liegt, desto weniger trägt ein vorab vollständiger Plan. Scrum zielt auf den komplexen Bereich, in dem Anforderungen und Lösung erst im Tun erkennbar werden.

Merksatz: Stacey = zwei Achsen, vier Felder: „Was wollen wir?" (Anforderungen) mal „Wie schaffen wir's?" (Technologie). Beide unklar = komplex → empirisch/agil.

Warum die anderen falsch sind:

Erfahrung/Motivation → das ist Situatives Führen, nicht Stacey.

Macht/Interesse → das ist die Stakeholder-Matrix (Mendelow).

Aufwand/Nutzen → das ist Priorisierung (z. B. WSJF), nicht Komplexität.

☝️ Single Welche Domäne des Cynefin-Frameworks passt am besten zum Anwendungsbereich von Scrum?

❌ Chaotisch – es zählt nur sofortiges Handeln

❌ Kompliziert – Expertenwissen genügt zur vollständigen Vorabplanung

✅ Komplex – Ursache und Wirkung sind erst im Nachhinein erkennbar, deshalb "probe, sense, respond"

❌ Einfach/klar – bewährte Praktiken sind bekannt und werden angewendet

Im komplizierten Bereich reicht Expertise und ein Plan. Erst im komplexen Bereich zahlt sich der empirische Ansatz aus, weil man das Ergebnis eines Schritts nicht zuverlässig vorhersagen kann.

Merksatz: „Scrum ist ein Kompass, kein Bauplan“ – im Complex-Domain gilt: probieren (probe), beobachten (sense), anpassen (respond). Ursache und Wirkung zeigen sich erst rückblickend.

Warum die anderen falsch sind:

Chaotic: dort regiert sofortiges Handeln, nicht empirisches Vorgehen.

Complicated: Expertenplanung reicht – Scrum braucht aber Empirie statt Vorabanalyse.

Simple/clear: bewährte Best Practices genügen – Scrum lebt von Emergenz und Anpassung.

☝️ Single Warum funktioniert ein vollständiger Vorabplan bei komplexer Produktentwicklung schlecht?

❌ Weil Pläne rechtlich nicht bindend sind

✅ Weil Anforderungen und Lösungswege sich während der Arbeit ändern und Wissen erst durch Umsetzung entsteht

❌ Weil Entwickler ungern nach Plänen arbeiten

❌ Weil Planung generell überflüssig ist

Scrum ersetzt den Vorabplan nicht durch Planlosigkeit, sondern durch häufige Neuplanung. Geplant wird in jedem Sprint erneut – mit dem Wissen, das bis dahin tatsächlich vorliegt.

☝️ Single Ein Vorhaben ist Routine: Anforderungen und Vorgehen sind vollständig bekannt und hundertfach erprobt. Ist Scrum hier die richtige Wahl?

✅ Nein – bei geringer Unsicherheit erzeugt der empirische Overhead mehr Aufwand als Nutzen; ein definierter Prozess ist effizienter.

❌ Nein – Scrum ist ausschließlich für Softwareentwicklung zulässig.

❌ Ja – Scrum ist für jede Art von Arbeit die überlegene Wahl.

❌ Ja, aber nur mit einwöchigen Sprints.

Scrum ist kein Selbstzweck. Für wiederholbare Arbeit mit bekanntem Weg ist ein standardisierter Prozess oder ein Flow-System wie Kanban meist die bessere Antwort.

☝️ Single Was unterscheidet einen empirischen von einem definierten Prozess?

❌ Der empirische Prozess ist schneller

❌ Die Begriffe bezeichnen dasselbe

❌ Der definierte Prozess kommt ohne Planung aus

✅ Der definierte Prozess ist vollständig vorhersagbar und wiederholbar; der empirische beruht auf Beobachtung und Anpassung, weil Vorhersage nicht möglich ist

Die Unterscheidung stammt aus der Prozesssteuerungstheorie und ist die theoretische Grundlage von Scrum: Wo dieselben Eingaben nicht dieselben Ergebnisse liefern, versagt der definierte Ansatz.

Iterativ-inkrementell [Theorie] 1 Unterseite →

☝️ Single Was ist der Unterschied zwischen "iterativ" und "inkrementell"?

❌ Iterativ bezieht sich auf Software, inkrementell auf Hardware

❌ Die Begriffe sind Synonyme

✅ Iterativ = wiederholte Verbesserung des Gleichen; inkrementell = stückweiser Aufbau in nutzbaren Teilen

❌ Iterativ = stückweiser Aufbau; inkrementell = wiederholte Überarbeitung

Scrum ist beides: In jedem Sprint entsteht ein zusätzliches nutzbares Stück (inkrementell), und Bestehendes wird auf Basis von Feedback überarbeitet (iterativ).

Agiles Manifest [Theorie] 9 Unterseite →

☝️ Single Wie verhält sich Scrum zum Agilen Manifest?

❌ Das Agile Manifest ersetzt den Scrum Guide

✅ Scrum ist älter als das Manifest und setzt dessen Werte konkret um, ist aber nicht daraus abgeleitet

❌ Scrum widerspricht mehreren Punkten des Agilen Manifests

❌ Scrum wurde vom Agilen Manifest definiert

Scrum existierte bereits in den 1990ern; das Manifest entstand 2001. Scrum ist ein Rahmenwerk, das agile Werte in konkrete Struktur übersetzt.

Merksatz: Scrum ist der ältere Bruder – geboren 1995, das Manifest folgte 2001. Nicht das Manifest erschuf Scrum, sondern Scrum lebte die Werte schon vorher.

Warum die anderen falsch sind:

Manifest ersetzt Guide: Das Manifest ist Wertekompass, kein Regelwerk – es ersetzt nichts.

Widerspruch: Scrum verkörpert die Manifest-Werte, statt ihnen zu widersprechen.

Vom Manifest definiert: Umgekehrte Zeitrichtung – Scrum existierte vor dem Manifest.

☝️ Single Wie lauten die vier Wertepaare des Agilen Manifests?

✅ Individuen und Interaktionen über Prozesse und Werkzeuge; funktionierende Software über umfassende Dokumentation; Zusammenarbeit mit dem Kunden über Vertragsverhandlung; Reagieren auf Veränderung über das Befolgen eines Plans

❌ Planung, Analyse, Umsetzung, Abnahme

❌ Commitment, Fokus, Offenheit, Respekt

❌ Transparenz über Kontrolle; Geschwindigkeit über Qualität; Team über Management; Ergebnis über Aufwand

Das Manifest stellt vier Werte gegenüber. Entscheidend ist der Nachsatz: Die Werte rechts haben durchaus Wert, die Werte links haben für die Autoren mehr Wert. Es ist also keine Ablehnung von Dokumentation, Verträgen oder Plänen.

Merksatz: „Menschen vor Maschinen, Code vor Papier, Kunde vor Vertrag, Wandel vor Plan“ – vier Paare, immer „X über Y“.

Warum die anderen falsch sind:

Planung/Analyse/Umsetzung/Abnahme: klassischer Wasserfall-Ablauf, kein Wertepaar.

Commitment/Fokus/Offenheit/Respekt: Scrum-Werte, nicht Agile-Manifest-Werte.

Transparenz/Geschwindigkeit/Team/Ergebnis: frei erfunden, klingt agil, ist es aber nicht.

☝️ Single Wie viele Prinzipien stehen hinter dem Agilen Manifest?

❌ Fünf

❌ Siebzehn

❌ Vier

✅ Zwölf

Vier Wertepaare, zwölf Prinzipien. Die Zahl siebzehn bezieht sich auf die Anzahl der Unterzeichner des Manifests im Jahr 2001, nicht auf die Prinzipien.

☝️ Single Ein Manager schließt aus dem Agilen Manifest, dass in agilen Projekten keine Dokumentation mehr erstellt wird. Wie ist das zu bewerten?

❌ Richtig – Dokumentation widerspricht agilen Werten grundsätzlich.

❌ Falsch – das Manifest fordert mehr Dokumentation als klassische Vorgehensmodelle.

❌ Richtig, sofern das Team es in der Retrospektive so beschließt.

✅ Falsch – das Manifest stellt gegenüber und priorisiert, es streicht die rechte Seite nicht. Dokumentation wird auf das reduziert, was tatsächlich Wert stiftet.

Der Satz "während wir die Werte auf der rechten Seite wertschätzen, schätzen wir die Werte auf der linken Seite höher" wird regelmäßig überlesen. Genau daraus entsteht dieses verbreitete Missverständnis.

✌️ Multi Welche Aussagen gehören zu den zwölf agilen Prinzipien? (Mehrere richtig)

✅ Anforderungsänderungen sind selbst spät in der Entwicklung willkommen.

❌ Der Umfang eines Vorhabens wird zu Beginn vollständig festgelegt und danach eingefroren.

✅ Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.

✅ Die höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen.

Das dritte Prinzip wird oft missverstanden: Gemeint ist nicht Faulheit, sondern das konsequente Weglassen von Arbeit, die keinen Wert stiftet. Ein eingefrorener Umfang widerspricht dem zweiten Prinzip direkt.

Merksatz: „Spät willkommen, früh liefern, einfach halten“ – Änderungen umarmen, Wert früh und stetig liefern, Einfachheit (nicht getane Arbeit maximieren) als Kern.

Warum die anderen falsch sind:

Umfang einfrieren: widerspricht „Änderungen willkommen“ – Agilität heißt Anpassung, nicht Starre.

☝️ Single Welches agile Prinzip beschreibt am direktesten, warum Scrum feste Sprint-Längen nutzt?

❌ Die besten Architekturen entstehen durch selbstorganisierte Teams.

❌ Einfachheit ist essenziell.

❌ Funktionierende Software ist das wichtigste Fortschrittsmaß.

✅ Agile Prozesse fördern nachhaltige Entwicklung – Auftraggeber, Entwickler und Nutzer sollten ein gleichmäßiges Tempo unbegrenzt halten können.

Der gleichbleibende Takt ("sustainable pace") ist der Kern: Eine konstante Sprint-Länge erzeugt einen verlässlichen Rhythmus statt Endspurt-Zyklen. Zusätzlich macht sie Vergleiche zwischen Sprints überhaupt erst aussagekräftig.

Merksatz: „Gleichmäßiges Tempo unbegrenzt“ – der Sprint ist der Herzschlag: feste Länge hält das Team im nachhaltigen Rhythmus.

Warum die anderen falsch sind:

Selbstorganisation → erklärt Teamstruktur, nicht Sprintlänge.

Einfachheit → meint Reduktion, nicht Taktung.

Funktionierende Software → betrifft Fortschrittsmessung, nicht Rhythmus.

☝️ Single Welches Fortschrittsmaß nennt das Agile Manifest?

❌ Die Velocity des Teams

❌ Die Anzahl geschriebener Seiten Spezifikation

✅ Funktionierende Software

❌ Der Anteil abgearbeiteter Aufgaben im Sprint Backlog

Genau diese Formulierung ist die Wurzel der Scrum-Regel, dass nur fertige Arbeit im Sinne der Definition of Done zählt. Aufgabenzähler und Velocity sind Hilfsgrößen, keine Fortschrittsmaße.

Merksatz: „Software, die läuft, schlägt Papier, das stapelt" – das Agile Manifest nennt funktionierende Software als einziges Fortschrittsmaß.

Warum die anderen falsch sind:

Velocity – ist Scrum-Metrik, nicht Manifest-Aussage.

Geschriebene Spezifikationsseiten – Manifest bevorzugt genau das Gegenteil.

Anteil erledigter Sprint-Backlog-Tasks – Scrum-Praxis, kein Manifest-Maß.

☝️ Single Welches agile Prinzip beschreibt die bevorzugte Form der Informationsübermittlung?

✅ Das Gespräch von Angesicht zu Angesicht ist die effizienteste Methode, Informationen zu übermitteln

❌ Die Kommunikation sollte über ein zentrales Werkzeug erfolgen

❌ Informationen sollten ausschließlich in den Scrum-Events ausgetauscht werden

❌ Eine vollständige schriftliche Spezifikation ist die zuverlässigste Form

Das Prinzip erklärt, warum Scrum auf gemeinsame Events und kurze Wege setzt – und warum verteilte Teams bewusst Ersatz für die entfallende Nähe schaffen müssen.

☝️ Single Welches agile Prinzip beschreibt der Satz, dass sich Teams in regelmäßigen Abständen darüber Gedanken machen, wie sie effektiver werden können?

✅ Das Prinzip der regelmäßigen Reflexion und Anpassung – in Scrum umgesetzt durch die Sprint Retrospective

❌ Das Prinzip der nachhaltigen Entwicklung

❌ Das Prinzip der Selbstorganisation

❌ Das Prinzip der technischen Exzellenz

Es ist das letzte der zwölf Prinzipien und zugleich dasjenige, das alle anderen erst wirksam macht: Ohne Anpassung bleibt jedes Prinzip eine Absichtserklärung.

Scrum-Historie [Theorie] 3 Unterseite →

☝️ Single Wer sind die Autoren des Scrum Guide?

✅ Ken Schwaber und Jeff Sutherland

❌ Mike Cohn und Roman Pichler

❌ Taiichi Ohno und W. Edwards Deming

❌ Kent Beck und Martin Fowler

Beide gehören auch zu den Unterzeichnern des Agilen Manifests. Der Scrum Guide erscheint seit 2010 und wurde zuletzt 2020 überarbeitet.

Merksatz: „Schwaber & Sutherland – die zwei Väter, die Scrum schrieben und bis heute pflegen."

Warum die anderen falsch sind:

Cohn/Pichler: Agile-Autoren, aber nicht Scrum-Guide-Väter.

Ohno/Deming: Lean-/Qualitäts-Pioniere, Vorläufer, keine Scrum-Autoren.

Beck/Fowler: XP- und Software-Handwerk-Bekannte, nicht Scrum-Guide.

✌️ Multi Welche Änderungen brachte der Scrum Guide 2020 gegenüber 2017? (Mehrere richtig)

✅ Aus "selbstorganisierend" wurde "selbstverwaltend" (self-managing).

✅ Einführung des Product Goal als Commitment des Product Backlog.

✅ Aus "Development Team" wurde "Developers" – ein Team ohne Team im Team.

❌ Die drei Fragen des Daily Scrum wurden verbindlich vorgeschrieben.

Die drei Fragen wurden im Gegenteil als Vorgabe gestrichen – sie sind nur noch ein mögliches Beispiel. Insgesamt wurde der Guide 2020 kürzer, weniger präskriptiv und über die IT hinaus formuliert.

Merksatz: 2020: „Selbstverwaltend, Product Goal, nur Developers" – drei Neuerungen, ein Ziel: schlanker und selbstbestimmter.

Warum die anderen falsch sind:

Daily-Fragen waren nie Pflicht – nur ein Beispiel, kein Gesetz.

☝️ Single Wie viele Seiten umfasst der Scrum Guide 2020 ungefähr und was folgt daraus?

❌ Die Seitenzahl ist nicht festgelegt, weil es nur eine Online-Version gibt

✅ Rund 13 Seiten – Scrum ist bewusst minimal gehalten und muss durch Praktiken ergänzt werden

❌ Rund 60 Seiten – Scrum deckt alle Projektmanagementaufgaben ab

❌ Rund 130 Seiten – Scrum regelt die Produktentwicklung umfassend

Die Kürze ist Absicht, nicht Nachlässigkeit. Wer aus dem Guide eine Anleitung für jede Situation erwartet, sucht etwas, das dort bewusst nicht steht.

Sprints & Events

Sprint [Events] 10 Unterseite →

☝️ Single Was ist der Sprint in Scrum?

❌ Nur das Planungsmeeting zu Beginn

✅ Ein fester Zeitrahmen (max. 1 Monat), in dem alle anderen Events stattfinden

❌ Eine Pause zwischen zwei Releases

❌ Ein Synonym für das Daily Scrum

Der Sprint ist der Container-Event von maximal einem Monat, in dem alle anderen Events (Planning, Daily, Review, Retro) stattfinden. Ein neuer Sprint startet direkt nach dem vorigen.

✌️ Multi Welche Aussagen über den Sprint sind korrekt? (Mehrere richtig)

❌ Das Sprint-Ziel darf beliebig oft während des Sprints ausgetauscht werden

✅ Während des Sprints wird die Qualität nicht gesenkt

✅ Ein neuer Sprint beginnt unmittelbar nach dem Ende des vorherigen

✅ Ein Sprint dauert maximal einen Monat

✅ Der Umfang kann mit dem PO neu verhandelt werden, wenn mehr klar wird

Sprints sind max. 1 Monat, folgen nahtlos aufeinander, Qualität wird nicht gesenkt, und der Umfang kann bei wachsendem Wissen mit dem PO verhandelt werden. Das Sprint-Ziel bleibt aber stabil – es wird nicht beliebig ausgetauscht.

Merksatz: Der "Monats-Marathon" Sprint startet sofort, hält Qualität hoch und ist flexibel beim Umfang, aber das "Sprint-Ziel-Schild" bleibt fest!

Warum die anderen falsch sind:

Das Sprint-Ziel darf beliebig oft während des Sprints ausgetauscht werden: Das Sprint-Ziel ist ein Commitment, kein Wunschkonzert.

☝️ Single Wie lange darf ein Sprint maximal dauern?

❌ Genau zwei Wochen

❌ Maximal sechs Wochen

✅ Einen Monat oder weniger

❌ Maximal ein Quartal

Sprints dauern einen Monat oder weniger. Längere Zeiträume machen das Sprint-Ziel unscharf, erhöhen die Komplexität und verzögern Feedback.

☝️ Single Wann beginnt der nächste Sprint?

❌ Nach Freigabe durch das Management

❌ Sobald der Product Owner das Backlog fertig aufbereitet hat

❌ Nach einer Pufferwoche zur Stabilisierung

✅ Unmittelbar nach dem Abschluss des vorherigen Sprints

Sprints folgen unmittelbar aufeinander. Stabilisierungs- oder Puffersprints zwischen Sprints sind nicht Teil von Scrum.

☝️ Single Warum wird der Sprint als "Container" bezeichnet?

✅ Weil alle anderen Scrum-Events innerhalb des Sprints stattfinden

❌ Weil er alle Product-Backlog-Einträge enthält

❌ Weil er das fertige Produkt enthält

❌ Weil er die Arbeit mehrerer Teams bündelt

Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospective finden alle innerhalb des Sprints statt.

☝️ Single Darf die Sprint-Länge während eines laufenden Sprints verlängert werden, um die Arbeit noch fertigzustellen?

❌ Ja, um maximal eine Woche

❌ Ja, wenn das Sprint-Ziel sonst nicht erreicht wird

✅ Nein – die Timebox ist fix; unfertige Arbeit geht zurück ins Product Backlog

❌ Ja, wenn der Product Owner zustimmt

Eine feste Kadenz ist Voraussetzung für verlässliche Empirie. Verlängerungen verdecken Planungsprobleme, statt sie sichtbar zu machen.

✍️ Offen Mitten im Sprint stellt sich heraus, dass ein ausgewählter Backlog-Eintrag deutlich größer ist als angenommen. Das Sprint-Ziel ist dadurch gefährdet. Beschreiben Sie das scrum-konforme Vorgehen.

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.

Bewertet werden: sofortige Transparenz + Neuverhandlung des Umfangs mit dem PO + Sprint-Ziel bleibt, Umfang ist verhandelbar + explizite Nennung unzulässiger Alternativen (Verlängerung/DoD absenken) + Abbruch nur durch PO + Ursachenbehandlung in der Retrospektive.

Merksatz: „Ziel bleibt, Umfang wackelt“ – erst transparent machen (Daily), dann mit dem PO neu verhandeln: splitten, tauschen, reduzieren. Sprint-Ziel ist heilig, Umfang nicht. Verboten: Sprint verlängern, DoD senken, still überziehen. Abbruch nur durch den PO, wenn das Ziel obsolet ist. Ursache in die Retrospektive.

✍️ Offen Begründen Sie, warum ein Sprint nicht verlängert werden darf, um noch unfertige Arbeit abzuschließen, und beschreiben Sie, was stattdessen geschieht.

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.

Merksatz: Der Sprint ist ein Metronom, kein Gummiband – wer ihn dehnt, verliert den Takt und die Wahrheit.

Kern: Feste Länge = Messlatte der Empirie. Verlängern würde die Information vernichten, dass zu viel geplant wurde. Stattdessen: Sprint endet pünktlich, Fertiges wird Increment, Unfertiges zurück ins Product Backlog (PO bewertet neu), Sprint Review zeigt ehrlichen Stand, Retrospektive klärt die Fehlprognose. Länge nur für künftige Sprints änderbar, nie im laufenden.

☝️ Single Ein Team möchte die Sprint-Länge von zwei Wochen auf eine Woche verkürzen. Welcher Effekt ist am wenigsten zu erwarten?

❌ Der Druck auf die Zerlegung der Backlog-Einträge steigt

✅ Der Anteil der Zeit, der auf Events entfällt, sinkt

❌ Das Risiko je Sprint sinkt, weil weniger Arbeit gefährdet ist

❌ Feedback aus dem Sprint Review kommt häufiger

Die Timeboxen der Events skalieren mit der Sprint-Länge, der relative Anteil bleibt also etwa gleich; in der Praxis steigt er sogar leicht, weil manche Events einen Sockelaufwand haben. Die anderen drei Effekte treten tatsächlich ein.

Merksatz: Kürzere Sprints = mehr Events pro Zeit, nicht weniger – die Zeremonien bleiben gleich lang, also steigt ihr Zeitanteil.

Warum die anderen falsch sind:

Zerlegung: kleinere Sprints brauchen feinere Häppchen.

Risiko: weniger Arbeit pro Sprint = kleineres Risiko.

Review: kürzere Sprints = häufigere Reviews.

✍️ Offen Ein Team erreicht seit fünf Sprints in Folge sein Sprint-Ziel nicht. Analysieren Sie mögliche Ursachen auf verschiedenen Ebenen und beschreiben Sie, wie Sie vorgehen würden.

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.

Bewertet werden: Muster statt Einzelfall + mindestens drei Ebenen (Zielformulierung, Planung/unsichtbare Arbeit, Arbeitsfluss/Abhängigkeiten, Organisation) + datenbasierte Retrospektive + eine Änderung statt vieler + Hinweis auf Sanktionierung und ihre Folge + Nennung untauglicher Abkürzungen.

Daily Scrum [Events] 6 Unterseite →

☝️ Single Wie lange dauert das Daily Scrum und für wen ist es?

❌ 30 Minuten, geleitet vom Scrum Master

❌ So lange wie nötig, für alle Stakeholder

✅ 15 Minuten, für die Developers

❌ 1 Stunde, für das ganze Unternehmen

Das Daily Scrum ist ein 15-minütiges Event für die Developers, um den Fortschritt zum Sprint-Ziel zu inspizieren und den Plan anzupassen. Es ist kein Status-Report an das Management.

☝️ Single Wie lange dauert das Daily Scrum?

❌ 30 Minuten

❌ So lange wie nötig

❌ 15 Minuten pro Woche Sprint-Länge

✅ 15 Minuten, unabhängig von der Sprint-Länge

Das Daily Scrum ist auf 15 Minuten begrenzt – unabhängig von der Sprint-Länge und der Teamgröße.

☝️ Single Für wen ist das Daily Scrum?

❌ Für den Product Owner und die Developers

✅ Für die Developers

❌ Für den Scrum Master

❌ Für das gesamte Scrum Team plus Stakeholder

Das Daily Scrum ist ein Event der Developers. Product Owner und Scrum Master nehmen nur teil, wenn sie aktiv an Sprint-Backlog-Arbeit mitwirken.

☝️ Single Müssen im Daily Scrum die drei bekannten Fragen ("Was habe ich gestern getan...") beantwortet werden?

❌ Ja, aber nur bei Sprints über zwei Wochen

✅ Nein – der Scrum Guide 2020 schreibt keine Struktur mehr vor, das Ziel ist Fortschritt zum Sprint-Ziel

❌ Ja, die drei Fragen sind verpflichtend

❌ Nein, das Daily Scrum wurde 2020 abgeschafft

Die drei Fragen wurden 2020 gestrichen. Die Developers wählen die Struktur selbst, solange Fortschritt und Plananpassung im Mittelpunkt stehen.

☝️ Single Warum findet das Daily Scrum jeden Tag zur selben Zeit am selben Ort statt?

❌ Um die Velocity täglich messen zu können

✅ Um Komplexität und Abstimmungsaufwand zu reduzieren

❌ Weil das Management es so vorgibt

❌ Damit der Scrum Master die Anwesenheit kontrollieren kann

Ein fester Rahmen reduziert Koordinationsaufwand – niemand muss täglich Termine abstimmen.

☝️ Single Ein Daily Scrum entwickelt sich regelmäßig zu einer 45-minütigen technischen Diskussion. Was ist die passendste Reaktion?

❌ Das Daily abschaffen und durch ein Wochenmeeting ersetzen

✅ Das Daily nach 15 Minuten beenden und die Detaildiskussion direkt danach mit den Betroffenen fortsetzen

❌ Technische Themen ins Sprint Review verschieben

❌ Die Timebox dauerhaft auf 45 Minuten erhöhen

Die Timebox bleibt. Vertiefende Diskussionen finden im Anschluss statt – oft nur mit einem Teil der Developers.

Sprint Planning [Events] 5 Unterseite →

☝️ Single Welche drei Themen behandelt das Sprint Planning?

❌ Rollen, Events, Artefakte

✅ Warum ist der Sprint wertvoll? Was kann erreicht werden? Wie wird die Arbeit erledigt?

❌ Budget, Zeit, Ressourcen

❌ Wer ist schuld? Was lief schlecht? Was ändern wir?

Sprint Planning behandelt: Warum (Sprint-Ziel/Wert), Was (ausgewählte Backlog-Items) und Wie (Plan zur Umsetzung). Die zweite Option beschreibt die Retrospektive.

☝️ Single Wie lange dauert das Sprint Planning maximal bei einem einmonatigen Sprint?

❌ Zwei Stunden

❌ Einen ganzen Arbeitstag ohne feste Grenze

✅ Acht Stunden

❌ Vier Stunden

Maximal acht Stunden bei einem Monatssprint; bei kürzeren Sprints entsprechend kürzer (Faustregel: bei zwei Wochen etwa vier Stunden).

Merksatz: Ein Monat Sprint = ein Arbeitstag Planung. 8 Stunden für 4 Wochen, also 2 Stunden pro Sprintwoche – „8 für 4“.

Warum die anderen falsch sind:

Zwei Stunden: das ist die Zeit pro Sprintwoche, nicht für den ganzen Monat.

Ganzer Arbeitstag ohne Grenze: Timebox muss immer fest sein.

Vier Stunden: das gilt für einen zweiwöchigen Sprint, nicht für einen Monat.

☝️ Single Das Sprint Planning gliedert sich in drei Themen. Welche Reihenfolge ist korrekt?

❌ Vision, Roadmap, Release-Plan

❌ Umfang, Termin, Kosten

✅ Warum ist dieser Sprint wertvoll, was kann erledigt werden, wie wird die Arbeit erledigt

❌ Was wurde erledigt, was blockiert, was kommt als Nächstes

Thema 1 führt zum Sprint-Ziel, Thema 2 zur Auswahl der Backlog-Einträge, Thema 3 zum Plan der Umsetzung. Zusammen ergeben sie das Sprint Backlog.

☝️ Single Wer entscheidet, wie viele Product-Backlog-Einträge in den Sprint aufgenommen werden?

❌ Der Scrum Master

❌ Der Product Owner

✅ Die Developers

❌ Das Management nach Kapazitätsplanung

Der Product Owner bestimmt die Reihenfolge und erklärt das Ziel; wie viel davon realistisch machbar ist, entscheiden allein die Developers.

☝️ Single Wer darf zum Sprint Planning eingeladen werden?

❌ Ausschließlich die Developers

✅ Das Scrum Team kann weitere Personen einladen, um fachlichen Rat einzuholen

❌ Alle Stakeholder müssen teilnehmen

❌ Nur Mitglieder des Scrum Teams, Externe sind ausgeschlossen

Das Scrum Team kann Dritte zur Beratung hinzuziehen. Die Entscheidungen bleiben aber beim Scrum Team.

Sprint Review [Events] 6 Unterseite →

☝️ Single Was ist der Hauptzweck des Sprint Review?

❌ Den nächsten Sprint detailliert planen

✅ Das Increment inspizieren und das Product Backlog gemeinsam mit Stakeholdern anpassen

❌ Die Developers bewerten

❌ Die Zusammenarbeit im Team verbessern

Im Sprint Review inspizieren Scrum-Team und Stakeholder das Increment und passen das Product Backlog an. Die Team-Verbesserung ist Thema der Retrospektive.

☝️ Single Wie lange dauert das Sprint Review maximal bei einem einmonatigen Sprint?

✅ Vier Stunden

❌ Drei Stunden

❌ Zwei Stunden

❌ Acht Stunden

Maximal vier Stunden bei einem Monatssprint, bei kürzeren Sprints entsprechend kürzer.

Merksatz: „Review = vier“ – wie ein Viersitzer: Der Sprint Review dauert bei einem Monat Sprint maximal vier Stunden.

Warum die anderen falsch sind:

Drei Stunden – verwechselt mit Daily Scrum (15 Min.) oder falscher Kürzung.

Zwei Stunden – typische Verwechslung mit Sprint Planning Teil 2 oder Retro.

Acht Stunden – das ist die Maximaldauer des Sprint Planning bei einem Monat.

☝️ Single Was ist der Zweck des Sprint Review?

❌ Das Increment formal abzunehmen und freizugeben

❌ Dem Management den Projektstatus zu berichten

❌ Die Arbeit des Teams zu bewerten und Leistung zu beurteilen

✅ Das Ergebnis des Sprints zu inspizieren und mit den Stakeholdern das weitere Vorgehen anzupassen

Das Review ist eine Arbeitssitzung zur gemeinsamen Inspektion und Anpassung des Product Backlogs – keine Statuspräsentation und kein Abnahme-Gate.

☝️ Single Wer nimmt am Sprint Review teil?

❌ Das Scrum Team allein, Stakeholder erhalten ein Protokoll

❌ Nur die Developers

❌ Nur Product Owner und Stakeholder

✅ Das Scrum Team und die eingeladenen Stakeholder

Das Review lebt vom direkten Austausch mit den Stakeholdern – das ist seine zentrale Feedbackfunktion.

Merksatz: Sprint Review = „Marktplatz“: Das Scrum Team öffnet die Türen, Stakeholder kommen zum Schauen und Mitreden.

Warum die anderen falsch sind:

Protokoll statt Dialog: Review ist Austausch, kein Bericht.

Nur Developers: PO und SM fehlen, Feedback fehlt.

Nur PO und Stakeholder: Developers zeigen die Arbeit selbst.

☝️ Single Was ist ein typisches Ergebnis des Sprint Review?

❌ Ein fertiges Sprint Backlog für den nächsten Sprint

✅ Ein angepasstes Product Backlog

❌ Ein Maßnahmenplan zur Teamverbesserung

❌ Eine formale Freigabe des Increments durch die Stakeholder

Aus der gemeinsamen Inspektion ergeben sich Anpassungen des Product Backlogs. Teamverbesserungen sind Thema der Retrospektive.

Merksatz: Sprint Review = Produkt-Inspektion mit Stakeholdern → Ergebnis ist ein angepasstes Product Backlog. „Review zeigt, was kommt ins Backlog."

Warum die anderen falsch sind:

Sprint Backlog entsteht im Sprint Planning, nicht im Review.

Maßnahmenplan ist Ergebnis der Retrospektive.

Formale Freigabe gibt es nicht – das Increment wird nur inspiziert.

✌️ Multi Welche Aussagen über das Sprint Review treffen zu? (Mehrere richtig)

❌ Es dient der formalen Abnahme des Increments durch den Product Owner

✅ Das Increment kann bereits vor dem Review ausgeliefert worden sein

❌ Ohne teilnehmende Stakeholder entfällt das Event

✅ Auch ein Sprint mit verfehltem Sprint-Ziel hat ein Sprint Review

✅ Es ist eine Arbeitssitzung, deren Ergebnis ein angepasstes Product Backlog sein kann

Eine formale Abnahme kennt Scrum nicht; die Definition of Done entscheidet über Fertigstellung. Fehlende Stakeholder sind ein Impediment, kein Grund zum Ausfall des Events.

Sprint Retrospective [Events] 5 Unterseite →

☝️ Single Worauf zielt die Sprint Retrospective ab?

✅ Wege finden, um Qualität und Effektivität der Zusammenarbeit zu steigern

❌ Das Product Backlog priorisieren

❌ Den Sprint-Umfang festlegen

❌ Das Increment den Stakeholdern zeigen

Die Retrospektive dient dazu, wie das Team zusammenarbeitet zu inspizieren und Verbesserungen zu planen (Qualität/Effektivität). Sie ist der letzte Event im Sprint.

☝️ Single Wie lange dauert die Sprint Retrospective maximal bei einem einmonatigen Sprint?

❌ Eine Stunde

❌ Acht Stunden

❌ Vier Stunden

✅ Drei Stunden

Maximal drei Stunden bei einem Monatssprint. Sie ist damit kürzer als das Sprint Review (vier Stunden).

Merksatz: „Drei Stunden Rückblick – wie ein Fußballspiel mit Verlängerung.“ Die Retro ist der kürzeste der drei großen Sprint-Events: maximal 3 Stunden pro Monat.

Warum die anderen falsch sind:

One hour – verwechselt mit dem Daily Scrum (15 Min.).

Eight hours – das ist das Sprint Planning bei einem Monat.

Four hours – das ist die Sprint Review bei einem Monat.

☝️ Single Welches Event schließt den Sprint ab?

❌ Das letzte Daily Scrum

✅ Die Sprint Retrospective

❌ Das Sprint Review

❌ Die Übergabe des Increments

Die Retrospektive ist das letzte Event im Sprint und findet nach dem Sprint Review statt.

Merksatz: Erst Review (Produkt zeigen), dann Retro (Prozess verbessern) – die Retrospective ist das Schlusslicht, sie beendet den Sprint.

Warum die anderen falsch sind:

Letztes Daily Scrum: nur Tagesabstimmung, kein Sprintende.

Sprint Review: prüft das Increment, kommt VOR der Retro.

Increment-Übergabe: ist kein Event, sondern Ergebnis.

✌️ Multi Was wird in der Sprint Retrospective inspiziert? (Mehrere richtig)

✅ Wie die Zusammenarbeit im Team verlaufen ist

❌ Die Leistung einzelner Teammitglieder zur Beurteilung

❌ Der Umfang des nächsten Sprints

✅ Die Definition of Done und die Qualität der Arbeit

✅ Welche Prozesse und Werkzeuge geholfen oder gestört haben

Die Retrospektive betrachtet Menschen, Interaktionen, Prozesse, Werkzeuge und die Definition of Done. Sie ist kein Instrument der Leistungsbeurteilung.

Merksatz: Retrospektive = Rückspiegel fürs WIE: Zusammenarbeit, Qualität (DoD) und Prozesse/Werkzeuge – nicht fürs WER oder WAS.

Warum die anderen falsch sind:

Leistung Einzelner: Retro bewertet das Team, nie Personen.

Umfang nächster Sprint: Das ist Sprint Planning, nicht Retro.

☝️ Single Was macht das Scrum Team mit den wirksamsten Verbesserungsideen aus der Retrospektive?

❌ Es übergibt sie dem Management zur Genehmigung

❌ Es dokumentiert sie ausschließlich im Retrospektiv-Protokoll

✅ Es setzt sie so bald wie möglich um; sie können auch ins Sprint Backlog aufgenommen werden

❌ Es sammelt sie für einen jährlichen Verbesserungsworkshop

Verbesserungen wirken nur, wenn sie umgesetzt werden. Es ist üblich, mindestens eine Verbesserung ins nächste Sprint Backlog aufzunehmen.

Sprint-Abbruch [Events] 3 Unterseite →

☝️ Single Wer darf einen Sprint vorzeitig abbrechen?

❌ Der Scrum Master

❌ Die Developers per Mehrheit

✅ Nur der Product Owner

❌ Jeder Stakeholder

Nur der Product Owner hat die Autorität, einen Sprint abzubrechen – typischerweise wenn das Sprint-Ziel obsolet geworden ist.

Merksatz: Der Product Owner hält den Geldbeutel – nur er stoppt den Sprint, wenn der Wert kippt. „Nur der PO zieht den Notausgang.“

Warum die anderen falsch sind:

Scrum Master: coacht, stoppt aber nicht – kein Sprint-Abbruch-Recht.

Developers per Mehrheit: bauen, entscheiden aber nicht über Sprintende.

Jeder Stakeholder: darf ansprechen, aber nie abbrechen.

☝️ Single Wer darf einen Sprint abbrechen?

✅ Nur der Product Owner

❌ Das Management

❌ Der Scrum Master

❌ Die Developers per Mehrheit

Nur der Product Owner kann einen Sprint abbrechen – typischerweise, wenn das Sprint-Ziel obsolet geworden ist. Andere können den Abbruch anregen.

☝️ Single Was geschieht mit den fertiggestellten Teilen, wenn ein Sprint abgebrochen wird?

❌ Die Arbeit wird ungeprüft in das nächste Increment übernommen

❌ Alle Arbeit des Sprints wird verworfen

✅ Fertige, der Definition of Done entsprechende Arbeit wird überprüft und kann übernommen werden; der Rest geht zurück ins Product Backlog

❌ Alles bleibt im Sprint Backlog für den nächsten Sprint

Ein Abbruch macht Fertiges nicht wertlos. Nicht abgeschlossene Einträge werden neu geschätzt und kehren ins Product Backlog zurück.

Events [Events] 8 Unterseite →

✌️ Multi Welche Aussagen zu den Scrum-Events sind korrekt? (Mehrere richtig)

✅ Jedes Event ist eine Gelegenheit zur Inspektion und Adaption

✅ Events haben eine feste maximale Dauer (Timebox)

❌ Zwischen Sprints gibt es lange Pausen

✅ Der Sprint enthält alle anderen Events

❌ Das Daily Scrum ist ein Status-Meeting für den Manager

Der Sprint ist der Container, jedes Event dient Inspektion+Adaption und ist timeboxed. Das Daily ist KEIN Management-Status, und ein neuer Sprint beginnt direkt nach dem vorigen (keine langen Pausen).

✍️ Offen Beschreiben Sie Zweck und Ergebnis des Sprint Planning.

Musterantwort: Zweck: Der Sprint wird geplant. Behandelt werden drei Themen – Warum ist der Sprint wertvoll (Sprint-Ziel), Was kann im Sprint erledigt werden (ausgewählte Product-Backlog-Items), Wie wird die Arbeit erledigt (Plan der Developers). Ergebnis: das Sprint Backlog (Sprint-Ziel + ausgewählte Items + Plan). Timebox: max. 8 Std bei einem Monatssprint.

Bewertet werden: Zweck (Sprint planen), die drei Themen Warum/Was/Wie, Ergebnis Sprint Backlog inkl. Sprint-Ziel.

Merksatz: „W-W-W zum Sprint-Backlog“ – Warum (Sprint-Ziel), Was (ausgewählte PBIs), Wie (Plan der Developers). Drei Fragen, ein Ergebnis: das Sprint Backlog. Timebox: max. 8 Std/Monat.

☝️ Single Was gilt für die Timeboxen der Scrum-Events?

✅ Sie sind Maximalwerte – Events können früher enden, wenn ihr Zweck erfüllt ist

❌ Sie sind unverbindliche Richtwerte

❌ Sie sind Mindestwerte und müssen ausgeschöpft werden

❌ Sie gelten nur für Sprints von einem Monat

Timeboxen sind Obergrenzen. Ein Event früher zu beenden ist erlaubt, sobald sein Zweck erreicht ist.

☝️ Single Was passiert bei kürzeren Sprints mit den Timeboxen der Events?

❌ Sie verdoppeln sich, um die kürzere Laufzeit auszugleichen

❌ Sie bleiben unverändert

❌ Sie entfallen bei Sprints unter zwei Wochen

✅ Sie sind in der Regel entsprechend kürzer

Die genannten Timeboxen gelten für einen Monatssprint; bei kürzeren Sprints sind die Events üblicherweise kürzer.

✌️ Multi Welche Events sieht Scrum vor? (Mehrere richtig)

❌ Product Backlog Refinement

✅ Daily Scrum

✅ Sprint Planning

❌ Sprint Zero

✅ Sprint Review

Neben Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospective (hier nicht aufgeführt) gilt der Sprint selbst als Event. Refinement ist eine laufende Aktivität, kein Event; einen "Sprint Zero" gibt es in Scrum nicht.

☝️ Single Ein Team führt zusätzlich wöchentliche Status-Meetings mit dem Management ein. Wie ist das aus Scrum-Sicht zu bewerten?

❌ Es ist unbedenklich, solange das Daily Scrum stattfindet

✅ Es ist ein Hinweis auf fehlende Transparenz – die Scrum-Events sollten den Informationsbedarf bereits decken

❌ Es ersetzt das Sprint Review

❌ Es ist Pflicht, sobald das Management Interesse zeigt

Die Scrum-Events sind so angelegt, dass zusätzliche Statusmeetings überflüssig werden. Ihr Bedarf deutet auf mangelnde Transparenz oder fehlendes Vertrauen hin.

☝️ Single Warum sollten die Scrum-Events möglichst am selben Ort und zur selben Zeit stattfinden?

✅ Um Komplexität zu reduzieren – Termine müssen nicht jedes Mal neu abgestimmt werden

❌ Weil der Scrum Guide feste Uhrzeiten vorschreibt

❌ Damit Stakeholder jederzeit spontan teilnehmen können

❌ Damit die Timeboxen automatisch eingehalten werden

Ein gleichbleibender Rhythmus senkt Koordinationsaufwand und macht Teilnahme verlässlich planbar.

☝️ Single Ein Team hält das Sprint Review regelmäßig ohne Stakeholder ab. Welche Folge hat das?

❌ Das Event wird dadurch effizienter

✅ Der Zweck des Events entfällt weitgehend: Ohne externes Feedback wird das Product Backlog nicht auf Basis neuer Erkenntnisse angepasst

❌ Die Auswirkung ist gering, solange das Increment fertig ist

❌ Der Product Owner kann die Anpassung allein vornehmen

Das Sprint Review ist ein Arbeitstreffen mit den Stakeholdern, keine Abnahmezeremonie. Ohne sie inspiziert das Team nur sich selbst.

Sprint-Ziel [Events] 1 Unterseite →

☝️ Single Am Ende des Sprints wurden acht von zehn ausgewählten Einträgen fertiggestellt, das Sprint-Ziel ist aber vollständig erreicht. Wie ist der Sprint zu bewerten?

✅ Der Sprint war erfolgreich: Das Commitment gilt dem Sprint-Ziel, nicht der Menge ausgewählter Einträge

❌ Der Sprint war teilweise gescheitert, weil zwanzig Prozent der Zusage offen blieben

❌ Das lässt sich nicht bewerten, solange der Product Owner die Einträge nicht abgenommen hat

❌ Der Sprint war erfolgreich, aber die beiden offenen Einträge müssen in den nächsten Sprint übernommen werden

Die Auswahl im Sprint Planning ist eine Prognose, das Sprint-Ziel ist das Commitment. Auch die dritte Antwort ist falsch: Offene Einträge gehen zurück ins Product Backlog, und der Product Owner entscheidet neu über ihre Reihenfolge, statt sie automatisch fortzuschreiben.

Merksatz: Das Sprint-Ziel ist der Kompass, nicht die Packliste – wer das Ziel erreicht, hat den Sprint gewonnen, auch wenn Gepäckstücke liegen bleiben.

Warum die anderen falsch sind:

Prozentdenken: Commitment gilt dem Ziel, nicht der Item-Anzahl.

PO-Abnahme ist kein Sprint-Kriterium, sondern Teil des Increments.

Offene Items wandern nicht automatisch, sie gehen zurück ins Product Backlog.

Prüfungsreifes Wissen,
strukturiert statt gestapelt.

Fachbegriff-Glossar

Lern-Podcasts & Videos

Wichtige Modelle & Merkhilfen

Alle Prüfungsfragen Product Discovery
225 Fragen 183 Single 24 Multi 18 Offen

Fachbegriff-Glossar

Lern-Podcasts & Videos

Wichtige Modelle & Merkhilfen

Product Discovery

Alle Prüfungsfragen Product Discovery 225 Fragen 183 Single 24 Multi 18 Offen

Alle Prüfungsfragen Product Discovery
225 Fragen 183 Single 24 Multi 18 Offen