Sprint Commitment

Ich finde das Sprint Commitment einen ganz wesentlichen Bestandteil von Scrum. Es gehört für mich dazu, wenn ich agil arbeite. Dabei wird das Sprint Commitment häufig falsch verstanden.

Ich habe Teams erlebt, die Sprint Commitments aufgrund von Story-Points abgeben. Das halte ich für Unsinn. Ich habe Teams erlebt, die Sprint Commitments aufgrund einer Story-Anzahl abgeben. Auch das halte ich für unsinnig. Ich habe Teams erlebt, die sich auf eine klar definierte Auswahl von Stories committen. Das halte ich nicht für effektiv. Ich glaube, dass man das Meiste herausholt, wenn man ein Team dafür gewinnt, das Sprint Commitment zum Sprintziel abzugeben.

Hier ist meine Erklärung dazu:

1) Sprint Commitment zu Story-Points
Die Story-Points sind ein Hilfsmittel, um Komplexität von Anforderungen abzuschätzen. D.h. ich möchte wissen, welche Herausforderung eine Story für das Team darstellt. Mit der Velocity, die ich über die zurückliegenden Sprints gemessen habe, kann ich eine ausreichend genaue Aussage über die Möglichkeiten des Teams treffen. Wenn sich das Team jetzt zu einer Story-Point-Anzahl committet wiederhole ich eigentlich nur die Berechnung unter Berücksichtigung der Inhalte. D.h. ich bekomme heraus, wie sicher sich das Team bei seiner Schätzung fühlt. Nachteil: Ich kann in zwei Drittel der Fälle nur verlieren, denn ein Team wird ggf. weniger Story-Points leisten oder nur genauso viel. Dann habe ich aber im Zweifel keinen gefühlten Erfolg. Nur wenn ich mehr schaffe, fühlt sich das richtig gut an, weil es ja ein abstrakter Wert ist. Außerdem bekomme ich als Product Owner keine inhaltliche Garantie. Im Zweifel zieht das Teams die „einfacheren“ Stories vor, um das Commitment zu schaffen.

2) Sprint Commitment zu Story-Anzahl
Das ist genauso zweifelhaft und verhält sich ähnlich zu den Story-Points.

3) Sprint Commitment zu einer Auswahl von Stories
Ja, das geht schon in die richtige Richtung. Ist aber leider auch falsch. Denn das Team hat keine Steuerungsmöglichkeiten mehr. Es befindet sich in der Falle. Kann eine der Stories nicht zu Ende bearbeitet werden ist das Commitment gerissen. D.h. je mehr Stories ich habe, desto wahrscheinlicher ist es, dass das Commitment nicht eingehalten wird. Das ist demotivierend und nicht zielführend.

Was ich eigentlich möchte ist ein Team, das eigenverantwortlich Entscheidungen trifft und auf ein mit dem Product Owner gemeinsam vereinbartes Ziel hinarbeitet. Das bekomme ich in den drei oben genannten Varianten aber nicht hin.

Ich ermögliche solch ein Handeln, wenn ich das Commitment auf das vom Product Owner gesetzte Sprintziel einhole. Und das geht so:

Der Product Owner kommt zum Planning mit seinem Sprintziel und den vorbereiteten Stories. Das Team wählt zusammen mit ihm die Stories aus, die notwendig und sinnvoll sind, um das Sprintziel zu erreichen. Bei der Auswahl wird die Velocity als Erfahrungswert berücksichtigt. Am Ende des Plannings stellt der Product Owner die Frage, ob sich das Team dem Sprintziel verschreibt (sich darauf committet). Das sollte ein Selbstgänger sein.

Was jetzt möglich wird ist, dass alle Entscheidungen während des Sprints an dem Sprintziel ausgerichtet werden können. Man kann sogar Stories kürzen, aufteilen, herausnehmen. Immer wenn man dadurch das Sprintziel weiterhin erreicht, ist es in Ordnung. Das Team trägt dafür die Verantwortung, denn es hat ja sein Commitment gegeben. Hier kommt es nicht auf Story-Points oder konkrete Stories an sondern darauf, das Sprintziel zu erreichen.

Werbung