maxClaint

Wissen · Agile Organisation

Eine Scrum-Woche: vom Planning bis zur Auslieferung

Wie ein Sprint von ein bis vier Wochen abläuft, was im Show and Tell mit dem Fachbereich passiert und wie mehrere Teams mit Scrum@Scale laufend auslieferbare Ergebnisse bereitstellen.

Von Michele Mangieri · Stand:

Kurz erklärt

Ein Sprint in Scrum dauert höchstens einen Monat, meist ein bis vier Wochen. Er beginnt mit dem Sprint Planning, jeden Tag folgt ein Daily Scrum von 15 Minuten, und er endet mit der Sprint Review als Show and Tell mit dem Fachbereich und der Retrospektive. Fertige Ergebnisse dürfen schon während des Sprints ausgeliefert werden.

Grafik: Zwei Wochen von Montag bis Freitag; Planung am ersten Montag, täglich ein Daily, zweimal Verfeinerung, Show and Tell mit dem Fachbereich und Rückblick am letzten Freitag, drei Auslieferungen im Sprint.

Ereignisse

Was in einem Sprint passiert.

Ein Sprint dauert höchstens einen Monat, in der Praxis meist ein bis vier Wochen. Seine Länge bleibt gleich, damit ein verlässlicher Takt entsteht. Alle Ereignisse finden innerhalb des Sprints statt.

Sprint Planning

Zu Beginn klärt das Team, warum der Sprint wertvoll ist, was geschafft werden kann und wie. Ergebnis ist das Sprint-Ziel.

Daily Scrum

Jeden Tag 15 Minuten, zur selben Zeit am selben Ort. Die Entwickler prüfen den Fortschritt zum Sprint-Ziel und passen ihren Plan an.

Sprint Review: Show and Tell mit dem Fachbereich

Am Ende zeigt das Team dem Fachbereich und weiteren Stakeholdern, was fertig ist, und bespricht es mit ihnen: Was passt, was fehlt, was kommt als Nächstes? Der Scrum Guide versteht die Review als Arbeitssitzung, nicht als reine Präsentation.

Sprint Retrospektive

Das Team prüft, wie es gearbeitet hat: Zusammenarbeit, Abläufe, Werkzeuge und die Definition of Done. Die wichtigsten Verbesserungen gehen in den nächsten Sprint.

Backlog Refinement

Eine laufende Tätigkeit: Einträge im Product Backlog werden zerlegt und präzisiert, bis sie in einen Sprint passen.

Beispiel

Zwei Wochen im Takt.

So sieht ein Sprint von zwei Wochen bei vielen Teams aus. Die Uhrzeiten legt jedes Team selbst fest.

Grafik: Zwei Wochen von Montag bis Freitag; Planung am ersten Montag, täglich ein Daily, zweimal Verfeinerung, Show and Tell mit dem Fachbereich und Rückblick am letzten Freitag, drei Auslieferungen im Sprint.
Fig. 22 · Sprint-Takt
  • Montag, erste Woche: Sprint Planning am Vormittag, danach beginnt die Arbeit am Sprint-Ziel.
  • Jeden Tag: Daily Scrum, 15 Minuten, immer zur selben Uhrzeit.
  • Donnerstag der ersten und Mittwoch der zweiten Woche: je ein Termin für Refinement, damit der nächste Sprint vorbereitet ist.
  • Laufend: Was die Definition of Done erfüllt, wird integriert und kann ausgeliefert werden, nicht erst am Sprintende.
  • Freitag, zweite Woche: Show and Tell mit dem Fachbereich. Das Team zeigt lauffähige Ergebnisse, der Fachbereich probiert aus und gibt Rückmeldung für das Backlog. Danach die Retrospektive, am Montag beginnt der nächste Sprint.

Sprintlänge

Ein bis vier Wochen: Was die Länge ändert.

1 Woche

Schnellstes Feedback, aber viel Abstimmung im Verhältnis zur Arbeit. Gut, wenn sich Anforderungen oft ändern. Planning bis etwa 2 Stunden, Review etwa 1 Stunde, Retrospektive etwa 45 Minuten.

2 Wochen

Ein verbreiteter Takt: genug Zeit für ein nutzbares Ergebnis, Feedback alle zehn Arbeitstage. Planning bis etwa 4 Stunden, Review etwa 2 Stunden, Retrospektive etwa 1,5 Stunden.

3 Wochen

Passt, wenn Ergebnisse mehr Vorlauf brauchen, etwa für Tests im Fachbereich. Planning bis etwa 6 Stunden, Review etwa 3 Stunden, Retrospektive etwa 2 Stunden.

4 Wochen

Obergrenze des Scrum Guides. Je länger der Sprint, desto eher veraltet das Sprint-Ziel unterwegs und desto höher das Risiko. Planning bis 8 Stunden, Review 4 Stunden, Retrospektive 3 Stunden.

Die Zeiten sind Höchstwerte nach dem Scrum Guide 2020 für einen einmonatigen Sprint; für kürzere Sprints sind sie anteilig als Faustregel angegeben.

Mit mehreren Teams

Schnell auslieferbar mit Scrum@Scale.

Arbeiten mehrere Teams an einem Produkt, entsteht ein auslieferbares Ergebnis erst, wenn ihre Arbeit zusammenpasst. Scrum@Scale und bewährte Technik bieten dafür mehrere Wege.

  • Eine gemeinsame Definition of Done: Arbeiten mehrere Teams an einem Produkt, legen sie nach dem Scrum Guide dieselbe Definition of Done fest. Enthält sie Integration, automatische Tests und eine produktionsnahe Bereitstellung, ist jedes fertige Ergebnis auslieferbar.
  • Ein integriertes Inkrement im Scrum of Scrums: Auslieferung ist ein Baustein des Scrum Master Cycle. Die Teams führen ihre Arbeit zu einem gemeinsamen, getesteten Stand zusammen, statt jedes für sich zu liefern.
  • Ein gemeinsames Show and Tell: Im Scrum of Scrums zeigen alle Teams dem Fachbereich ein integriertes Ergebnis, statt einzelne Teilstände nacheinander vorzuführen. So sieht der Fachbereich, was wirklich zusammen funktioniert.
  • Ausliefern während des Sprints: In einem Sprint dürfen mehrere Inkremente entstehen. Die Review ist kein Tor für die Freigabe, ausgeliefert wird, sobald ein Ergebnis fertig ist.
  • Bereitstellen und Freischalten trennen: Mit Schaltern im Code (Feature Toggles) geht Software laufend in Produktion. Wann eine Funktion freigeschaltet wird, entscheidet die Release-Planung im Product Owner Cycle.
  • Automatisierte Strecke: Ohne automatisierte Tests und eine Bereitstellungsstrecke wird jede Auslieferung zum Projekt. Im SAP-Umfeld gehören Transporte und Schnittstellentests dazu.
  • Hindernisse schnell lösen: Was ein Team nicht allein lösen kann, kommt im Scaled Daily Scrum auf den Tisch und geht an das Executive Action Team.
  • Feedback in beide Zyklen: Rückmeldungen zum Produkt gehen an die Product Owner, Rückmeldungen zur Auslieferung an die Scrum Master.

Aus unserer Arbeit

In einer S/4HANA-Transformation haben wir UAT- und Regressionstests automatisiert, damit Ergebnisse schneller abnahmefähig sind. Als Scrum Master und Moderator zwischen Fachbereichen und IT haben wir erlebt: Der Takt hält nur, wenn Fachbereich und Stakeholder zur Review wirklich kommen.

Sie wollen mehrere Teams in einen gemeinsamen Takt bringen? Zur Workshop-Moderation →

Quellen: Der Scrum Guide, November 2020, Ken Schwaber und Jeff Sutherland; The Scrum@Scale Guide, Version 2.1, Februar 2022, Jeff Sutherland und Scrum Inc.; beide unter der Lizenz CC BY-SA 4.0. Scrum@Scale ist eine eingetragene Marke der Scrum Inc. maxClaint ist ein unabhängiges Beratungsunternehmen und nicht mit Scrum Inc. verbunden.

Häufige Fragen

Fragen zum Sprint

Wie lange dauert ein Sprint in Scrum?

Höchstens einen Monat, in der Praxis meist ein bis vier Wochen. Die Länge bleibt gleich, damit ein Takt entsteht. Ist ein Sprint zu lang, kann das Sprint-Ziel unterwegs veralten, und das Risiko steigt.

Was ist ein Show and Tell in Scrum?

So wird die Sprint Review oft genannt. Das Team zeigt dem Fachbereich und weiteren Stakeholdern sein lauffähiges Ergebnis, der Fachbereich probiert aus und gibt Rückmeldung. Der Scrum Guide versteht die Review als Arbeitssitzung, in der über das weitere Vorgehen entschieden wird.

Darf man vor dem Ende eines Sprints ausliefern?

Ja. Innerhalb eines Sprints dürfen mehrere Inkremente entstehen und ausgeliefert werden. Die Sprint Review ist kein Tor für die Freigabe. Voraussetzung ist, dass das Ergebnis die Definition of Done erfüllt.

Wie liefern mehrere Teams mit Scrum@Scale schnell aus?

Mit einer gemeinsamen Definition of Done, einem integrierten Inkrement im Scrum of Scrums und einer automatisierten Bereitstellung. Feature Toggles trennen das Bereitstellen vom Freischalten. Hindernisse gehen über den Scaled Daily Scrum an das Executive Action Team.

30 Minuten, danach wissen Sie, ob wir helfen können.

Sie schildern die Entscheidung, die ansteht. Wir sagen, welches Paket passt, oder dass keines passt.

Anfrage starten