Sprint-Durchfuehrung: Der vollstaendige Leitfaden 2025 fuer Scrum-Teams

Q: Wie unterscheidet sich die Sprint-Durchfuehrung zwischen Software-Entwicklungsteams und Nicht-Software-Scrum-Teams?

Obwohl die Prinzipien der Sprint-Durchfuehrung branchenuebergreifend gleich sind - Daily Scrum, Sprint-Backlog-Management, Definition of Done, Sprint-Ziel-Fokus - unterscheiden sich die spezifischen Aktivitaeten erheblich. Nicht-Software-Teams (Marketing, HR, Produktdesign, Betrieb) organisieren sich immer noch selbst, halten Daily Scrums ab und arbeiten auf ein Sprint-Ziel hin, aber ihre 'Done'-Kriterien konzentrieren sich auf Liefergegenstaende wie abgeschlossene Kampagnen, finalisierte Richtlinien, genehmigte Designs oder geloeste Service-Tickets. Der Schluessel-Unterschied ist, dass Nicht-Software-Teams oft weniger Moeglichkeiten fuer kontinuierliche Integration und automatisierte Verifizierung haben, daher basiert ihre Definition of Done staerker auf Peer-Review, Stakeholder-Abnahme und manueller Validierung.

Q: Kann ein Sprint waehrend der Durchfuehrung abgebrochen werden, und wer hat die Befugnis dazu?

Ja, ein Sprint kann waehrend der Durchfuehrung abgebrochen werden, aber nur der Product Owner hat die Befugnis dazu - nicht die Entwickler oder der Scrum Master. Ein Sprint wird abgebrochen, wenn das Sprint-Ziel obsolet wird, was passieren kann, wenn sich die Geschaeftsrichtung dramatisch aendert, eine wichtige technologische Abhaengigkeit vollstaendig scheitert oder ein Marktereignis das Sprint-Ziel irrelevant macht. Sprint-Absagen sind selten und sollten als Ausnahmemassnahme behandelt werden. Wenn ein Sprint abgebrochen wird, ueberprueft das Team alle abgeschlossenen Arbeiten, die die Definition of Done erfuellen, und die verbleibenden Sprint-Backlog-Items werden neu geschaetzt und ins Product Backlog zurueckgefuehrt.

Q: Wie sollte ein Scrum-Team mit einem kritischen Produktions-Bug umgehen, der waehrend der Sprint-Durchfuehrung auftritt?

Produktions-Bugs waehrend der Sprint-Durchfuehrung erzeugen eine echte Spannung zwischen Sprint-Integritaet und organisatorischer Verantwortung. Das Scrum-Framework empfiehlt, dass kritische Bugs ueber den Product Owner gehen, der ihre Prioritaet gegenueber dem Sprint-Ziel bewertet. Wenn der Bug genuegend Benutzer oder Umsatz bedroht, fuegt der Product Owner ihn in den Sprint ein (moeglicherweise ein bestehendes Item entsprechender Groesse entfernend, um die Sprint-Kapazitaet zu schuetzen). Einige Teams behalten einen kleinen 'operativen Puffer' von 10-15% Sprint-Kapazitaet fuer ungeplante Arbeit - dies ist eine Team-Entscheidung, die waehrend Sprint Planning getroffen wird.

Q: Wie verhaelt sich Sprint-Durchfuehrung zu technischen Schulden?

Technische Schulden haeufen sich an, wenn Teams Qualitaetspraktiken waehrend der Sprint-Durchfuehrung ueberspringen - Tests kuerzend, Code-Reviews ueberspringend oder Refactoring verschiebend. Eine starke Definition of Done ist die primaere Verteidigung gegen technische Schulden: Wenn Code-Review, Unit-Tests und Integrationstests nicht verhandelbare DoD-Kriterien sind, werden Abkuerzungen, die Schulden erzeugen, verhindert. Leistungsstarke Scrum-Teams weisen Sprint-Kapazitaet explizit fuer die Reduzierung technischer Schulden zu (typischerweise 10-20% der Sprint-Kapazitaet), indem sie sie als echte Sprint-Backlog-Arbeit behandeln.

Q: Wie gehen Scrum-Teams mit Wissenssilos und Bus-Faktor-Risiken waehrend der Sprint-Durchfuehrung um?

Wissenssilos entstehen, wenn nur ein Entwickler einen bestimmten Teil des Systems versteht und einen 'Bus-Faktor' von 1 erzeugt. Sprint-Durchfuehrungs-Praktiken, die Silos reduzieren, umfassen: Pair-Programming-Rotationen (verschiedene Paare jeden Sprint), Anforderung von Code-Reviews durch jemand anderen als den Autor, Cross-Training-Sessions als Sprint-Backlog-Items, Normen fuer gemeinsame Code-Eigentuemer-schaft und Dokumentation als Teil der Definition of Done. Die Sprint-Retrospektive ist der richtige Moment, um wachsende Silos zu identifizieren und spezifische Massnahmen zu ergreifen, um sie anzugehen.

Q: Wie sollte ein Scrum-Team die Sprint-Durchfuehrung gestalten, wenn Teammitglieder erheblich unterschiedliche Faehigkeitsniveaus haben?

Teams mit gemischten Faehigkeiten sind in Scrum die Norm, nicht die Ausnahme. Die Sprint-Durchfuehrung berucksichtigt dies durch Selbstorganisation: Erfahrene Entwickler paaren sich natuerlich mit Junioren bei komplexen Items, und Junior-Entwickler uebernehmen klar definierte Items mit bekannten Loesungen. Pair Programming ist besonders wertvoll in Teams mit gemischten Faehigkeiten - es uebertrag-t Wissen, waehrend die Arbeit erledigt wird. Der Scrum Master coacht das Team, um das Anti-Pattern zu vermeiden, komplexe Arbeit immer Senioren zuzuweisen und einfache Arbeit Junioren (was Wachstum einschraenkt).

Q: Welche Rolle spielt die Definition of Done bei der Sprint-Durchfuehrung und wie entwickelt sie sich im Laufe der Zeit?

Die Definition of Done ist der Qualitaetsstandard, den jedes Sprint-Backlog-Item erfuellen muss, bevor es als Teil des potenziell auslieferbaren Increments zaehlt. Waehrend der Sprint-Durchfuehrung fungiert sie als Checkliste, die 'fast fertig'-Items davon abhalt, vorzeitig als abgeschlossen markiert zu werden. Teams beginnen typischerweise mit einer minimalen DoD (Code ueberprueft, grundlegende Tests bestanden, in Staging bereitgestellt) und staerken sie im Laufe der Zeit, da ihre Infrastruktur und Praktiken reifen. Die Sprint-Retrospektive ist die primaere Gelegenheit, die DoD zu entwickeln.

Q: Wie veraendert sich die Sprint-Durchfuehrung, wenn mehrere Scrum-Teams am gleichen Produkt arbeiten?

Wenn mehrere Scrum-Teams zu einem Produkt beitragen, erfordert die Sprint-Durchfuehrung zusaetzliche Koordination jenseits der internen Praktiken jedes Teams. Teams muessen ihre Integrationspunkte synchronisieren - typischerweise durch Verwendung eines einzigen Product Backlogs, desselben Sprint-Zeitrahmens (synchronisierte Sprints) und Integration ihrer Arbeit in ein einziges Increment pro Sprint. Scrum of Scrums ist ein gaengiger Koordinationsmechanismus: Vertreter jedes Teams treffen sich kurz (oft taeglich oder mehrmals pro Woche), um teamuebergreifende Abhaengigkeiten und Integrationsrisiken aufzuzeigen.

Q: Welche psychologische Auswirkung hat das Nicht-Erreichen des Sprint-Ziels, und wie sollten Teams damit umgehen?

Das Nichterreichen des Sprint-Ziels, insbesondere wiederholt, errodiert das Teamvertrauen und die Teamkompetenz. Entwickler koennen beginnen, Schaetzungen zu polstern, um sich zu schuetzen, oder sich vom Sprint-Ziel als Selbstschutz zu distanzieren. Der Scrum Master spielt eine entscheidende Rolle dabei, Misserfolge als Lernmoeglichkeit statt als Leistungsversagen zu normalisieren: Die Sprint-Retrospektive sollte ohne Schuldzuweisungen fragen 'Was hat uns daran gehindert, das Sprint-Ziel zu erreichen?' und spezifische Prozessaenderungen fuer den naechsten Sprint produzieren.

Q: Wie messen Organisationen den ROI von Investitionen in die Verbesserung der Sprint-Durchfuehrung?

Der ROI aus der Verbesserung der Sprint-Durchfuehrung manifestiert sich durch mehrere messbare Ergebnisse. Eine steigende Sprint-Ziel-Erreichungsrate von 50-65% auf 80%+ erhoht direkt die Vorhersagbarkeit. Reduzierte Nacharbeit (weniger Bugs nach Sprint-Abschluss, weniger Items nach Sprint Review wieder geoeffnet) senkt die Qualitaetskosten. Niedrigere Impediment-Loesungszeit reduziert die kumulierten Kosten blockierter Arbeit im Team. Mitarbeiterzufriedenheitswerte verbessern sich typischerweise, da die Durchfuehrungsqualitaet steigt. Auf Portfolioebene bringen Organisationen mit hoher Sprint-Durchfuehrungs-Reife Features schneller auf den Markt.

Von Abhay Talreja

20.2.2026

Mein neuester Artikel - Empirical Process Control - The Key to Agile Success

Sprint-Durchfuehrungsstrategien fuer Scrum-Teams: Ein tiefer Einblick

Die Sprint-Durchfuehrung ist der Moment, in dem Scrum-Theorie zur Realitaet wird. Es ist die Phase zwischen Sprint Planning und dem Sprint Review, in der das Scrum-Team ausgewaehlte Product Backlog Items in ein nutzbares Produkt-Increment umwandelt.

Die Sprint-Durchfuehrung richtig umzusetzen unterscheidet leistungsstarke Scrum-Teams von denen, die mit verfehlten Zielen, Scope Creep und niedrigem Teamgeist kaempfen. Dieser Leitfaden behandelt alle Dimensionen einer effektiven Sprint-Durchfuehrung - von taeglichen Ablaeufen und Rollenverantwortlichkeiten bis hin zu Metriken, Remote-Team-Praktiken und den haeufigsten Anti-Patterns.

Kurze Antwort: Sprint-Durchfuehrung auf einen Blick

Aspekt	Details
Was es ist	Die Arbeitsphase eines Sprints, in der das Team das Increment in Richtung Sprint-Ziel erstellt
Dauer	Die gesamte Sprint-Laenge (typischerweise 1-4 Wochen), abzueglich Planungs- und Review-Zeremonien
Hauptverantwortlicher	Entwickler - sie organisieren sich selbst und besitzen die Art und Weise, wie die Arbeit erledigt wird
Wichtige Events	Daily Scrum (15 Min. taeglich), plus bedarfsorientierte Zusammenarbeit
Wichtiges Artefakt	Sprint Backlog - der Plan des Teams zur Erreichung des Sprint-Ziels
Erfolgsmassstaab	Sprint-Ziel erreicht, Increment erfullt die Definition of Done
Haeufige Falle	Sprint Backlog als festen Vertrag statt als adaptiven Plan behandeln

Was Sie in diesem Leitfaden lernen werden:

Wie Sprint-Durchfuehrung in den vollstaendigen Sprint-Lebenszyklus passt
Taegliche Ablaeufe und stundengenaue Teamrhythmen
Spezifische Verantwortlichkeiten fuer Entwickler, Scrum Master und Product Owner
Metriken, die den Durchfuehrungszustand aufzeigen (Burn-down, Flow-Effizienz, Impediment-Aging)
Ein dreistufiges Reifegradmodell zur Weiterentwicklung der Durchfuehrungskapazitaet Ihres Teams
Die 8 schaedlichsten Sprint-Durchfuehrungs-Anti-Patterns mit spezifischen Loesungen

Inhaltsverzeichnis-

Was ist Sprint-Durchfuehrung?

Sprint-Durchfuehrung ist die Phase innerhalb eines Sprints, in der Entwickler die eigentliche Arbeit am Produkt-Increment ausfuehren. Sie beginnt in dem Moment, in dem Sprint Planning endet, und dauert bis zum Ende des Sprints an.

Waehrend dieser Zeit:

Arbeitet das Team die Sprint-Backlog-Items nach Prioritaet ab
Fuehrt das Team jeden Tag ein Daily Scrum durch, um den Fortschritt zu inspizieren und den Plan anzupassen
Arbeitet das Team kontinuierlich zusammen, um Probleme zu loesen und Wissen zu teilen
Stellt das Team sicher, dass jedes abgeschlossene Item die Definition of Done des Teams erfuellt
Haelt das Team das Sprint-Ziel als leitendes Ziel im Vordergrund

Das Sprint Backlog gehoert vollstaendig den Entwicklern. Nur Entwickler koennen es waehrend des Sprints aendern. Product Owner und Scrum Master weisen keine Aufgaben zu und lenken nicht, wie die Arbeit erledigt wird.

Wie Sprint-Durchfuehrung sich von traditioneller Projektausfuehrung unterscheidet

Dimension	Traditionelle Projektausfuehrung	Scrum Sprint-Durchfuehrung
Planung	Detaillierter Upfront-Plan, Aenderungen unerwuenscht	Planen beim Sprint-Start, taeglich anpassen
Steuerung	Manager weist Aufgaben von oben nach unten zu	Team organisiert sich selbst, zieht Arbeit
Fortschrittsverfolgung	Meilenstein-Gates, Phasenabschluesse	Daily Scrum, Burn-down, Definition of Done
Scope-Aenderungen	Change Control Board, formeller Prozess	Neue Items kommen ins Backlog; Sprint-Ziel wird geschuetzt
Qualitaetsgates	Reviews am Ende jeder Phase	Kontinuierlich - jedes Item muss DoD erfuellen
Teamstruktur	Funktionale Silos (Dev, QA, Ops)	Cross-funktional, alle Skills in einem Team

Der Sprint-Zyklus und seine fuenf Events

Die Sprint-Durchfuehrung findet nicht isoliert statt. Sie ist die zentrale Phase innerhalb des Sprint-Zyklus, der fuenf Scrum-Events umfasst:

Sprint - Der Container fuer alle anderen Events (1-4 Wochen)
Sprint Planning - Legt das Sprint-Ziel fest und erstellt das Sprint Backlog (max. 8 Stunden fuer einen 4-Wochen-Sprint)
Daily Scrum - 15-minuetliche taegliche Inspektion und Anpassung (findet jeden Tag waehrend der Durchfuehrung statt)
Sprint Review - Increment mit Stakeholdern inspizieren, Product Backlog anpassen (max. 4 Stunden)
Sprint Retrospective - Teamprozesse inspizieren, Verbesserungen identifizieren (max. 3 Stunden)

Was das Daily Scrum ist (und was nicht)

Das Daily Scrum ist ein Inspektions- und Anpassungs-Event:

Inspizieren: Wie ist der Fortschritt in Richtung Sprint-Ziel?
Anpassen: Muss der Plan angepasst werden, um auf Kurs zu bleiben?

Effektive Daily-Scrum-Fragen konzentrieren sich auf das Sprint-Ziel:

Was habe ich gestern getan, das uns dem Sprint-Ziel naehergebracht hat?
Was werde ich heute tun, um uns dem Sprint-Ziel naeher zu bringen?
Gibt es etwas, das den Fortschritt in Richtung Sprint-Ziel blockiert?

Der Scrum Master fuehrt das Daily Scrum nicht. Entwickler besitzen es. Der Scrum Master sorgt dafuer, dass es stattfindet, und coacht das Team, es fokussiert und zeitgebunden zu halten.

Taeglicher Arbeitsablauf waehrend eines Sprints

Leistungsstarke Scrum-Teams entwickeln einen konsistenten taeglichen Rhythmus.

Morgen (Team-Sync und Fokus-Einstellung)

9:00 - 9:15 - Daily Scrum

Alle Entwickler anwesend (Scrum Master nimmt als Dienstleister teil; PO optional)
Fortschritt gegenueber dem Sprint-Ziel inspizieren
Blocker oder Koordinationsbeduerfnisse identifizieren
Sprint Backlog aktualisieren (Aufgabenstatus, verbleibende Scha-etzungen)

9:15 - 9:30 - Post-Scrum-Koordination

Paare oder Untergruppen treffen sich kurz zur Planung kollaborativer Arbeit
Scrum Master adressiert aufgeworfene Impediments
PO fuer schnelle Klaerungen verfa-egbar (keine Entscheidungen, die den Scope aendern)

Mittag (Phase tiefer Arbeit)

9:30 - 12:30 - Fokussierte Entwicklungsarbeit

Entwickler ziehen Aufgaben aus dem Sprint Backlog (nicht vom Manager zugewiesen)
Swarming bei blockierten Items: Wenn ein Entwickler blockiert ist, helfen andere
Kontinuierliche Integration - Code wird haeufig committet und getestet
Kurze technische Syncs finden organisch nach Bedarf statt

Nachmittag (Fortsetzung und Abschluss)

13:30 - 16:30 - Entwicklungsarbeit wird fortgesetzt

Code-Reviews, Pair Programming, Testing
Integration und Deployment in Testumgebungen
Dokumentations-Updates als Teil der Definition of Done

16:30 - 17:00 - Tagesabschluss-Ueberpruefung

Sprint Backlog mit tatsaechlichem Fortschritt aktualisieren
Items markieren, die moeglicherweise nicht fertig werden
Entscheidungen oder Erkenntnisse fuer das Daily Scrum von morgen notieren

⚠️

Vermeiden Sie Mid-Sprint-Status-Meetings durch das Management. Diese fragmentieren die Fokuszeit und untergraben das Daily Scrum als primaeren Koordinationsmechanismus des Teams.

Rollenverantwortlichkeiten waehrend der Sprint-Durchfuehrung

Entwickler

Entwickler sind die primaeren Eigentuemer der Sprint-Durchfuehrung:

Selbst-organisieren: Entscheiden, wer was, wann und wie tut - ohne externe Anleitung
Arbeit ziehen: Items aus dem Sprint Backlog nach Prioritaet und Kapazitaet auswaehlen
Zusammenarbeiten: Bei Blockern swarmen, bei komplexen Problemen paaren, Wissen teilen
Kontinuierlich integrieren: Code haeufig committen, automatisierte Tests ausfuehren
Qualitaet aufrechterhalten: Definition of Done auf jedes Item anwenden
Sprint Backlog aktualisieren: Tatsaechlichen Fortschritt taeglich widerspiegeln
Impediments fruehzeitig melden: Blocker beim Daily Scrum aufzeigen

Scrum Master

Der Scrum Master dient dem Team waehrend der Durchfuehrung:

Impediments entfernen: Sofort handeln, wenn Blocker gemeldet werden
Team schuetzen: Externe Unterbrechungen und Mid-Sprint-Aenderungen verhindern
Daily Scrum begleiten (nicht leiten): Team coachen, es zu besitzen
Impediment-Alter verfolgen: Impediments aelter als 2 Tage brauchen Eskalation
Technische Diskussionen begleiten: Teams bei der Loesung blockierender Architekturdebatten helfen

Product Owner

Der Product Owner spielt waehrend der Durchfuehrung eine unterstuetzende, nicht direktive Rolle:

Fuer Klaerungen verfuegbar sein: Entwickler werden Fragen zu Akzeptanzkriterien haben
Fragen schnell beantworten: Verzoegerungen bei PO-Antworten sind ein wesentliches Impediment
Sprint-Ziel nicht aendern: Einmal in Sprint Planning festgelegt, wird das Sprint-Ziel geschuetzt
Stakeholder-Erwartungen managen: Kommunizieren, was im Sprint ist und was nicht

Wenn ein Stakeholder waehrend des Sprints dringende Arbeit zum Product Owner bringt, bewertet der PO die Prioritaet und fuegt sie dem Product Backlog hinzu. Nur wenn die neue Arbeit das Sprint-Ziel bedroht, sollte der PO eine Sprint-Absage in Betracht ziehen.

Sprint-Ziel-Fokus aufrechterhalten

Das Sprint-Ziel ist der wichtigste Anker der Sprint-Durchfuehrung. Es ist das "Warum" hinter dem Sprint Backlog.

Scope Creep verhindern

Auf Team-Ebene:

Sprint-Ziel sichtbar im Team-Arbeitsbereich oder virtuellen Board posten
Sprint-Ziel als Filter verwenden: "Beeinflusst diese neue Anforderung unsere Faehigkeit, das Sprint-Ziel zu erreichen?"
Wenn ja - an PO eskalieren. Wenn nein - ins Backlog fuer einen zukunftigen Sprint.

Wenn Scope sich mid-Sprint aendern muss:

Wenn ein neuer kritischer Bug das Sprint-Ziel blockiert - tritt er in den Sprint ein
Wenn ein PBI viel groesser ist als geschaetzt - Scope wird entfernt, um das Ziel zu schuetzen
Wenn externe Abhaengigkeiten scheitern - das Team plant um das Ziel herum neu

Aufgabenmanagement-Strategien

PBIs in Aufgaben aufteilen

Eine gut aufgeteilte PBI hat Aufgaben, die:

In 1-2 Tagen abschliessbar sind (nicht "Backend schreiben" - das ist zu vage)
Wo moeglich unabhaengig testbar sind
Eine grobe Stundenabschaetzung beim Sprint Planning haben (taeglich aktualisiert)

Beispiel-Aufgliederung fuer "Benutzer kann Passwort zuruecksetzen":

Passwort-Reset-E-Mail-Vorlage gestalten (4 Stunden)
Passwort-Reset-Token-Generierung implementieren (3 Stunden)
Reset-Passwort-API-Endpunkt erstellen (5 Stunden)
Unit-Tests fuer Reset-Logik schreiben (3 Stunden)
Reset-Passwort-UI-Formular erstellen (4 Stunden)
End-to-End-Flow-Integrationstest (3 Stunden)
Benutzerdokumentation aktualisieren (2 Stunden)

Swarming bei Blockern

Swarming bedeutet, dass das Team voruebe-gehend kollektive Aufmerksamkeit auf ein blockiertes oder gefaehrdetes Item richtet:

Ein Entwickler meldet einen Blocker beim Daily Scrum
Anstatt mit ihren eigenen Aufgaben fortzufahren, helfen andere
Das blockierte Item wird innerhalb von Stunden, nicht Tagen, entsperrt

WIP-Limits waehrend der Sprint-Durchfuehrung

Team-Level-WIP-Limit: Nicht mehr als n+1 Items in Bearbeitung (wobei n = Anzahl der Entwickler)
Individuelles WIP-Limit: Jeder Entwickler arbeitet an hoechstens 2 Items gleichzeitig
Items muessen DoD erfuellen, bevor neue begonnen werden: Keine "groesstenteils fertig"-Items

Sprint-Durchfuehrungs-Metriken

Burn-Down-Chart

Ein Burn-down-Chart zeigt verbleibende Arbeit (Stunden oder Story Points) im Zeitverlauf.

Was zu beachten ist:

Flache Linie: Arbeit wird nicht abgeschlossen - Blocker untersuchen
Linie ueber Idealverlauf: Sprint-Ziel koennte gefaehrdet sein - Swarming oder Scope-Verhandlung in Betracht ziehen
Ploetzlicher Abfall: Grosse Items abgeschlossen oder Scope entfernt
Linie unter Idealverlauf: Team koennte fruehzeitig fertig sein oder Arbeit war ueberschaetzt

⚠️

Burn-down-Charts messen Output (abgeschlossene Arbeit), nicht Outcome (gelieferter Wert). Verwenden Sie sie als Fruehwarnsystem, nicht als Leistungsmassstaab fuer das Team.

Impediment-Aging

Verfolgen Sie, wie lange jedes Impediment offen ist:

0-1 Tage: Normal - Scrum Master ist sich bewusst und adressiert es
2-3 Tage: Eskalation erforderlich - Scrum Master bindet Management ein
4+ Tage: Kritisch - Dieses Impediment bedroht das Sprint-Ziel

Kommunikationsmuster, die funktionieren

Das Daily Scrum als Koordinations-Hub

Uber die drei Standardfragen hinaus:

Dauert nicht laenger als 15 Minuten (Scrum Master zeitmt es)
Konzentriert sich auf das Sprint-Ziel, nicht auf individuelle Aufgabenerledigung
Zeigt Impediments auf ohne sie zu loesen (Loesen passiert danach)
Fuehrt zu spezifischen Koordinationsentscheidungen

Async-Kommunikation zwischen Daily Scrums

In verteilten Teams insbesondere:

Geteilten Kanal (Slack, Teams) fuer schnelle Fragen und Entscheidungen nutzen
Technische Entscheidungen in Sprint-Backlog-Item-Kommentaren dokumentieren
Video-Calls fuer komplexe Diskussionen nutzen
"Work in progress"-Code fruehzeitig teilen (offene PRs)

Reifegradmodell der Sprint-Durchfuehrung

Stufe 1: Grundlegende Sprint-Durchfuehrung (Sprints 1-6)

Merkmale:

Daily Scrum laeuft oft lange oder wird zum Statusbericht
Sprint Backlog wird zwischen Daily Scrums nicht aktualisiert
Entwickler arbeiten in Silos - begrenzte Mid-Sprint-Kollaboration
Scope wird haeufig mid-Sprint hinzugefuegt ohne Sprint-Ziel-Beruecksichtigung
Definition of Done wird inkonsistent angewendet

Worauf zu fokussieren ist:

Daily Scrum strikt zeitboxen (sichtbarer Timer)
Sprint Backlog taeglich aktualisieren - zur Team-Gewohnheit machen
Sprint-Ziel als Entscheidungsfilter fuer Scope-Aenderungen einfuehren

Erwartete Sprint-Ziel-Erreichungsrate: 50-65%

Stufe 2: Mittlere Sprint-Durchfuehrung (Sprints 7-15)

Merkmale:

Daily Scrum konsistent auf Sprint-Ziel fokussiert, 15 Minuten oder weniger
Sprint Backlog in Echtzeit oder taeglich von Entwicklern aktualisiert
Etwas Swarming-Verhalten entsteht - blockierte Items erhalten Team-Hilfe
Impediments werden beim Daily Scrum gemeldet, innerhalb von 1-2 Tagen entfernt

Erwartete Sprint-Ziel-Erreichungsrate: 70-80%

Stufe 3: Fortgeschrittene Sprint-Durchfuehrung (Sprint 16+)

Merkmale:

Daily Scrum fuehrt zu echten Neuplanungsentscheidungen, nicht nur Updates
Team swarmt natuerlich bei gefaehrdeten Items ohne Scrum-Master-Aufforderung
Sprint-Ziel-Erreichungsrate konsistent ueber 80%
Scope-Trade-offs selbstbewusst von Entwicklern mit PO-Input gehandhabt

Erwartete Sprint-Ziel-Erreichungsrate: 85%+