Christian Hütchen Agiles Projektmanagement nimmt zunehmend an Fahrt auf. Die Hintergründe hierzu sind ganz verschieden. Hat man sich einmal für das agile Arbeiten entschieden, gilt es sich von alten Verhaltensweisen zu verabschieden und das Mindset auf die neuen Gegebenheiten auszurichten. Das Verabschieden alter Verhaltensweisen fällt uns jedoch nicht nur im Privatleben, sondern auch im beruflichen Alltag besonders schwer. So kommt es, dass wir uns ganz unweigerlich Hürden in den Weg stellen, die unseren Erfolg verzögern.
In diesem Artikel möchte ich darauf eingehen, welche Stolperfallen beim Bewerten von Stories mit sogenannten Story Points auftreten können und wie diese verhindert werden können.
Was sind Story Points?
Story Points sind eine Kenngröße, mit der die Komplexität einer Story bewertet wird. Gerne wird beim Punktesystem auf die Fibonacci-Reihe (1,2,3,5,8,…) zurück gegriffen. Die Bewertung einzelner Stories findet im Vorfeld eines Sprints gemeinsam durch das Team statt. Ein Sprint ist ein fester Rahmen, in dem Stories abgearbeitet werden. Der Rahmen umfasst z.B. eine feste Definition von Zeit, beispielsweise eine Woche, sowie die maximale Anzahl Story Points, die das Team in der Lage ist abzuarbeiten. Mit Hilfe der Story Points wird also die maximale Anzahl an Stories festgelegt.
Gerade zu Beginn beim Arbeiten nach agilen Ansätzen kann es vorkommen, dass die Einschätzung der Komplexität von der tatsächlichen Komplexität abweicht. Das ist ein völlig natürlicher Prozess. Das Team muss sich an die neuen Herausforderungen gewöhnen und Stück für Stück nähern → In den „FLOW“ kommen.
Fatal wird es, wenn das Team nach einer gewissen Phase dennoch kontinuierlich die Ziele des geplanten Sprints verpasst, ohne dass hierfür erkennbare Gründe ersichtlich sind.
Anbei finden Sie einen Auszug an Möglichkeiten, die den Erfolg eines Sprints durch eine fehlerhafte Bewertung beeinflussen können:
- Die Stories wurden im Vorfeld nicht ausreichend vorbereitet und dokumentiert.
Ist eine Story inhaltlich unklar, so sollte es grundsätzlich zu keiner Bewertung kommen. Dennoch kommt es vor, dass davon ausgegangen wird, die Aufgabe sei jedem eindeutig klar und am Ende kommt es doch ganz anders als gedacht. Eine saubere Vorbereitung der Story ist ein essenzielles Fundament. Grundsätzlich sollte hier ein sehr großes Augenmerk darauf gelegt werden.
Ein unterschiedliches Verständnis der Story und der notwendigen Schritte führen zu unterschiedlichen Bewertungen und können am Ende zu einer komplett falschen Finalbewertung sowie erhöhtem Zeitaufwand für die Diskussion/Argumentation der Story führen. Jedem Team-Mitglied muss genau klar sein, was zu bewerten ist.
- Komplexität ist nicht gleich Aufwand
Es wird gerne in den Modus verfallen, dass eine Story nach Aufwand (altes Laster aus vergangenen Zeiten) bewertet wird. Dies ist jedoch nicht der Gedanke der Bewertung. Bewertet wird nach Komplexität!
Ein Beispiel für die Komplexität:
Das Update eines MySQL Clusters wird vom Team mit 13 Story Points bewertet. Begründet darin, dass mehrere Schritte erforderlich sind.
Ändert sich nun die Komplexität bei zukünftigen Stories, wenn ich ein weiteres MySQL Cluster aktualisiert werden soll? Nein, denn die dafür notwendigen Schritte bleiben identisch, ergo die Komplexität bleibt.
Bei der Bearbeitung ist auch immer davon auszugehen, dass diese Story ein Team-Mitglied durchführt, für welches die Durchführung zum ersten Mal erfolgt.
(Ein wesentlicher Aspekt im DevOps Umfeld ist, die Team-Mitglieder auf gleichem Know-how-Niveau zu halten, sodass jedes Mitglied in der Lage ist, jegliche Themenkomplexe umzusetzen. Das bedeutet, dass jedes Team-Mitglied mit den Themen zwangsläufig zum ersten Mal in Berührung kommen wird.)
Gerne fällt bei Bewertungen auch mal die Begründung: „Das habe ich schon x-mal gemacht, daher ist die Bewertung nun … (niedriger)?“ Bei solchen Argumentationen empfehle ich Achtsamkeit, denn diese impliziert, dass die Komplexität nicht im Vordergrund der Bewertung stand.
Bei der Bewertung der Komplexität empfiehlt sich aus meiner Sicht folgende Herangehensweise. Einfach jedes Mal folgende Frage an sich selbst stellen: „Wie würde ich herangehen, wenn ich diese Aufgabe zum ersten Mal angehen würden?“
- Festlegen der maximalen Story Points für einen Sprint
Die maximale Anzahl an Story Points ergibt sich aus der Teamstärke und dem aktuellen Kenntnisstand. Die maximale Anzahl an Story Points ist die Kenngröße, die festlegt, was das Team innerhalb eines Zeitraumes in der Lage ist abzuarbeiten. Aus psychologischer Sicht ist es empfehlenswert, wenn die Gesamtzahl der Story Points in zwei Bausteine unterteilt wird.
„Must-Do“ – 70 %
„Can-Do“ – 30 %
Auf die ersten 70 % wird sich im Sprint primär konzentriert. Sollte es unerwartet zu Verzögerungen kommen, ist genug Puffer, um das Wochenziel dennoch zu erreichen. Somit hat das Team am Ende mit hoher Wahrscheinlichkeit ein Erfolgserlebnis → Also ein Grund zum Feiern. Werden zusätzlich die „Can-Do“-Stories abgearbeitet, so steht gleich ein doppeltes Erfolgserlebnis ins Haus.
Bei der Festlegung der maximalen Story Points ist zu berücksichtigen, dass neben dem eigentlichen Do-ing auch regelmäßige StandUps, Plannings, etc. anfallen und sich die zur Verfügung stehenden Zeiten reduzieren. Das Team wird sich über den Zeitraum entwickeln und anstehende Aufgaben zunehmend schneller umsetzen. In diesem Fall ist die maximale Anzahl an Story Points anzupassen, um einer Unterforderung vorzubeugen.
Umfang einer Story
Grundsätzlich sollten Stories auf ein Minimum herunter gebrochen werden. Dies ermöglicht eine einfachere Bewertung durch Fokussierung auf einzelne „kleinere“ Schritte mit geringerer Komplexität.
Zum Beispiel könnte für das Deployment einer virtuellen Maschine explizit eine Story von mehreren Stories angelegt werden, welche sich ausschließlich mit dem Download eines OVA-Templates beschäftigt. Dieser Task ist einfacher zu bewerten als ein komplettes Deployment mit allen Abhängigkeiten innerhalb einer Story. Unterschiede in der Bewertung sollten hierbei nicht zu weit voneinander abweichen, sodass die Zeitaufwände für die Argumentation ebenfalls gering ausfallen werden.
Ganz grundsätzlich wird es bei der Bewertung von Stories immer zu unterschiedlichen Meinungen und Einschätzungen kommen. Insofern die Unterschiede geringfügig sind oder permanente Verfehlungen ausbleiben, ist noch kein großer Grund für Besorgnis. Um dem Vorzubeugen empfiehlt sich ein regelmäßiger Review der Stories, ob die Komplexität zu Beginn korrekt eingeschätzt wurde. Ist dies der Fall, könnte dies zu einer Referenz-Story avancieren, um zukünftige Story-Bewertungen zu vereinfachen und zu beschleunigen.
