Ist das Identifizieren von Tasks im Iteration Planning die Mühe wert?

Lohnt sich das Identifizieren der Tasks überhaupt?

In letzter Zeit habe ich einiges über das Identifizieren von Tasks im Iteration Planning geschrieben. Dabei ging es darum, dem Team dabei zu helfen, die richtige Anzahl und Größe von Tasks zu identifizieren.

Für die meisten Teams lautet die Antwort: Ja.

Die Task-Liste an sich finde ich gar nicht mal sonderlich hilfreich. Die Tatsache, dass man sich für die Erstellung der Liste jedoch Gedanken machen muss, ist allerdings äußerst hilfreich.

Ein Beispiel für eine gute Task-Liste

Nehmen Sie einmal an, dass Sie gerade eine schöne Städtereise planen und möchten nun Ihren Koffer packen. Also erstellen Sie entweder eine Packliste oder Sie fangen einfach an, Klamotten in Ihren Koffer zu schmeißen. Sie würden in gewissem Maße darüber nachdenken, was Sie alles benötigen werden. Sie wissen aber auch, dass Sie, wenn Sie etwas vergessen haben sollten, zur Not auch vor Ort etwas kaufen könnten.

Anders wäre es allerdings, wenn Sie eine Expedition zum Mount Everest geplant hätten. In diesem Fall würden Sie genauer darüber nachdenken, was Sie alles benötigen. Auf über 8.800 m Höhe wird es nämlich schwierig, etwas nachzukaufen, was man vergessen hat. Daher würden Sie in diesem Fall sicherlich eine Packliste schreiben und diese wahrscheinlich auch zwei- oder dreimal kontrollieren.

Ist diese Packliste jedoch auch während der Besteigung des Mount Everest noch hilfreich für Sie?

Überhaupt nicht.

Aber die Tatsache, dass Sie sich darüber intensiv Gedanken gemacht haben, schon.

Der eigentliche Wert des Identifizierens von Tasks

Das Gleiche gilt für für das Identifizieren von Tasks im Iteration Planning. Lediglich über diese Tasks nachzudenken ist schon der Mehrwert – und nicht notwendigerweise die eigentliche Liste.

Alles auf der Task-Liste hätte theoretisch auch in Echtzeit täglich während der Iteration identifiziert werden können. Tasks so spät zu identifizieren, kann allerdings zu Koordinationsproblemen und Verzögerungen führen. Wenn ich weiß, dass ich nächste Woche etwas von jemandem brauche, kann diese Person sich überlegen, wann sie diese Aufgabe erledigen wird. Wenn ich sofort etwas von jemandem benötige und nicht weitermachen kann, bevor diese Aufgabe erledigt ist, hat derjenige nicht den Luxus, selbst entscheiden zu können, wann er das erledigt. Derjenige muss jetzt daran arbeiten, denn ich warte ja darauf.

Sollte Ihr Team nun die Tasks im Iteration Planning identifizieren oder nicht?

Grundsätzlich: Ja. Ich glaube ein Team kann aufhören, die Tasks zu identifizieren, sobald sie Folgendes beherrschen:

Zusammenarbeit während der Iteration, um sich durch die neu entdeckten Items zu arbeiten.
Sie wissen, wie viele (und welche) Product Backlog Items sie in die Iteration aufgenommen sollten.
Meiner Meinung nach sollten Teams solange Tasks identifizieren, bis sie diesen Punkt erreicht haben. Denken Sie aber bitte daran, nur ungefähr zwei Drittel aller Tasks der Iteration zu identifizieren. Das ist ein guter Richtwert, um darüber nachzudenken, was alles erledigt werden muss, ohne das Ganze zu sehr zu zerdenken.

Das ist vergleichbar damit, die Expedition zum Mount Everest zu planen und zu wissen, dass man zumindest ein paar letzte Vorräte noch in Kathmandu kaufen kann.

Die Problematik der Task Identifizierung

Es gibt nämlich zwei Probleme, wenn Teams jeden einzelnen Task im Iteration Planning identifizieren möchten:

1. Es ist so gut wie unmöglich, alles außer den offensichtlichsten Dingen identifizieren zu wollen. Egal wie viel Mühe sich Ihr Team gibt, es wird ihnen nie gelingen, im Voraus an alles zu denken.

2. Es ist viel zu viel Arbeit.

Der Sinn und Zweck des Iteration Plannings ist es, die richtigen Product Backlog Items auszuwählen – und zwar genau die richtige Anzahl an Items, die am wichtigsten für die Auslieferung sind.

Ein Team kann all das tun, ohne an jede Kleinigkeit denken zu müssen, die in dieser Iteration erledigt werden muss. Solange die Teammitglieder sich über die wichtigsten Dinge Gedanken machen, können sie auch die richtige Menge der richtigen Product Backlog Items auswählen.

Dabei müssen die Teammitglieder an Folgendes denken:

• Große Tasks

• Tasks, die viel Koordination erfordern – und zwar entweder zwischen den einzelnen Teammitgliedern oder zwischen Teammitgliedern und Personen außerhalb des Teams

• Tasks, die höchstwahrscheinlich zum kritischen Pfad gehören

• Die ursprünglichen bzw. Haupttasks der Product Backlog Items, bei denen es noch viel Ungewissheit gibt

Abgesehen von diesen Punkten muss man nicht wirklich an etwas anderes denken. Das wäre nur eine große Zeitverschwendung und würde dazu führen, dass die Teammitglieder sich nicht mehr an den wichtigeren Meetings beteiligen möchten, da sie die Nase voll haben.

Was ein guter Scrum Master oder Agile Coach tun kann

Einige Iterationen lang sollte man keine Veränderungen vornehmen, außer die im Iteration Planning identifizierten Tasks zu zählen. Danach zählt man die Tasks, die am Ende der Iteration existieren. Man sollte alle Tasks zählen, auch die, die noch nicht fertiggestellt bzw. angefangen wurden.

Nachdem man das ein bis zwei Iterationen lang gemacht hat, wird der Prozentsatz der Tasks errechnet, die vom Team im Planning Meeting identifiziert wurden.

Ein Beispiel:

Nehmen wir an, ein Team hat drei Iterationen hinter sich gebracht. In der ersten Iteration identifizierte das Team 50 Tasks im Planning Meeting und am Ende der Iteration waren insgesamt 60 Tasks im Iteration Backlog. Das bedeutet, dass im Laufe der Iteration 10 Tasks hinzugekommen sind.

In der zweiten Iteration identifizierte das Team 45 von 60 Tasks im Planning Meeting. Und in der letzten Iteration 55 von letztendlich 70 Tasks.

Das heißt, dass das Team in den Planning Meetings 50 + 45 + 55 von insgesamt 60 + 60 + 70 Tasks identifiziert hat. Das sind 150 von insgesamt 180 Tasks. Das Team hat also 83 % aller Tasks während den drei Planning Meetings identifiziert.

Das ist zu viel.

Aus Erfahrung und nachdem ich diese Messung mit vielen Teams durchgeführt habe, kann ich sagen, dass erfolgreiche agile Teams ungefähr zwei Drittel aller Tasks im Planning identifizieren.

Wenn Ihr Team mehr als diese zwei Drittel in den Meetings identifiziert (wie das Team in dem oben genannten Beispiel), dann verbringt Ihr Team wahrscheinlich zu viel Zeit im Iteration Planning Meeting.

Erklären Sie das Ihrem Team beim nächsten Iteration Planning Meeting und gratulieren Sie den Teammitgliedern dazu, sich mit dem Planning so viel Mühe gemacht zu haben. Dann sagen Sie ihnen, dass Sie die Zeit dafür um 30 Minuten kürzen werden.

Sollte der Prozentsatz Ihres Teams jedoch unter 67 % liegen, teilen Sie auch diese Information mit den Teammitgliedern und sagen ihnen, dass sowohl das Team als auch Sie selbst davon profitieren werden, im Planning etwas gründlicher vorzugehen. Dann fügen Sie 30 Minuten zur Planungszeit hinzu.

Wiederholen Sie das so lange, bis Ihr Team ungefähr zwei Drittel aller Tasks im Planning Meeting identifiziert. Und noch einmal, ich sage nicht, dass man bei einer magischen Grenze die Diskussion einfach abbrechen sollte. Nutzen Sie dies einfach als praktische Richtlinie, um die richtige Menge an Zeit in den Iteration Planning Meetings dafür aufzuwenden.

Ich möchte nochmal darauf hinweisen, dass ich von zwei Drittel der Tasks eines Teams spreche. Das wird mit Sicherheit mehr sein als zwei Drittel der geplanten Zeit eines Iteration Planning Meetings. Die Tasks, die im Planning Meeting nicht identifiziert werden, sind meist die kleineren Tasks.

Lernen Sie mehr über die Unterstützung beim Planning oder Refinement in unserem zertifizierten ScrumMaster Training. Wenn Sie Ihrem Team dabei helfen, nur etwa zwei Drittel der Tasks einer Iteration zu identifizieren, werden Sie Ihren Team dabei helfen, mit Agile erfolgreich zu sein.