Wer legt eigentlich fest, wie lange eine Sprint dauert?

Diese spannende Frage stellte Michael de la Maza auf Twitter. Spannend, weil der Scrum Guide dazu keine explizite Antwort liefert und trotzdem muss eine Entscheidung getroffen werden. Die Festlegung der Sprint-Länge ist eine längerfristige Entscheidung, denn die Sprint-Länge sollte über einen längeren Zeitraum gleich bleiben.

Das Ergebnis der Umfrage stimmt mich nachdenklich:

Quelle: https://twitter.com/hearthealthyscr/status/1171863203342536706

Als häufigste Antwort wurde das Dev-Team (45% = 41 Stimmen von 92) genannt. Gefolgt von „keins der genannten Antworten“ (33% = 30 Stimmen). Scrum Master (14% = 13 Stimmen) und Produkt Owner (9% = 8 Stimmen) sind stark abgeschlagen. Aus den Kommentaren unter der Umfrage geht hervor, dass die Antwort „Others“ häufig als Ersatz für die fehlende Antwortmöglichkeit „Scrum Team“ ausgewählt wurde.

Meine Antwort war: Produkt Owner. Nunja, damit bin ich deutlich in der Minderheit. Deshalb dieser Blog-Post, um meine Antwort zu begründen.

Der von mir geschätze (Scrum Urgestein) Mike Cohn schrieb bereits 2014 (Link: englisch/Original bzw. deutsch/Übersetzung): Das Scrum Team (also alle 3 Rollen gemeinsam) entscheiden gemeinsam über die Sprint-Länge. Findet sich kein Konsens, dann entscheidet der Scrum Master.

Diese Einschätzung teile ich nicht.

Meine Argumentation:

Das Herz von Scrum ist der Sprint, ein Zeitraum[Time Box] von maximal einem Monat,innerhalb dessen ein fertiges [„Done“], nutzbares und potenziell auslieferbares Produktinkrement hergestellt wird.

Scrum Guide, deutsch, 2017, Abschnitt: Sprint

Entwicklungsteams liefern jeden Sprint ein Inkrement an Produktfunktionalität. Dieses Inkrement ist vollständig verwendbar, so dass der Product Owner sich jederzeit dazu entscheiden kann, es zu releasen.

Scrum Guide, deutsch, 2017, Abschnitt: Definition of Done

Ich würde es einfach zusammenfassen zu: Das Sprint-Ergebnis (weiterentwickeltes Produkt Inkrement) kann am Ende des Sprintes an den Nutzer des Produktes ausgeliefert werden. Und somit wird ein Mehrwert für den Anwender geschaffen (Business Value). In einer agilen, wettbewerbsgetriebenen Welt ist es ein Wettbewerbsvorteil, schnell auf die Veränderungen im Markt zu reagieren und entsprechende Lösungen anzubieten. Dem Markt/den Stakeholdern das bestmögliche (wertmaximiertes) Produkt zu liefern ist Aufgabe des Product Owners.

Schätzt der Product Owner den Markt so ein, dass eine neue Produktversion nur alle 4 Wochen released werden sollte, dann kann der Sprint „lange“ dauern. Hinzu kommen noch Feedback-Zyklen, die das Produkt-Inkrement ggf. in einer weiteren Verbesserung-Schleife „besser“ macht. Ist ein wöchentliches Feedback/Relase notwendig, dann sollte der Sprint nur 1 Woche dauern. Business und Risikovermeidung treiben die Sprint-Länge.

Die Entscheidung über die Sprint-Länge sollte aus meiner Sicht der Product Owner fällen.

Natürlich ergibt es sehr viel Sinn (und hier zeigt sich, ob der Product Owner ein Teamplayer ist), wenn der Product Owner sich vorher mit dem Scrum Team berät. Der Scrum Master kann aus seinen Erfahrungen eine Empfehlung ableiten. Das Dev-Team kann darüber beraten, ob in dem gewünschten Sprint-Zeitraum ein entsprechend spürbarer Mehrwert geliefert werden kann. Vielleicht gibt es auch technische Notwendigkeiten für eine Mindest-Sprint-Länge.

Entscheiden muss jedoch der Product Owner.

Für den Scrum Master sehe ich grundsätzlich keine Entscheidungskompetenz. Es ist eine beratende und unterstützende Rolle für das gesamte Scrum Team.

2 Kommentare zu „Wer legt eigentlich fest, wie lange eine Sprint dauert?

  1. Zunächst danke für diesen Artikel. Ich habe den Post auch gesehen und fand es interessant, dass die aus meiner Sicht richtige Antwort Scrum-Team in der Auflistung fehlte. Ich teile also die Meinung von Mike Cohn. Die Länge des Sprints ergibt sich aus der „Fähigkeit“ des Scrum-Teams einen lieferbaren Mehrwert zu generieren. Das schließt den PO und das Dev-Team mit ein. Der Scrum-Master ist auch entscheidend, denn er ist daran interessiert, diese Fähigkeit zu entwickeln. Den Business-Aspekt für das Feedback sehe ich tatsächlich erst an zweiter Stelle, denn vor dem Feedback kommt das Liefern.

    Gefällt 1 Person

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.