Das Iterationsendmeeting: über jeden offenen Vorgang einzeln entscheiden

Am Ende einer Iteration bleibt fast immer etwas liegen. Bis hierhin gab es dafür nur den Knopf „Iteration abschließen“: Jeder unfertige Vorgang wandert mit seinem gerechneten Restaufwand in den nächsten Abschnitt. Das ist der richtige Normalfall, aber in einer echten Abschlussrunde fallen Sätze wie „Das schieben wir zurück“ oder „Da sind eher noch zwei Tage drin“. Für genau diese Runde gibt es jetzt das Iterationsendmeeting.

Der Kopf des Iterationsboards mit den Knöpfen „Iteration abschließen“ und „Iterationsendmeeting“ Beide Wege zum Abschluss stehen nebeneinander im Kopf des Iterationsboards. Der Name des Iterationsplans ist verpixelt.

Das Meeting öffnet ein Fenster mit allen offenen Vorgängen des Abschnitts. Links steht die Liste, rechts der gewählte Vorgang mit Beschreibung und Kommentaren. Zu jedem entscheidet man, ob er in die nächste Iteration übernommen wird oder zurück ins Backlog geht, und mit welchem Restaufwand er weiterzählt. Vorausgewählt ist „übernehmen“ mit dem gerechneten Rest. Wer nichts anfasst, bekommt also genau das Ergebnis des einfachen Abschlusses.

Was „zurück ins Backlog“ heißt

Ein eigenes Backlog als Ablage gibt es in GODAV Pro nicht. „Backlog“ heißt hier: Der Vorgang steht in keinem offenen Abschnitt mehr. Wichtig war mir, dass er dabei nicht ausgetragen wird. Im abgeschlossenen Abschnitt bleibt er stehen, denn dort wurde an ihm gearbeitet, und das bleibt wahr. Würde man ihn auch dort entfernen, sähe die vergangene Iteration hinterher leerer aus, als sie war.

Ebenso wenig ändert „Backlog“ seinen Status. Ich hätte den Vorgang dabei zum Beispiel auf „Offen“ zurücksetzen können. Das wäre aber eine zweite Entscheidung, die im Meeting niemand ausdrücklich trifft, und sie würde die Zeitpunkte für Beginn und Abschluss umschreiben. Der Status gehört an die Vorgangskarte, nicht in die Abschlussrunde.

Der Restaufwand gilt für den Vorgang, nicht für den Abschnitt

Ein eingetragener Restaufwand korrigiert die Schätzung des Vorgangs, genau wie das gleichnamige Feld beim Buchen einer Zeit. Er zieht sie auch dann nach, wenn der Vorgang ins Backlog geht. Ich hätte die Zahl in diesem Fall auch verwerfen können, schließlich wandert ja nichts weiter. Aber „so viel ist daran noch zu tun“ ist eine Aussage über den Vorgang, und dieselbe Eingabe je nach Nachbarknopf einmal wirken und einmal verfallen zu lassen, wäre eine Regel, die niemand errät.

Geschrieben wird dabei nur, was sich wirklich ändert. Das Fenster schickt zwar für jeden übernommenen Vorgang eine Zahl, die meisten sind aber unverändert. Ohne diesen Vergleich stünde nach jedem Meeting im Änderungsprotokoll eine lange Reihe von Einträgen wie „12 → 12“.

Was in einer abgeschlossenen Iteration festgehalten wird, bleibt davon übrigens unberührt. Festgeschrieben wird, was der Abschnitt gebunden hatte, als in ihm gearbeitet wurde, und nicht, was für die Zukunft vereinbart wird. Sonst sähe ein durchlaufener Abschnitt voller aus, nur weil jemand den Rest heraufgesetzt hat.

Wurde ein Abschluss verpasst, sodass inzwischen mehrere Abschnitte vorbei sind, zeigt das Fenster die Vorgänge aus allen davon. Stünden sie nicht in der Liste, würden sie stillschweigend übernommen, obwohl das Fenster verspricht, über jeden zu entscheiden.

Was das Fenster absichtlich nicht kann

Bearbeiten. Beschreibung und Kommentare stehen nur zum Nachlesen da. Ein Formular daneben würde dazu einladen, mitten in der Entscheidung den Gegenstand zu ändern. Einzige Ausnahme ist der Restaufwand, denn um ihn geht es ja.
Ein anderes Ziel wählen. Übernommen wird immer in die nächste Iteration. Wer weiter vorausplant, legt den Vorgang von Hand in die Iteration, die er meint.
Halb fertig speichern. „Abbrechen“ verwirft alles. Restaufwände, Übernahmen und der Abschluss sind eine einzige Entscheidung und werden auch auf einmal gespeichert.

Der Reiter „Iterationen“ eines Iterationsplans mit dem Knopf „Iterationsendmeeting“ an der laufenden Iteration Den Knopf gibt es auch direkt an der laufenden Iteration im Iterationsplan.

Später: aus dem Fenster wurde eine Sitzung

In der ersten Fassung war das Meeting ein Fenster des Startenden. Wer mitredete, sah den Vorgang nicht, über den gerade gesprochen wurde. Einige Wochen später ist daraus eine gemeinsame Sitzung geworden, gebaut nach dem Vorbild von Planning Poker: erst ein Wartebereich, danach sehen alle Teilnehmer den Vorgang, den die Meetingleitung anklickt. Entschieden wird weiterhin nur an einer Stelle.

Zwei Unterschiede zum Poker haben ihren Grund in der Aufgabe. Teilnehmen kann, wer in mindestens einem Projekt des Plans Mitglied ist, denn im Meeting hört man zu und redet mit, statt etwas zu schreiben. Und eine Mindestzahl gibt es nicht, wer die Liste allein durchgeht, hält eben ein kurzes Meeting. Gesehen wird dabei aber nur, was man auch sonst sehen darf: Auf einen Vorgang aus einem fremden Projekt steht beim Teilnehmer ein Hinweis statt des Inhalts.