Der Ablauf eines Scrum- Prozesses
Scrum- Framework
Der folgende Abschnitt beschreibt den Scrum-Prozess mit seinen zentralen Rollen, Artefakten und Events. Neben dem Ablauf und der Bedeutung der einzelnen Scrum-Events werden auch typische Hindernisse und Herausforderungen beleuchtet, die in der Praxis häufig auftreten. Dadurch erhältst du einen vollständigen Einblick in den idealen Scrum- Ablauf sowie die realen Stolpersteine, die Teams im Alltag begegnen.
Der Product Backlog – Strategische Grundlage der Produktentwicklung
Ziel des Product Backlogs
Das Product Backlog ist eine dynamische, priorisierte Liste aller bekannten Anforderungen an das Produkt. Es dient als zentrale Arbeitsgrundlage für das Scrum-Team und stellt sicher, dass jederzeit an den aus Sicht des Unternehmens wertvollsten Inhalten gearbeitet wird.
Teilnehmer
Product Owner (verantwortlich), Scrum Team (zur Klärung technischer Zusammenhänge und Machbarkeit), Stakeholder:innen (zur Bedarfsklärung, optional eingebunden).
Aufgaben der Teilnehmer im Scrum Team
Product Owner: Erstellt, pflegt und priorisiert das Product Backlog. Er stellt sicher, dass die Einträge klar formuliert, verstanden und geschätzt sind.
Developer:innen: Unterstützen bei der Einschätzung von Komplexität, Aufwand und technischer Umsetzbarkeit.
Scrum Master: Unterstützt den Product Owner bei der Anwendung agiler Prinzipien, stellt Transparenz sicher und moderiert bei Bedarf die Kommunikation mit Stakeholder:innen.
Durchführung
Die Erstellung des Product Backlogs beginnt vor dem ersten Sprint und wird kontinuierlich fortgeführt und gepflegt. Neue Erkenntnisse aus Sprints, Nutzerfeedback oder Marktveränderungen fließen regelmäßig ein. Dieses Product Backlog Refinement ist ein fortlaufender Prozess, um Klarheit und Priorisierung sicherzustellen.
Typische Hindernisse bei der Erstellung des Product Backlogs
Unklare Produktvision oder Zielsetzung
Ohne ein klares Ziel ist es schwer, sinnvolle und priorisierte Einträge zu formulieren.
Unzureichende Einbindung von Stakeholder:innen
Fehlende Rückmeldung oder mangelndes Engagement führen zu unvollständigen oder irrelevanten Anforderungen.
Fehlendes Verständnis der Nutzerbedürfnisse
Wenn kein direkter Nutzerkontakt stattfindet, basiert das Backlog oft auf Annahmen statt validierten Erkenntnissen.
Überfrachtetes oder zu detailliertes Backlog
Zu viele Einträge oder zu früh ausgearbeitete Details führen zu Intransparenz und Verzögerungen.
Mangelnde Priorisierung
Ohne klare Prioritäten wird das Backlog unübersichtlich und das Team arbeitet womöglich nicht am wertvollsten Thema.
Technische oder fachliche Unsicherheit
Wenn das Scrum-Team nicht frühzeitig in die Backlog- Erstellung einbezogen wird, fehlt die Einschätzung zur Machbarkeit oder zum Aufwand.
Abhängigkeiten zu anderen Teams oder Systemen
Wenn externe Abhängigkeiten nicht erkannt oder berücksichtigt werden, können wichtige Einträge blockiert sein.
Unklare Rollenverteilung
Wenn unklar ist, wer für das Backlog verantwortlich ist, entstehen Konflikte oder es wird gar nicht gepflegt.
Fehlende Zeit für regelmäßiges Refinement
Ohne kontinuierliche Pflege veraltet das Backlog schnell und verliert seine Aussagekraft.
Kulturelle Widerstände gegen Transparenz
Wenn eine Organisation nicht gewohnt ist, offen über Anforderungen und Prioritäten zu sprechen, bleibt das Backlog oberflächlich oder politisch geprägt.
Die im Zusammenhang mit der Erstellung des Product Backlogs auftretenden Hindernisse und mögliche Lösungsansätze werden in Das Produkt- Backlog richtig formulieren – Klarheit für agiles Arbeiten schaffen, noch ausführlich beschrieben.
Der Sprint – Das Herzstück des Scrum Frameworks
Ziel des Sprints
Der Sprint bildet den zentralen Rahmen, in dem alle Aktivitäten des Scrum-Teams stattfinden. Ziel ist es, innerhalb eines festen Zeitraums ein wertvolles Increment zu liefern – also ein fertiges, potenziell auslieferbares Produktstück. Der Sprint fördert Transparenz, kontinuierliches Lernen und fokussiertes Arbeiten. Er schafft einen geschützten Raum für Planung, Umsetzung, Überprüfung und Anpassung.
Teilnehmer
Scrum Team (Product Owner, Scrum Master, Developer:innen) Stakeholder:innen (bei Bedarf, insbesondere im Sprint Review)
Aufgaben der Teilnehmer
Product Owner: Stellt sicher, dass das Sprint-Ziel mit dem Product Backlog abgestimmt ist und die Items mit dem höchsten Wert priorisiert sind.
Developer:innen: Planen und liefern ein funktionierendes Increment. Sie organisieren sich selbst, um die Sprint-Ziele zu erreichen.
Scrum Master: Schützt das Team vor externen Störungen, sorgt für die Einhaltung der Scrum- Prinzipien und unterstützt bei der kontinuierlichen Verbesserung.
Durchführung
Ein Sprint ist ein zeitlich festgelegter Zyklus von maximal einem Monat (typischerweise 1–4 Wochen), der alle Scrum- Events umfasst:
Sprint Planning: Startet den Sprint mit einer gemeinsamen Zieldefinition und Auswahl von Backlog Items.
Daily Scrum: Tägliches 15-minütiges Meeting zur Synchronisation und Anpassung des Plans.
Sprint Review: Am Ende des Sprints wird das Increment mit Stakeholder:innen begutachtet und Feedback eingeholt.
Sprint Retrospektive: Abschließende Reflexion des Teams zur Verbesserung der Zusammenarbeit und Prozesse.
Der Sprint beginnt unmittelbar nach dem vorherigen und endet nie vorzeitig. Änderungen während des Sprints sind nur möglich, wenn sie das Sprint- Ziel nicht gefährden.
Typische Hindernisse im Sprint-Prozess
Unklar formuliertes oder zu breit gefasstes Sprint-Ziel
Führt zu Fokusverlust und unklarem Arbeitsauftrag.
Überambitionierte Sprint-Planung
Zu viele oder zu komplexe Backlog Items werden eingeplant.
Fehlende Einbindung des Product Owners im Sprint
Entscheidungen verzögern sich, Klarheit über Anforderungen fehlt.
Störungen von außen (z. B. ad-hoc-Anfragen, Kontextwechsel)
Unterbrechen den Arbeitsfluss und gefährden das Sprint-Ziel.
Unzureichende technische Infrastruktur oder Tools
Verlangsamen die Umsetzung oder verhindern die Lieferung eines Increments.
Ungenutzte Retrospektiven
Chancen zur Verbesserung bleiben ungenutzt, Dysfunktionen verstetigen sich.
Fehlende Definition of Done (DoD)
Unterschiedliche Auffassungen über den Fertigstellungsgrad führen zu Unsicherheit im Team.
Vertiefende Informationen zu typischen Herausforderungen im Sprint-Prozess sowie praxisnahe Lösungsansätze findest du im Inhaltsverzeichnis.
Sprint Planning – Klarer Start in den Sprint
Ziel des Meetings
Das Sprint Planning definiert den Arbeitsumfang für den kommenden Sprint und schafft ein gemeinsames Verständnis darüber, was erreicht werden soll und wie die Umsetzung erfolgt. Das Ergebnis ist ein klar formuliertes Sprint-Ziel, eine Auswahl an Product-Backlog-Einträgen und ein konkreter Umsetzungsplan – zusammen bilden sie das Sprint Backlog.
Teilnehmer
Scrum Team (Scrum Master, Product Owner, Developer:innen)
Optional: externe Expert:innen bei spezifischem Fachbedarf
Aufgaben der Teilnehmer
Product Owner: Stellt priorisierte Product-Backlog-Einträge vor und erklärt deren geschäftlichen Mehrwert.
Developer:innen: Schätzen den Umfang ein, wählen machbare Einträge aus und planen die Umsetzung.
Scrum Master: Moderiert das Meeting, achtet auf die Einhaltung der Scrum-Prinzipien und sorgt für einen strukturierten Ablauf.
Durchführung – Drei Leitfragen strukturieren das Planning:
Warum ist dieser Sprint wertvoll?
Der Product Owner schlägt ein Sprint-Ziel vor, das den Fokus und den geschäftlichen Nutzen des Sprints klar macht.
Was kann im Sprint erreicht werden?
Das Team analysiert die priorisierten Backlog-Einträge und wählt realistische Aufgaben auf Basis der verfügbaren Kapazität.
Wie wird die Arbeit umgesetzt?
Die Developer:innen planen die Umsetzung – oft durch Aufteilung in kleinere Aufgaben, die innerhalb des Sprints abgeschlossen werden können.
Zeitlicher Rahmen
Maximal acht Stunden bei einem vierwöchigen Sprint. Kürzere Sprints haben entsprechend kürzere Planning- Zeiten.
Typische Herausforderungen im Sprint Planning
Unklare oder ungepflegte Backlog-Einträge
Erschweren die Auswahl und führen zu Missverständnissen.
Fehlendes oder schwammiges Sprint-Ziel
Beeinträchtigt die Ausrichtung und den Fokus des Teams.
Unrealistische Kapazitätsplanung
Führt zu Überlastung oder ineffizienter Sprint-Nutzung.
Schlechte Vorbereitung
Verlängert das Meeting und lässt wichtige Fragen offen.
Unklare Moderation oder Rollenverteilung
Kann Diskussionen entgleisen lassen oder zu Unklarheit über Zuständigkeiten führen.
Weitere Tipps und Informationen zum Sprint Planning findest du in „Realistische Planung auf Basis der Team- Velocity“ und „Mit der Definition of Ready zu besseren Sprint- Plannings“
Daily Scrum – Tägliche Ausrichtung für maximale Transparenz
Ziel des Daily Scrums
Das Daily Scrum dient der täglichen Synchronisation des Developer- Teams. Es schafft Transparenz über den Fortschritt in Richtung Sprint-Ziel und ermöglicht es dem Team, sich schnell auf veränderte Bedingungen einzustellen und Hindernisse frühzeitig zu erkennen.
Teilnehmer
Developer:innen (verantwortlich), Scrum Master (optional unterstützend), Product Owner (optional, meist als Zuhörer:in).
Aufgaben der Teilnehmer
Developer:innen: Berichten über den Fortschritt seit dem letzten Daily, planen die Arbeit bis zum nächsten Daily und identifizieren mögliche Hindernisse.
Ziel ist es, gemeinsam Verantwortung für das Sprint-Ziel zu übernehmen und die Zusammenarbeit effizient zu koordinieren.
Scrum Master: Achtet darauf, dass das Daily Scrum stattfindet und im vorgegebenen Zeitrahmen (max. 15 Minuten) bleibt. Unterstützt bei Bedarf, wenn Hindernisse erkannt werden. Moderiert nur bei Bedarf – das Event gehört dem Developer-Team.
Product Owner: Nimmt bei Bedarf teil, hält sich jedoch mit Eingriffen zurück, um den Fokus der Developer:innen nicht zu stören.
Durchführung
Das Daily Scrum findet an jedem Arbeitstag des Sprints zur gleichen Zeit und am gleichen Ort statt – bevorzugt im Stehen, um es kurz und fokussiert zu halten. Die Struktur ist flexibel, häufig orientieren sich Teams an drei Leitfragen:
Was habe ich seit dem letzten Daily erreicht?
Was werde ich bis zum nächsten Daily tun?
Gibt es Hindernisse, die mich an der Arbeit hindern?
Das Event dient nicht zur Statusabgabe gegenüber dem Scrum Master oder Product Owner, sondern zur Selbstorganisation und Ausrichtung im Team.
Typische Hindernisse und Fehler beim Daily Scrum
Daily wird zur Statusabgabe
Statt sich gegenseitig zu synchronisieren, berichten einzelne Teammitglieder nur gegenüber dem Scrum Master oder Product Owner – die Selbstorganisation bleibt auf der Strecke.
Dominanz einzelner Personen
Einzelne Teilnehmer:innen reden zu viel oder unterbrechen andere – das verhindert eine ausgewogene Teamkommunikation und hemmt das Vertrauen.
Kein klarer Fokus auf das Sprint-Ziel
Die Beiträge sind zu allgemein oder schweifen ab, ohne erkennbaren Bezug zum Sprint-Ziel – das schwächt die Ausrichtung des Teams.
Keine Konsequenz bei auftretenden Hindernissen
Probleme werden zwar genannt, aber nicht weiterverfolgt – das führt dazu, dass sie im Tagesgeschäft untergehen.
Fehlende Vorbereitung oder passive Teilnahme
Wenn Teammitglieder unvorbereitet sind oder das Daily als Pflichttermin ansehen, leidet die Qualität und der Nutzen des Events.
Unregelmäßige Durchführung oder wechselnde Uhrzeiten
Ein fehlender Rhythmus schwächt die Verlässlichkeit und senkt die Verbindlichkeit innerhalb des Teams.
Zu lange oder zu kurze Dauer
Wird das Daily überzogen, verliert es an Effizienz. Ist es zu kurz und oberflächlich, geht wertvolle Information verloren.
Technische Hürden bei Remote-Teams
Schlechte Ton- oder Bildqualität, kein aktives Einbeziehen remote zugeschalteter Teilnehmer:innen – das erschwert die gleichberechtigte Teilnahme.
Falscher Ort oder Störungen durch Dritte
Wenn das Daily in unruhiger Umgebung stattfindet oder regelmäßig gestört wird, leidet der Fokus und das Engagement sinkt.
Unklare Verantwortung für die Durchführung
Wenn niemand den Rahmen wahrt (Zeit, Struktur, Pünktlichkeit), verwässert das Daily und wird ineffektiv.
Sprint Review – Gemeinsame Bewertung und Ausrichtung
Ziel des Meetings
Das Sprint Review dient dazu, die im Sprint erzielten Ergebnisse zu überprüfen, das entstandene Product Increment zu präsentieren und gezielt Feedback von Stakeholder:innen einzuholen. Ziel ist es, den aktuellen Stand in Bezug auf das Produkt-Ziel gemeinsam zu bewerten, Transparenz zu schaffen und gemeinsam potenzielle Anpassungen für die weitere Produktentwicklung zu identifizieren.
Dabei handelt es sich nicht um eine reine Präsentation, sondern um ein arbeitsorientiertes, interaktives Event, bei dem der Austausch im Mittelpunkt steht. Das Scrum Team erhält durch das Feedback der Stakeholder:innen die Möglichkeit, den Kurs auf Basis neuer Erkenntnisse gezielt anzupassen und das Product Backlog weiterzuentwickeln. Das Review stärkt somit nicht nur die kontinuierliche Verbesserung, sondern sichert auch die gemeinsame Ausrichtung aller Beteiligten auf die Produktvision und fördert das Verständnis für den aktuellen Fortschritt.
Teilnehmer
Scrum Team (Product Owner, Scrum Master, Developer:innen)
Stakeholder:innen
Aufgaben der Teilnehmer
Product Owner: Erläutert den Fortschritt in Richtung des Produkt-Ziels und ordnet die Ergebnisse in den Gesamtzusammenhang ein.
Developer:innen: Präsentieren die fertigen Increments und beantworten Fragen zu Umsetzung, Funktionalität oder Technik.
Stakeholder:innen: Geben konstruktives Feedback, stellen Rückfragen und diskutieren gemeinsam mit dem Team mögliche nächste Schritte.
Scrum Master: Moderiert das Meeting, achtet auf die Einhaltung der Timebox und unterstützt einen offenen, respektvollen Dialog.
Durchführung
Vorstellung der abgeschlossenen Increments
Diskussion über relevante Veränderungen (z. B. Markt, Nutzerfeedback, strategische Rahmenbedingungen)
Identifikation und Priorisierung möglicher Anpassungen für kommende Sprints
Timebox: Maximal 4 Stunden bei einem einmonatigen Sprint (kürzer bei kürzeren Sprints)
Organisatorische Empfehlungen
Räumlichkeiten: Angemessen groß, technisch ausgestattet, mit angenehmer Atmosphäre
Logistik: Anfahrt, Parkmöglichkeiten, ggf. Verpflegung oder Raumkosten im Vorfeld klären
Struktur & Ablauf:
Gliederung in sinnvolle Phasen (z. B. Präsentation, Feedback, Diskussion)
Nutzung visueller Hilfsmittel wie Boards, digitale Tools oder Diagramme
Moderation durch den Scrum Master, um aktive Beteiligung zu sichern
Rolle der Stakeholder:innen
Stakeholder:innen sind aktive Mitgestalter:innen des Sprint Reviews – nicht bloß Zuschauer:innen.
Ihre Aufgaben:
Feedback geben zur Qualität und Zielerreichung der präsentierten Ergebnisse
Fragen stellen zur Klärung technischer oder fachlicher Aspekte
Zukunft mitgestalten durch Diskussion neuer Anforderungen oder veränderter Prioritäten
Der Scrum Master sorgt dabei für eine ausgewogene Beteiligung, fördert einen konstruktiven Austausch und stellt sicher, dass alle Stimmen Gehör finden.
Typische Hindernisse beim Sprint Review
Fehlende oder passive Stakeholder:innen
Geringe Beteiligung führt zu fehlendem Feedback und sinkender Relevanz des Meetings.
Sprint Review wird als reine Präsentation verstanden
Der interaktive Austausch fehlt, und Chancen zur Verbesserung werden nicht genutzt.
Unklare Zielsetzung oder fehlende Agenda
Das Meeting verläuft unstrukturiert, wichtige Themen bleiben unbesprochen.
Technische Probleme oder ungeeignete Räumlichkeiten
Präsentationen scheitern an schlechter Ausstattung oder Störungen im Ablauf.
Unvollständige oder nicht lauffähige Increments
Verwirrung entsteht, und das Vertrauen der Stakeholder:innen leidet.
Unzureichende Moderation durch den Scrum Master
Diskussionen entgleiten, Timeboxing wird nicht eingehalten.
Mangel an Vorbereitung im Team
Ergebnisse sind nicht durchdacht präsentiert, Visualisierungen fehlen.
Dominanz einzelner Personen
Andere Stimmen werden übergangen, der Dialog ist unausgewogen.
Fehlende Dokumentation von Feedback
Erkenntnisse gehen verloren, das Product Backlog bleibt unverändert.
Verwechslung mit der Retrospektive
Team-interne Reflexionen ersetzen den Austausch mit Stakeholder:innen.
Im Kapitel „Hindernisse aus dem Sprint Review gezielt angehen“ werden weitere Hinweise und Lösungsmöglichkeiten aufgezeigt.
Sprint Retrospektive – Gemeinsame Reflexion zur kontinuierlichen Verbesserung
Ziel des Meetings
Die Sprint Retrospektive dient dem Scrum Team zur Reflexion der Zusammenarbeit im vergangenen Sprint. Ziel ist es, Erfolge und Herausforderungen offen zu besprechen, Verbesserungsmöglichkeiten zu identifizieren und konkrete Maßnahmen zur Optimierung des Arbeitsprozesses zu vereinbaren. Die Retrospektive fördert Transparenz, Vertrauen und kontinuierliches Lernen.
Teilnehmer
Scrum Team (Scrum Master, Product Owner, Developer:innen)
Optional: Externe Expert:innen
Aufgaben der Teilnehmer
Developer:innen: Bringen ehrliches Feedback zur Zusammenarbeit, Prozessen und Tools ein, teilen Beobachtungen und Ideen zur Verbesserung.
Product Owner: Reflektiert das eigene Verhalten und die Zusammenarbeit mit dem Team, hört aktiv zu und beteiligt sich konstruktiv.
Scrum Master: Moderiert die Retrospektive, schafft einen sicheren Raum für Offenheit, sorgt für Struktur und verfolgt die Umsetzung beschlossener Maßnahmen.
Durchführung – Drei Leitfragen strukturieren die Retrospektive
Was lief gut im letzten Sprint?
Erfolge, positive Erfahrungen und gelungene Teamarbeit werden gewürdigt.
Was lief nicht so gut?
Herausforderungen, Probleme oder wiederkehrende Hindernisse werden benannt.
Was wollen wir verbessern?
Das Team entwickelt gemeinsam umsetzbare Maßnahmen für den nächsten Sprint.
Zeitlicher Rahmen
Maximal drei Stunden bei einem vierwöchigen Sprint. Kürzere Sprints erfordern entsprechend kürzere Retrospektiven.
Typische Herausforderungen in der Sprint Retrospektive
Mangelnde Offenheit oder Vertrauen
Verhindert ehrliche Diskussionen und sinnvolle Erkenntnisse.
Wiederholende Kritik ohne Veränderung
Frustriert das Team und untergräbt die Wirksamkeit des Meetings.
Unklare oder unrealistische Maßnahmen
Bleiben folgenlos oder werden nicht umgesetzt.
Zeitdruck oder fehlende Struktur
Führt zu oberflächlicher Reflexion oder reinen Schuldzuweisungen.
Dominanz einzelner Stimmen
Unterdrückt Perspektiven und reduziert die Vielfalt an Ideen.
Die Methoden zur Beantwortung dieser Fragen variieren je nach Teamdynamik (z. B. Start-Stop-Continue, Mad-Sad-Glad, 4L, Lean Coffee). Diese Varianten werden in den Abschnitten näher beschrieben – Ursachen sichtbar machen – Die Fischgrätenanalyse im agilen Coaching und Inspirierende Retrospektiven – Frischer Wind für den Rückblick.