Velocity-orientiertes Sprint Planning

Es gibt zwei grundlegende Vorgehensweisen, einen Sprint zu planen:

  1. Velocity-orientiertes Sprint Planning (mit Hinblick auf das durchschnittliche Arbeitspensum eines Teams), und

2) Commitment-orientiertes Sprint Planning (mit Hinblick darauf, was ein Team glaubt, in einem Sprint schaffen zu können).

Velocity-orientiertes Sprint Planning

Hier geht es um velocity-orientiertes Sprint Planning. Dabei sollte die Menge an Arbeit, die für den nächsten Sprint geplant wird, in etwa der der vorherigen Sprints entsprechen. Das setzt natürlich voraus, dass die Größe des Teams in etwa gleich bleibt, dass in den Sprints ähnliche Aufgaben erledigt werden, dass die Sprints ungefähr gleich lang sind, usw. Abweichungen von diesen Voraussetzungen können zum Glück leicht erkannt werden. Wenn, zum Beispiel, ein Sprint wegen eines Feiertages nur neun anstatt zehn Tage dauert, weiß das Team das natürlich schon im Vorhinein.

Die einzelnen Schritte beim velocity-orientierten Sprint Planning:

  • Herausfinden, wie die durchschnittliche Velocity des Teams bei vorherigen Sprints war.

  • Anhand dieser Velocity die entsprechende Anzahl von Product Backlog Items auswählen.

  • Die einzelnen Tasks der User Stories ermitteln und überlegen, ob es die richtige Menge an Arbeit sein könnte.

  • Einschätzen, ob diese Tasks genauso viel Arbeit erfordern, wie die in vorherigen Sprints.

Schauen wir uns diese Schritte aber einmal genauer an.

Schritt 1: Die durchschnittliche Velocity eines Teams ermitteln

Der erste Schritt bei velocity-orientiertem Sprint Planning ist, die durchschnittliche Velocity eines Teams festzustellen. Einige agile Teams orientieren sich nur an der Velocity ihres letzten Sprints. Viele Teams glauben, dass das der beste Indikator dafür ist, was im nächsten Sprint geschafft werden kann. Das ist natürlich nicht falsch. Es kann allerdings hilfreich sein, noch etwas weiter zurück zu schauen (falls diese Daten vorliegen).

Dafür schaut man sich die Velocity der letzten drei bis acht Sprints an. Erfahrungsgemäß kann man so recht gut zukünftige Sprints voraussagen. Natürlich sollte man nicht übertreiben und den Durchschnitt der letzten zehn Jahre ermitteln. Das würde schließlich nichts über die aktuelle Velocity eines Teams aussagen. Liegen die Daten vorheriger Sprints jedoch vor, sollte man möglichst nicht nur auf den einen letzten Sprint zurück blicken.

Schritt 2: Product Backlog Items auswählen

Anhand der gerade ermittelten durchschnittlichen Velocity können die Teammitglieder dann die Items für den nächsten Sprint auswählen. Zusammen sollten diese – zumindest annähernd – der durchschnittlichen Velocity entsprechen.
An diesem Punkt ist velocity-orientiertes Sprint Planning im Prinzip abgeschlossen und kann so bereits innerhalb weniger Sekunden erledigt sein – sobald das Team die Product Backlog Items entsprechend seiner durchschnittlichen Velocity ausgesucht hat, ist es fertig.

Schritt 3: Tasks ermitteln (optional)

Oft reicht diese kurze Zeit für ein Sprint Planning jedoch nicht wirklich aus. Daher können Teams ihrer Planung noch einen dritten Schritt hinzufügen, bei dem die auszuführenden Tasks ermittelt werden.
Dafür besprechen die Teammitglieder jedes einzelne Product Backlog Item, das für den Sprint ausgesucht wurde. Sie versuchen festzustellen, welche Arbeitsschritte für die Fertigstellung der Items notwendig sind. Natürlich kann nicht an alles gedacht werden aber man sollte sich bemühen, so viel wie möglich einzukalkulieren.

Danach überlegt das Team, ob die ausgewählten Items und die entsprechenden Tasks den Sprint füllen werden. Dementsprechend können dann noch einige Items in den Sprint aufgenommen oder entfernt werden.

Einige Teams beenden ihr Sprint Planning jetzt, andere führen noch einen letzten Schritt aus:

Schritt 4: Die Tasks einschätzen (optional)

Manche Teams werden zu guter Letzt noch einschätzen, wie viele Stunden sie wohl für die ausgewählten Tasks brauchen werden. Daran können sie erkennen, ob sie die richtige Menge an Arbeit eingeplant haben.

Dieser Text stammt aus dem Blog von Mike Cohn und wurde von uns ins Deutsche übersetzt.