Wann ist ein Sprint abgeschlossen?

Es kommt recht häufig vor, dass ein Team am Ende eines agilen Sprints oder einer Iteration noch unfertige Arbeiten übrig hat. Idealerweise würde ein Team immer jedes Item im Sprint Backlog während des Sprints fertigstellen. Aus den verschiedensten Gründen ist das jedoch nicht immer der Fall. Das führt uns zu einigen Fragen, auf die ich im Folgenden eingehen werde:

• Was soll mit dem jeweiligen Product Backlog Item geschehen?

• Sollte es aufgesplittet werden oder in den nächsten Sprint übernommen werden? Sollte das Team sich die Punkte für die fertigen Teile der Story bei der Velocity anrechnen lassen?

Ist das Item noch relevant?

Wenn ein Product Backlog Item am Ende eines Sprints nicht fertiggestellt wurde, sollte es eigentlich wieder zurück in den Product Backlog verschoben werden. Arbeiten werden nie automatisch von einem Sprint in den nächsten übernommen.

Vielleicht bin ich bei diesem Thema etwas sehr pedantisch, aber mir geht es darum, dass jeder Sprint damit beginnt, dass der Product Owner eine bewusste Entscheidung dazu trifft, woran das Team arbeiten soll. Natürlich ist es sehr wahrscheinlich, dass der Product Owner möchte, dass das Team die unfertigen Arbeiten aus dem vorherigen Sprint in dem neuen Sprint fertigstellt. Jedoch sollte dies immer eine bewusste Entscheidung des Product Owners sein.

(Nur als Anmerkung: ich sage nicht, dass Sie sich extra Arbeit machen sollen, wenn Sie ein Tool benutzen, mit dem das zu kompliziert wäre. Ich sage nur, dass Arbeit nicht automatisch in den nächsten Sprint übernommen wird. Der Product Owner sollte immer entscheiden, ob die Arbeit noch relevant ist.)

Aufsplitten oder in den nächsten Sprint übernehmen?

Wenn ein Product Backlog nicht ganz fertiggestellt werden konnte, fragen sich die Teammitglieder oft, ob sie das Product Backlog Item so lassen sollen (auch wenn schon ein Teil an Funktionalität fertig ist) oder ob sie es so umschreiben sollen, dass nur der noch fehlende Teil beschrieben wird.

Beispiel: Nehmen wir als Beispiel ein Team, das an einer typischen Druckvorschau-Funktion für eine Desktop-Anwendung arbeitet. Wenn das Team dann bis auf die Funktion, durch die einzelnen Seiten zurückblättern zu können, alles erledigt hat, können die Teammitglieder entweder die originale User Story mit in den nächsten Sprint nehmen oder aber ersatzweise eine kleinere Story schreiben: „Als Nutzer möchte ich zurückblättern können, wenn die Druckvorschau angezeigt wird.”

Wenn die Story im folgenden Sprint fertiggestellt wird, würde ich vorschlagen, sie einfach so zu belassen, wie sie ist, und sie nicht umzuschreiben. Jeder kennt die Story so, wie sie bisher geschrieben ist. Wenn der Product Owner sie also immer noch für wichtig hält, kommt sie unverändert in den nächsten Sprint.

Sollte die verbliebene Arbeit jedoch auf einen späteren Sprint verschoben werden, sollte eine neue Story geschrieben werden, die nur den unfertigen Teil der Funktionalität beschreibt.

Merke: Wenn die Arbeit im nächsten Sprint fertiggestellt wird, wird die Story nicht umgeschrieben.

Bekommt das Team Punkte für die Velocity?

Ich nehme gerne einen etwas konservativen Standpunkt im Hinblick auf die Velocity ein. Das bedeutet, dass ein Team nur für die Arbeit Punkte bekommen sollte, die auch wirklich vollständig fertig ist. Das bedeutet:

1. Wenn ein unfertiges Product Backlog Item also in den nächsten Sprint übernommen und dann auch fertiggestellt wird, sollte das Team in dem ursprünglichen Sprint keine Punkte dafür bekommen. Stattdessen bekommt das Team dann im dem Sprint alle Punkte für die Story, in dem die Arbeit tatsächlich fertig wird. Da ich ohnehin dafür bin, mit einer durchschnittlichen Velocity zu arbeiten, gleicht sich das wieder aus und so besteht kein Risiko, dass die Velocity dann zu hoch bewertet wird.

2. Anders ist es allerdings, wenn das Team die Story aufsplittet und die verbleibende Arbeit zurück in den Product Backlog gibt, um später daran zu arbeiten. In diesem Fall werden die Punkte für die erledigte Arbeit dem Team gutgeschrieben. Die Teammitglieder müssen dann so gut wie möglich einschätzen, wie viele Punkte die erledigte Arbeit wohl wert ist. Auch wenn die gesamte Story noch nicht fertig ist, kann es sein, dass das Team alle ursprünglichen Punkte für die Story bekommt, denn es ist möglich, dass die Story doch größer war als gedacht. Das sollte nicht ständig passieren aber ab und zu ist es in Ordnung.

Fazit: Immer nach der Ursache suchen

Wenn es am Ende des Sprints noch unfertige Arbeiten gibt, sollte sich das Team in der Retrospektive immer Zeit nehmen, um herauszufinden, ob die Ursache dafür vermeidbar gewesen wäre. Manchmal ist es einfach nur Pech oder schlechtes Timing; beispielsweise wenn ein Teammitglied krank wird oder ein Problem auftaucht, das man am Anfang des Sprints nicht vorhersehen konnte. Es ist aber immer ratsam, darüber nachzudenken, was die Ursache war und wie man das in Zukunft verhindern kann.

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

User Stories, Epics, Themes

Wir erklären den Unterschied zwischen diesen Items.
=>User Stories, Epics, Themes

Ein Produkt entwickeln

Von der Idee bis zur Fertigstellung mit dem Product Vision Board.
=>Product Vision Board

Was sind Story Points?

Finde heraus, wo du das Einschätzen deines Teams verbessern kannst.
=>Was sind Story Points?