Product Backlog, Sprint Planning, Sprint Review & Retrospektive

Scrum besteht nicht nur aus Rollen. Mindestens genauso wichtig sind die wiederkehrenden Artefakte und Events, die den eigentlichen Arbeitsrhythmus eines Teams ausmachen. Product Backlog, Sprint Planning, Daily Scrum, Sprint Review und Retrospektive bilden gemeinsam den Kern der täglichen Scrum-Arbeit.

Wer versteht, wie diese vier Elemente zusammenspielen, versteht den eigentlichen Takt eines Scrum-Teams. Einen allgemeinen Überblick über Scrum als Framework – Rollen, Werte, Herkunft – bietet unser Beitrag Was ist Scrum? Der umfassende Leitfaden für Unternehmen. Dieser Artikel hier geht bewusst tiefer in die vier Elemente, die den Arbeitsalltag prägen, und begleitet dabei durchgehend ein Beispiel: die Weiterentwicklung eines Online-Shops.

Die zentrale Idee dieses Beitrags: Product Backlog, Sprint Planning, Sprint Review und Retrospektive sind keine isolierten Elemente. Sie bilden gemeinsam einen kontinuierlichen Lern- und Verbesserungszyklus, der Scrum erst erfolgreich macht.

Abb.: Der allgemeine Scrum-Flow – vom ersten Backlog-Eintrag über den täglichen Daily Scrum bis zum nächsten Sprint

Wie arbeiten Product Backlog und Scrum Events zusammen?

Das Product Backlog ist die Quelle, aus der jeder Sprint schöpft. Im Sprint Planning wählt das Team aus diesem Backlog aus, was im kommenden Sprint umgesetzt wird. Im Sprint selbst entsteht daraus ein fertiges Increment, das im Sprint Review den Stakeholdern gezeigt und mit ihrem Feedback abgeglichen wird – Feedback, das häufig direkt neue oder veränderte Backlog-Einträge zur Folge hat. Die Retrospektive schließlich blickt nicht auf das Produkt, sondern auf die Zusammenarbeit selbst und sorgt dafür, dass sich die Arbeitsweise des Teams von Sprint zu Sprint verbessert. Alle vier Elemente greifen so ineinander, dass ein Fehler in einem von ihnen fast immer auch die anderen beeinträchtigt – ein Grund, warum sie im Folgenden nicht isoliert, sondern im Zusammenhang betrachtet werden.

Was ist das Product Backlog?

Das Product Backlog ist das Herzstück der Produktentwicklung im Scrum. Es ist der Ort, an dem jede Idee, jede Anforderung und jedes Kundenfeedback zusammenläuft, bevor daraus tatsächliche Arbeit wird – und der Maßstab, an dem sich zeigt, ob ein Team an den richtigen Dingen arbeitet.

Zweck. Das Product Backlog ist die einzige Quelle für alle Anforderungen an ein Produkt. Es ist kein statischer Aufgabenkatalog, sondern ein lebendes Produktartefakt, das sich mit jedem neuen Erkenntnisgewinn verändert.

Aufbau. Ein Backlog-Eintrag beschreibt in der Regel eine Anforderung aus Nutzersicht, ergänzt um Kontext, groben Umfang und – sobald er priorisiert wird – Akzeptanzkriterien. Einträge weiter oben im Backlog sind üblicherweise kleiner und detaillierter ausgearbeitet als solche weiter unten.

Wer pflegt das Backlog? Die Verantwortung für Inhalt, Sichtbarkeit und Reihenfolge liegt beim Product Owner. Das schließt nicht aus, dass Vorschläge aus dem Team oder von Stakeholdern einfließen – die letzte Entscheidung über Priorität trifft jedoch der Product Owner.

Priorisierung. Nicht alles, was wichtig erscheint, ist gleich dringend. Priorisierung basiert idealerweise auf einer Kombination aus Kundennutzen, Geschäftswert, Risiko und Aufwand – nicht auf der Lautstärke, mit der eine Anforderung eingefordert wird.

User Stories. Eine verbreitete Form, Backlog-Einträge zu formulieren, beschreibt eine Anforderung aus Sicht einer Nutzerrolle: Wer möchte was erreichen, und warum. Diese Perspektive hält den Fokus auf dem tatsächlichen Nutzen, statt nur eine technische Funktion zu beschreiben.

Akzeptanzkriterien. Sie legen fest, wann ein Backlog-Eintrag als korrekt umgesetzt gilt. Klare Akzeptanzkriterien verhindern spätere Missverständnisse zwischen dem, was gemeint war, und dem, was tatsächlich gebaut wurde.

Backlog Refinement. Regelmäßige, meist nicht offiziell als eigenes Event definierte Termine, in denen Team und Product Owner Backlog-Einträge gemeinsam schärfen, schätzen und in überschaubare Einheiten zerlegen – idealerweise, bevor sie im Sprint Planning ausgewählt werden.

Typische Fehler. Ein zu großes, unpriorisiertes Backlog voller vager Einträge ist der häufigste Stolperstein. Ebenso verbreitet: ein Backlog, das monatelang nicht aktualisiert wird und dadurch den Bezug zur tatsächlichen Produktrealität verliert.

Praxisbeispiel: Online-Shop

Im Product Backlog eines Online-Shops steht weit oben der Eintrag "Als Kundin möchte ich beim Checkout meine Zahlungsart speichern können, damit ich beim nächsten Einkauf schneller bezahlen kann." Der Product Owner hat diesen Eintrag priorisiert, weil Auswertungen zeigen, dass ein umständlicher Checkout-Prozess die Abbruchrate erhöht. Akzeptanzkriterien legen fest, welche Zahlungsarten gespeichert werden können und wie die Sicherheit dieser Daten gewährleistet wird.

Was passiert im Sprint Planning?

Ziel. Das Sprint Planning legt fest, was im kommenden Sprint erreicht werden soll und wie das Team diese Arbeit angehen will.

Teilnehmer. Das gesamte Scrum-Team – Product Owner, Scrum Master und Developers – nimmt teil. Der Product Owner bringt priorisierte Backlog-Einträge ein, die Developers planen die konkrete Umsetzung.

Ablauf. Üblicherweise beginnt das Sprint Planning mit der Frage, warum dieser Sprint wertvoll ist, gefolgt von der Auswahl konkreter Backlog-Einträge und der Klärung, wie diese umgesetzt werden.

Sprint Goal. Das Sprintziel fasst zusammen, welchen Wert der Sprint liefern soll – ein gemeinsamer Fokuspunkt, der dem Team hilft, auch bei unerwarteten Änderungen die Richtung zu behalten.

Auswahl der Backlog Items. Das Team wählt aus dem priorisierten Backlog aus, was realistisch in den Sprint passt – basierend auf bisheriger Erfahrung, nicht auf Wunschdenken.

Aufwandsschätzung. Viele Teams nutzen relative Schätzverfahren wie Story Points, um den Umfang einzelner Einträge einzuschätzen. Wer diese und weitere Facilitation-Techniken vertiefen möchte, findet dazu Inhalte im Kurs Scrum Master – inkl. Vorbereitung auf den PSM I.

Ergebnis. Am Ende steht das Sprint Backlog: das Sprintziel, die ausgewählten Einträge und ein erster Plan zur Umsetzung.

Typische Fehler. Zu viel Arbeit für den Sprint einzuplanen, ohne reale Kapazitäten zu berücksichtigen, ist der häufigste Fehler – gefolgt von einem Sprintziel, das so vage formuliert ist, dass es keine echte Orientierung bietet.

Praxisbeispiel: Online-Shop

Das Team wählt den Checkout-Eintrag für den kommenden Sprint aus und formuliert das Sprintziel: "Kundinnen und Kunden können ihre bevorzugte Zahlungsart sicher speichern und beim nächsten Einkauf automatisch nutzen." Die Developers zerlegen die Umsetzung in kleinere technische Teilaufgaben und schätzen den Aufwand gemeinsam ein.

Was passiert im Daily Scrum?

Zwischen Sprint Planning und Sprint Review liegt das Event, das ein Scrum-Team am häufigsten durchläuft: der Daily Scrum. Anders als Planning, Review und Retrospektive findet er nicht einmal pro Sprint statt, sondern an jedem Arbeitstag – und genau deshalb wird er in vielen Darstellungen von Scrum Events übersehen, obwohl er im Alltag am meisten Raum einnimmt.

Der Daily Scrum ist auf 15 Minuten begrenzt und dient ausschließlich den Developers zur Synchronisation: Wie weit ist das Team auf dem Weg zum Sprintziel, was hat sich seit gestern verändert, und wo gibt es Hindernisse, die den Fortschritt bremsen? Teilnehmer sind die Developers selbst; Scrum Master und Product Owner können anwesend sein, moderieren oder berichten aber nicht anstelle des Teams.

Das Ergebnis eines guten Daily Scrum ist kein Statusbericht an eine externe Person, sondern ein angepasster Plan für die nächsten 24 Stunden, den das Team selbst erarbeitet. Genau hier liegt der häufigste Fehler: Sobald das Daily zu einer Reihe individueller Berichte an den Scrum Master wird, statt zu einem echten Abstimmungsgespräch im Team, verliert es seinen eigentlichen Zweck.

Praxisbeispiel: Online-Shop

Im Daily Scrum erwähnt eine Entwicklerin, dass die Anbindung an den Zahlungsdienstleister komplizierter ist als angenommen. Ein Kollege, der bereits ähnliche Integrationen umgesetzt hat, bietet spontan Unterstützung an – eine Abstimmung, die ohne das tägliche kurze Treffen erst deutlich später stattgefunden hätte.

Was passiert im Sprint Review?

Der Sprint Review ist keine reine Demo – er ist eine gemeinsame Inspektion des entstandenen Increments, bei der Team und Stakeholder gemeinsam bewerten, ob das Ergebnis tatsächlich den erwarteten Wert liefert.

Teilnehmer. Neben dem Scrum-Team nehmen relevante Stakeholder teil – Personen, deren Feedback für die weitere Ausrichtung des Produkts wichtig ist.

Ablauf. Das Team zeigt, was im Sprint fertiggestellt wurde, erläutert Hintergründe und offene Punkte, und tritt anschließend in einen offenen Dialog mit den Stakeholdern.

Feedback. Rückmeldungen aus dem Review fließen direkt in das Product Backlog ein – als neue Einträge, als Anpassung bestehender Prioritäten oder als Korrektur bisheriger Annahmen.

Stakeholder. Ihre Perspektive ist entscheidend, weil sie häufig Kontext einbringen, den das Team im Tagesgeschäft nicht automatisch hat – etwa Marktentwicklungen oder Kundenreaktionen.

Ergebnisse. Ein aktualisiertes Verständnis darüber, ob das Produkt in die richtige Richtung geht, sowie ein angepasstes, aktuelles Product Backlog.

Häufige Fehler. Wird das Review als reine Präsentation ohne echten Dialog verstanden, geht der eigentliche Zweck verloren – die gemeinsame Überprüfung, nicht die einseitige Vorführung.

Praxisbeispiel: Online-Shop

Im Sprint Review zeigt das Team die neue Checkout-Funktion live im Test-Shop. Eine Stakeholderin aus dem Kundenservice merkt an, dass Kunden häufig mehrere Zahlungsarten gleichzeitig nutzen möchten – ein Aspekt, den das Team bislang nicht bedacht hatte. Der Product Owner nimmt diesen Punkt als neuen Backlog-Eintrag auf.

Was passiert in der Retrospektive?

Die Retrospektive ist das Event, das in der Praxis am häufigsten missverstanden wird – dabei ist sie zentral für die kontinuierliche Verbesserung eines Scrum-Teams.

Ziel. Das Team reflektiert, wie die Zusammenarbeit im vergangenen Sprint funktioniert hat – bei Menschen, Prozessen und Werkzeugen – und legt konkrete Verbesserungen fest.

Teilnehmer. Das Scrum-Team selbst, ohne externe Stakeholder, um einen geschützten Rahmen für offene Kommunikation zu schaffen.

Ablauf. Typischerweise sammelt das Team zunächst Beobachtungen, identifiziert gemeinsam Muster und Ursachen, und einigt sich anschließend auf wenige konkrete Maßnahmen.

Maßnahmen. Wirksame Retrospektiven enden mit ein bis zwei überprüfbaren Maßnahmen, die aktiv in den nächsten Sprint eingeplant werden – nicht mit einer langen Liste guter Vorsätze.

Psychologische Sicherheit. Offene, ehrliche Retrospektiven setzen voraus, dass Teammitglieder Probleme ansprechen können, ohne negative Konsequenzen befürchten zu müssen. Ohne dieses Vertrauen bleiben Retrospektiven oberflächlich.

Kontinuierliche Verbesserung. Die Retrospektive ist der strukturelle Ort, an dem Scrum sein empirisches Grundprinzip – Transparenz, Überprüfung, Anpassung – auf die eigene Zusammenarbeit anwendet.

Häufige Fehler. Retrospektiven, die aus Zeitdruck ausfallen oder auf oberflächliche Aussagen reduziert werden, sowie Maßnahmen, die zwar besprochen, aber nie tatsächlich umgesetzt werden.

Praxisbeispiel: Online-Shop

In der Retrospektive stellt das Team fest, dass die Checkout-Funktion knapper fertig wurde als geplant, weil eine technische Abhängigkeit zum Zahlungsdienstleister unterschätzt wurde. Als Maßnahme vereinbart das Team, externe Abhängigkeiten künftig bereits im Backlog Refinement explizit zu kennzeichnen – eine kleine, aber konkret überprüfbare Verbesserung für den nächsten Sprint.

Wie greifen diese Elemente ineinander?

Element	Zweck	Ergebnis
Product Backlog	Arbeit sammeln und priorisieren	Geordnetes, aktuelles Backlog
Sprint Planning	Sprint vorbereiten	Sprint Goal und Sprint Backlog
Sprint Review	Produkt überprüfen	Feedback und aktualisiertes Backlog
Retrospektive	Zusammenarbeit verbessern	Konkrete Maßnahmen für den nächsten Sprint

Scrum Events im Überblick

Event	Ziel	Teilnehmer	Ergebnis
Sprint Planning	Sprint vorbereiten	Scrum-Team	Sprint Goal, Sprint Backlog
Daily Scrum	Fortschritt synchronisieren	Developers	Angepasster Plan für die nächsten 24 Stunden
Sprint Review	Increment überprüfen	Scrum-Team und Stakeholder	Feedback, aktualisiertes Backlog
Retrospektive	Zusammenarbeit reflektieren	Scrum-Team	Konkrete Verbesserungsmaßnahmen

Welches Scrum Event beantwortet welche Frage?

Ein einfacher Weg, sich die Logik der Events zu merken: Jedes Element beantwortet eine eigene, klar abgegrenzte Frage.

Element	Leitfrage
Product Backlog	Was könnte gebaut werden?
Sprint Planning	Was bauen wir jetzt?
Daily Scrum	Wie kommen wir voran?
Sprint Review	Haben wir Wert geliefert?
Retrospektive	Wie werden wir besser?

Wie lange dauern die Scrum Events?

Die Timeboxes richten sich nach der Sprintlänge – die folgenden Werte gelten als Richtwert für einen zweiwöchigen Sprint.

Event	Typische Dauer
Sprint Planning	bis zu 4 Stunden
Daily Scrum	15 Minuten (täglich)
Sprint Review	bis zu 2 Stunden
Retrospektive	bis zu 1,5 Stunden

Product Backlog vs. Sprint Backlog – der Unterschied

Beide Begriffe werden häufig verwechselt, meinen jedoch grundlegend Verschiedenes.

Product Backlog	Sprint Backlog
Enthält alle Anforderungen an das gesamte Produkt	Enthält nur die für den aktuellen Sprint ausgewählten Einträge
Verantwortet vom Product Owner	Verantwortet von den Developers
Verändert sich fortlaufend, ohne festen Rhythmus	Gilt für die Dauer eines einzelnen Sprints
Enthält Product Goal und langfristige Perspektive	Enthält Sprint Goal und konkreten Umsetzungsplan

Backlog Lifecycle

Ein einzelner Backlog-Eintrag durchläuft typischerweise mehrere Stationen, bevor er als fertig gilt.

Idee → Backlog-Eintrag → Refinement → Sprint Backlog → Done

Ein Eintrag beginnt als grobe Idee, wird im Refinement geschärft und mit Akzeptanzkriterien versehen, gelangt bei ausreichender Priorität ins Sprint Backlog und wird dort umgesetzt, bis er die Definition of Done erfüllt.

Der Feedback Loop zwischen Review und Backlog

Sprint Review → Stakeholder-Feedback → Product Backlog → nächster Sprint

Dieser Kreislauf ist der Grund, warum das Product Backlog nie als abgeschlossen gilt: Jedes Sprint Review speist neue Erkenntnisse zurück in das Backlog, wodurch der nächste Sprint auf einer aktuelleren Grundlage geplant werden kann als der vorherige.

Typische Fehler in den Scrum Events

Fehler in einem Event wirken sich häufig auf die nachfolgenden aus – ein Grund, warum sich Probleme in Scrum-Teams oft wie eine Kettenreaktion anfühlen.

Backlog zu groß → Planning ohne Prioritäten → Review nur Präsentation → Retro ohne Maßnahmen

Ein unpriorisiertes, zu großes Backlog erschwert bereits das Sprint Planning, weil kaum erkennbar ist, was wirklich wichtig ist. Ein Planning ohne klare Prioritäten führt zu einem Sprint ohne echten Fokus. Dieser unklare Fokus zeigt sich im Review häufig darin, dass nur präsentiert statt diskutiert wird, weil das eigentliche Ziel des Sprints nie klar war. Und wenn selbst diese Probleme in der Retrospektive nicht in konkrete Maßnahmen münden, wiederholt sich die gesamte Kette im nächsten Sprint erneut.

Ein Sprint auf einen Blick

Backlog → Planning → 2 Wochen Sprint (mit täglichem Daily) → Review → Retro → neuer Sprint

Diese Kompaktansicht zeigt, wie sich ein einzelner Sprint tatsächlich anfühlt: ein kurzer Planungsauftakt, mehrere Wochen fokussierter Arbeit mit täglicher Synchronisation, und ein klar abgegrenzter Abschluss aus Review und Retrospektive, bevor der nächste Zyklus beginnt.

Warum die Reihenfolge wichtig ist

Die vier Elemente funktionieren nicht nur zusammen, sondern auch nur in dieser bestimmten Reihenfolge – und das ist kein Zufall. Ein Sprint Planning ohne vorheriges, gepflegtes Product Backlog hätte schlicht keine Grundlage: Das Team müsste im Planning selbst improvisieren, was eigentlich längst vorbereitet sein sollte. Ebenso wenig ergibt ein Sprint Review Sinn, bevor überhaupt ein Sprintziel definiert wurde – ohne Sprint Goal fehlt der Maßstab, an dem sich das Ergebnis messen lässt.

Auch die Retrospektive am Ende ist kein Zufall der Reihenfolge: Sie braucht die Erfahrungen aus dem gesamten Sprint, um sinnvoll reflektieren zu können, weshalb sie erst nach dem Sprint Review stattfindet – nicht davor und nicht parallel. Wer versucht, diese Reihenfolge zu verkürzen oder Schritte auszulassen, etwa Sprint Planning ohne vorheriges Refinement des Backlogs, wird die fehlende Vorarbeit an anderer Stelle im Sprint teuer nachholen müssen.

Best Practices für erfolgreiche Scrum Events

Gute Vorbereitung. Ein gepflegtes Backlog macht jedes nachfolgende Event leichter und schneller.
Klare Ziele. Jedes Event sollte einen erkennbaren Zweck haben, den alle Teilnehmenden verstehen.
Fokus. Diskussionen, die nicht in das jeweilige Event gehören, gehören konsequent ausgelagert.
Timeboxing. Feste Zeitrahmen schützen vor ausufernden Diskussionen und erhalten die Energie im Team.
Aktive Beteiligung. Events funktionieren nur, wenn alle Teilnehmenden tatsächlich mitdenken, statt passiv zuzuhören.
Nachbereitung. Ergebnisse aus Review und Retrospektive sollten sichtbar in Backlog und nächsten Sprint einfließen, statt in Notizen zu verschwinden.

Häufige Fragen

Wie lange dauert das Sprint Planning? Für einen zweiwöchigen Sprint sind in der Praxis etwa vier Stunden üblich, proportional angepasst an die tatsächliche Sprintlänge.

Wer nimmt am Sprint Review teil? Das gesamte Scrum-Team sowie die Stakeholder, deren Feedback für die weitere Produktentwicklung relevant ist.

Muss jede Retrospektive gleich ablaufen? Nein. Unterschiedliche Formate – von einfachen Fragerunden bis zu strukturierten Moderationstechniken – helfen, Retrospektiven abwechslungsreich und wirksam zu halten.

Wie oft wird das Backlog gepflegt? Kontinuierlich, meist ergänzt durch regelmäßige Refinement-Termine außerhalb der offiziellen Scrum-Events, oft ein- bis zweimal pro Sprint.

Fazit

Die einzelnen Scrum Events entfalten ihren Wert nicht isoliert. Erst ihr Zusammenspiel – ein gepflegtes Backlog, ein fokussiertes Planning, ein ehrliches Review und eine wirksame Retrospektive – schafft die Transparenz, das kontinuierliche Lernen und die erfolgreiche Produktentwicklung, für die Scrum steht.

Aus unserer Erfahrung

Teams, die eines dieser vier Elemente konsequent vernachlässigen, spüren die Folgen meist zuerst in einem ganz anderen Element – ein schwaches Backlog zeigt sich oft erst im chaotischen Sprint Planning, eine wirkungslose Retrospektive erst in wiederkehrenden Problemen im nächsten Review.

Möchten Sie Ihr Team gezielt auf den täglichen Scrum-Rhythmus vorbereiten? Einen Überblick über alle Schulungen finden Sie in unserer Kategorie Scrum Schulungen.

Passende Scrum Schulungen

Weitere Fachartikel zum Thema Scrum

Grundlagen & Einführung

Rollen & Zusammenarbeit

Scrum im Arbeitsalltag