Agiles Schätzen und Planen

In unseren Erfahrungen mit Scrum hat sich in der Vergangenheit immer wieder gezeigt, dass eine sorgfältige Sprint-Planung mit das Wichtigste Artefakt in Scrum ist. Sie entscheidet darüber, ob der anschließende Iterationszyklus das gewünschte Ergebnis liefert, oder aber in einem kompletten Chaos endet. Letzeres soll natürlich vermieden werden, wenn es irgendwie geht. Doch wie stellt man das am besten an?

Als Beispiel für eine funktionierende Sprintplanung möchte ich hier die Methode vorstellen, die Henrik Kniberg in seinem sehr empfehlenswerten Buch „Scrum and XP from the trenches“ gibt.

Grundlage für eine erfolgreiche Sprint-Planung ist ein einigermaßen sauber geführtes Product Backlog. Mit „einigermaßen sauber” meine ich hier:

• Es sollte existieren,
• auf dem aktuellen Stand sein, und
• die einzelnen Einträge sollten nach Geschäftswert priorisiert sein.

Ideal wäre außerdem noch, wenn es zu jedem Eintrag noch ein definiertes Abnahmekriterium gäbe („How to demo”), da sich so im Vorfeld bereits einige Missverständnisse ausräumen lassen (etwa über den Umfang des Eintrags). Dies alles liegt natürlich in der Verantwortlichkeit des Product Owners. Es ist daher unbedingt erforderlich, dass dieser seine Aufgabe auch ernst nimmt!

Sind diese Voraussetzungen erfüllt, so kann die eigentliche Planung beginnen. Hierfür sollte man sich genügend Zeit nehmen. Mein Vorschlag ist, sich pro Woche, die der anschließende Sprint dauert, in etwa 1 Stunde Zeit zu nehmen. Bei einem 4-wöchigen Zyklus wären das also 4 Stunden. Hört sich zwar lange an (das ganze Team einen halben Tag in Beschlag zu nehmen), ist aber jede investierte Minute wert!

Am Ende sollte man folgendes erreicht haben:

• Man hat ein Ziel für den Sprint festgelegt,
• ein Sprint Backlog erstellt,
• Termine für Sprint Review und das tägliche Statusmeeting ausgemacht, sowie
• eine Liste der Teammitglieder samt ihrer Verfügbarkeit.

Zuerst sollte man sich Gedanken darüber machen, welche Einträge aus dem Product Backlog man für den neuen Sprint übernimmt. Da diese Einträge nach Geschäftswert priorisiert sind ist dieser Schritt zunächst einmal relativ leicht:

Man beginnt am oberen Ende der Liste und übernimmt einfach so viele Einträge, wie man meint innerhalb einer Iteration realisieren zu können. Wieviele Einträge dies sind? Dazu schätzt man den Aufwand der ausgewählten Einträge und gleicht den ermittelten Wert dann mit den Erfahrungswerten aus vorangegangenen Iterationszyklen ab. Diese Technik wird „yesterday’s weather” genannt.

Natürlich steht ein solcher Erfahrungswert nicht immer zur Verfügung. Sollte dies der Fall sein, so kann man auch eine einfache Art der Ressourcenkalkulation verwenden. Basis hierfür bildet die Zahl der verfügbaren Manntage im Sprint. Bei einem 4-wöchigen Sprint in einem Team von 5 Leuten könnte eine solche Planung dann etwa wie folgt aussehen:

• Adam: 20 Manntage
• Bertram: 18 Manntage (hat 2 Urlaubstage genommen)
• Cäsar: 20 Manntage
• Dora: 10 Manntage (steht nur zu 50% zur Verfügung)
• Egbert: 20 Manntage

Insgesamt stehen für den Sprint also 88 Manntage zur Verfügung. Kann man nun also in diesem Sprint also nun Einträge im Wert von 88 Story Points realisieren? Nein, da die Einheit für Story Points aus „idealen Manntagen” besteht. Ein solcher idealer Manntag ist ein Tag, an dem eine Person die ganze Zeit über produktiv arbeitet, ohne jegliche Art von Pausen, Störungen oder Krankheit. Dies kommt in der Realität natürlich nicht allzu häufig vor. Der tatsächliche Wert wird daher etwas unter diesem Idealwert liegen. Diesen Unterschied zwischen idealem und realem Wert nennt man auch den „Fokusfaktor”.

Die Anzahl der in einem Sprint erreichbaren Story Points ist also [Zahl der Manntage] x [Fokusfaktor]. Den Fokusfaktor kann man z.B. aus vorangegangenen Sprints berechnen (über die Formel: Fokusfaktor = [realisierte Story Points] / [ Gesamtzahl Manntage]). Besser noch ist es natürlich, einen Mittelwert über mehrere Sprints zu verwenden.

Angenommen, im letzten Sprint wurden bei 90 zur Verfügung stehenden Manntagen Stories im Wert von 60 Story Points realisiert, so errechnet sich daraus ein Fokusfaktor von 60/90 = 0,66.

Für den neuen Sprint würde das dann bedeuten, dass wir damit planen können, insgesamt Einträge in der Höhe von 88 * 0,66 = 58 Story Points umzusetzen.

Was aber, wenn noch kein solcher Fokusfaktor existiert? Hier könnte man versuchen, ins Unternehmen zu schauen und ein Team zum Vorbild zu nehmen, das unter vergleichbaren Umständen arbeitet, oder aber (falls auch das nicht möglich ist) einfach einen Faktor zu schätzen. Dies hört sich im ersten Moment zwar etwas unprofessionell an, ist aber vertretbar, da dieser Fall eh nur im ersten Sprint eines neuen Projekts auftreten kann. Bereits ab dem zweiten Sprint kann man wieder echte Daten verwenden. In der Literatur (Link einfügen: „Scrum and XP from the trenches”) findet sich hier ein Wert von ~0,7, was auch in etwa unseren Erfahrungen entspricht. Falls Sie sich also keinen Wert selbst ausdenken wollen, so können Sie gerne diesen verwenden.

Der Fokusfaktor eignet sich übrigens nicht nur zum Planen eines neuen Sprints. Da er ja die Differenz zwischen idealen und tatsächlichen Manntagen darstellt, beinhaltet er somit auch alle Umweltfaktoren. Dies kann auch als Druckmittel bei Verhandlungen mit dem Product Owner dienen, wenn es etwa darum geht, Probleme zu beseitigen, die das Team in seiner täglichen Arbeit behindern. Man denke hier nur an eine im Hochsommer ausfallende Klimaanlage oder an häufig auftretende Netzwerkprobleme. Beides würde sich in einer Verringerung des Fokusfaktors niederschlagen, und somit einen direkten negativen Einfluss auf den Projekterfolg haben. Eine Beseitigung dieser Probleme hätte jedoch wieder eine Erhöhung des Fokusfaktors zur Folge, und damit auch eine Erhöhung der realisierbaren Story Points innerhalb eines Sprints.

Am Ende dieses Abschnitts wissen wir nun also, wie viele Story Points wir in diesem Sprint realisieren können. Um nun jedoch zu einer tatsächlichen Liste von Funktionen zu kommen, müssen zuerst noch alle in Frage kommenden Einträge des Product Backlogs beschätzt werden. Die Methode, die wir in solchen Fällen immer einsetzen, nennt sich „Planning Poker”. Wie diese genau funktioniert, darüber mehr im nächsten Artikel.

BFE