Commitment-orientiertes Sprint Planning

Es gibt zwei grundlegende Möglichkeiten 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 habe ich bereits erläutert, also konzentrieren wir uns hier auf das Commitment-orientierte Sprint Planning:

Commitment-orientierte Sprint Planning Meetings beziehen den Product Owner, den ScrumMaster und das gesamte Entwicklungsteam mit ein. Der Product Owner gibt eine Übersicht über die Product Backlog Items mit der höchsten Priorität und erklärt sie dann dem Team.

Ein Item auswählen

Im Anschluss daran wählen die Mitglieder des Teams ein Item für den nächsten Sprint aus. In den meisten Fällen stimmt das mit dem Item überein, dem auch der Product Owner die höchste Priorität beigemessen hat. Es kann jedoch auch vorkommen, dass das Item des Product Owners noch zu viele ungeklärte Punkte beinhaltet.

Idealerweise sollte das Team dennoch in der Lage sein, dieses Item in den Sprint aufzunehmen und die offenen Fragen früh genug zu klären, um das Item trotzdem fertigstellen zu können. Sollten es allerdings zu viele, zu schwerwiegende oder zu zeitaufwendige Punkte sein, die es zu lösen gilt, dann sollte das vom Product Owner ausgewählte Item erst einmal ausgelassen werden.

Tasks und Stunden

Nachdem ein Item ausgewählt wurde, besprechen die Teammitglieder die damit verbundene Arbeit und ermitteln die Tasks (Aufgaben), die notwendig sind, um das Product Backlog Item ausliefern zu können. Währenddessen oder direkt danach schätzt das Team ein, wie viel Zeit (Stunden) sie für die einzelnen Tasks etwa benötigen werden.

Erwarten Sie aber nicht, dass das Team für jeden Task eine Einschätzung abgibt. Das ist nicht nur unmöglich, sondern auch unnötig.

Die Teammitglieder sollten lediglich so viele der Tasks einschätzen, dass sie das Gefühl bekommen, alles ausreichend durchdacht zu haben. Denn das ist das eigentliche Ziel eines solchen Meetings. Tasks und Stundenzahlen festzulegen ist zweitrangig.

Die Frage nach den Commitments

Sobald die Teammitglieder die Tasks festgelegt haben und grob einschätzen können, wie lange sie für bestimmte Backlog Items brauchen, sollten sie sich die Frage stellen: “Können wir dafür ein Commitment abgeben?”

Ich finde es wichtig, dass das Team sich selbst diese Frage stellt und nicht vom Scrum Master gefragt wird: “Können Sie dafür ein Commitment abgeben?” Denn so verpflichten sie sich einander, anstatt dem Scrum Master.

Ich weiß nicht wie es bei Ihnen ist, aber meine ersten Jahre im Berufsleben (in der Zeit vor Scrum) waren geprägt von nicht einhaltbaren Commitments gegenüber Vorgesetzten, die zwar fragten “Können Sie das schaffen?”, aber eigentlich meinten “Sehen Sie zu, dass Sie das schaffen!”

Auch wenn der Scrum Master als “Master” bezeichnet wird, ist er kein Vorgesetzter des Teams und sollte dieses Gefühl auch nicht erwecken. Es ist besser, nicht als Chef angesehen zu werden, der auf der Erfüllung aller Commitments besteht.

Stattdessen sollte ein Team dazu gebracht werden, sich selbst zu fragen: “Können wir ein Commitment abgeben?” Denn ein Commitment ist viel stärker, wenn das Team sich gegenüber sich selbst zu etwas verpflichtet.

Außerdem ist es eindeutig, dass es auf die Frage des Teams “Können wir ein Commitment abgeben?” nur zwei mögliche Antworten geben kann, nämlich “Ja, können wir” oder “Nein, können wir nicht.” Wenn hingegen der Scrum Master fragt “Können Sie ein Commitment abgeben?”, werden einige Teammitglieder mit “wir” antworten und andere mit “ich”.

Scrum erfordert ein Commitment des gesamten Teams: “Wenn du Hilfe brauchst, werde ich dir helfen und ich weiß, dass du das selbe für mich tun würdest.” und nicht “Dies sind meine Tasks und das sind deine.”

Den Prozess bei weiteren Stories wiederholen

Wenn das Team sich darauf einigt, für ein bestimmtes Product Backlog Item kein Commitment abgeben zu können, wählen sie ein anderes Item aus und wiederholen den Prozess, Tasks – Stunden – Commitment, solange bis jemand sagt, dass er zu dem ausgewählten Item kein Commitment abgeben kann.

Wenn das so ist, besprechen die Teammitglieder die Situation und schauen, ob ihnen vielleicht jemand anderes helfen kann. Vielleicht kann ja ein Datenbankadministrator mit rudimentären JavaScript-Kenntnissen einem überforderten JavaScript-Entwickler weiterhelfen.

Sollte das nicht der Fall sein, kann die Story zurück in den Backlog geschoben und ein kleineres oder einfacheres Item ausgewählt werden, zu dem jeder ein Commitment abgeben kann.

Was ist mit Story Points und Velocity?

Vielleicht ist Ihnen schon aufgefallen, dass in diesem Prozess bisher weder Story Points noch Velocity eine Rolle spielten. Ich empfehle zwar immer noch, Product Backlog Items mit Hilfe von Story Points abzuschätzen. Allerdings spielen Story Points und Velocity bis zu diesem Punkt keine wirkliche Rolle beim Commitment-orientierten Sprint Planning. Eine wichtige Rolle spielen sie jedoch in der letzten Phase eines Sprint Planning Meetings.

Plausibilitätsprüfung der Commitments

Sobald das Team die verfügbare Zeit in einem Sprint gefüllt hat, kann der Scrum Master nachschauen, wie viele Story Points die einzelnen Items vorher bekommen haben. Das Ergebnis teilt er dann dem Team mit. Das Team kann diese Zahl dann mit seiner durchschnittlichen oder aktuellen Velocity vergleichen.

Nehmen wir einmal an, ein Team mit einer durchschnittlichen Velocity von 20 hält ein solches Sprint Planning Meeting ab und wählt Items aus, die sich insgesamt auf 19 Story Points belaufen. Sie haben diese Items ausgewählt, ohne zu wissen, mit wie vielen Story Points sie zuvor bewertet wurden.

Wenn der Scrum Master ihnen nun mitteilt, dass sie soeben Items mit insgesamt 19 Points ausgewählt haben und dass ihre durchschnittliche Velocity gleich oder sehr ähnlich ist, können die Teammitglieder davon ausgehen, die richtige Menge an Arbeit für den Sprint geplant zu haben.

Wenn jedoch nur Items mit insgesamt 11 Story Points ausgewählt wurden, sollten sie sich fragen, warum sie die Arbeit jetzt als so viel schwieriger eingestuft haben.

Das könnte beispielsweise daran liegen, dass sie im Laufe des Sprint Plannings Arbeit identifiziert haben, die sie vorher nicht berücksichtigt hatten. Oder sie stellen einfach nur fest, dass eine Story in Wirklichkeit komplizierter ist, als gedacht.

In jedem Fall wird das Team wissen, ob es eine angemessene Menge an Arbeit gewählt hat oder ob man vielleicht noch mehr einplanen kann.

Andererseits werden sich die Teammitglieder fragen, was sie nicht berücksichtigt haben, wenn sie Items mit insgesamt 30 Points ausgewählt haben – also 10 mehr als ihr Durchschnitt beträgt. Die Frage könnte dann lauten: “Warum erscheint diese Arbeit nach dem Sprint Planning so viel einfacher als zuvor?”

Velocity und Story Points spielen also keine Rolle für den Großteil eines Commitment-orientierten Sprint Planning Meetings. Sie sind jedoch unerlässlich, wenn es darum geht, die Planung zu überprüfen und zu bestätigen.

Ein Commitment ist keine Garantie

Es ist wichtig, ein Commitment nie als Garantie für etwas zu sehen. Wie schon Clint Eastwood in einem seiner Filme sagte: “Wenn du eine Garantie willst, kauf dir einen Toaster!”

Das Commitment eines Teams bedeutet, dass alle ihr Bestes geben. Wenn sie ihre Commitments in 80 Prozent der Fälle einhalten können, ist das ein guter Schnitt. Es bedeutet auch, dass sie die Sache ernst nehmen und die Zeit optimal nutzen sollten. Das schafft Vertrauen in das Team und in das, was es behauptet, leisten zu können.

Es sollte allerdings nicht das Ziel sein, immer alles zu 100 Prozent fertig zu bekommen. Ein Team, das dazu gezwungen wird, immer alles fertig zu stellen, wird das zwar schaffen können – aber nur indem es seine Commitments dann niedriger ansetzt.

Ich habe diesen Ansatz “Commitment-orientiertes Sprint Planning” genannt. Er wird aber auch als “Kapazitätsbasierte Planung” bezeichnet. Dieser Begriff gefällt mir immer besser, weil ein Commitment einfach zu leicht als Garantie verstanden werden kann.

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