Agile Entwicklung – wie Story Points funktionieren
Softwareentwicklung ist eine Kunst, agile Entwicklung erst recht. Dennoch kommt es auch hier bisweilen auf möglichst genaue Bewertungen an. Story Points sind ein Lösungsansatz, der funktioniert – wenn man nicht nur auf eine abstrakte Zahl abzielt, sondern sich im Team ein gemeinsames Verständnis des Aufwands erarbeitet.
Messbarkeit ist in der agilen Welt ein beliebtes Diskussionsthema: Man kann Abende damit füllen, ob man jetzt Story Points hernehmen soll oder nicht, welche Alternativen es gibt und welche Methode noch funktioniert.
Ich finde diese Diskussionen fair, weil sie sehr schön aufzeigen, dass wir verschiedene Werkzeuge haben, die für einen bestimmten Zweck zum Einsatz kommen. So wie ich einen Hammer nehme, um einen Nagel in die Wand zu schlagen, und keinen Schraubenzieher. OK, vielleicht kann ich mir noch mit einem Schuh behelfen, aber Sie verstehen, was ich meine. Nicht jedes Werkzeug ist für jeden Zweck geeignet…
Agile Arbeitsmethoden basieren auf Empirie: Wissen wird aus gesammelten Daten gewonnen. Bei einfachen Aufgaben, die immer einem gleichen Ablauf folgen und bei denen ich direkt Ursache und Wirkung benennen kann, kann ich einfach Vorhersagen treffen: Wenn ich einen Topf Wasser auf die heiße Herdplatte stelle, wird es voraussichtlich kochen. Begeben wir uns aber in komplexere Bereiche, wird es schwieriger, weil wir den Umfang nicht genau kennen und nicht genau wissen, wie wir vorgehen. Das heißt, wir müssen erst einmal ausprobieren, schauen was funktioniert und dann damit weitermachen. Und damit wir uns hier nicht auf „schauen wir mal, dann sehen wir schon“ verlassen, überlegen wir uns in agilen Arbeitsweisen, welche Messgrößen Sinn machen: Messen wir das Richtige und messen wir richtig?
Story Points als agile Messgröße
Und hier kommen Story Points ins Spiel. Story Points sind eine Messgröße, eine Zahl aus der Fibonacci- oder Cohn-Skala, die Komplexität und Aufwand repräsentiert. Dadurch, dass wir im komplexen Umfeld nicht immer genau wissen, was passieren wird und wie, fällt es uns schwer, eine ultimative Zahl, zum Beispiel die Zeit, hinter eine Aufgabe zu schreiben. Das ist ja im einfachen Umfeld schon schwer. Und wenn dann im komplexen Bereich noch eine Unbekannte dazu kommt, wird es noch schwieriger. Daher betrachten wir in agilen Projekten nicht nur die Zeit, sondern auch Schwierigkeit, Abhängigkeiten oder Risiken.
Kaffee ist nicht gleich Kaffee
Ein kurzer Exkurs zur Komplexität: Für die Zubereitung des Kaffees am Morgen gibt es viele verschiedene Möglichkeiten. Meine Großmutter mag Instant-Kaffee, ich bevorzuge Filterkaffee aus der Maschine, eine Kollegin liebt ihre Mocca-Kanne und schäumt sich dazu Milch auf, und ein anderer Kollege holt sich seinen fertigen Cappuccino aus dem Kaffeeautomaten. Ich hoffe, wir können uns darauf einigen, dass Instantkaffee eine andere Komplexität hat als der Mocca, bei dem wir noch zusätzlich Milch aufschäumen.
Komplexität von Aufgaben bestimmen
Wir bestimmen also mit einer relativen Zahl die Komplexität einer Aufgabe. Der Kaffeeautomat hat eine Komplexität von 1 Punkt, Instant-Kaffee 2 Punkte, Filtermaschinenkaffee 3 Punkte, Mocca mit Milchschaum 5 Punkte. Wenn Sie mir hier nicht zustimmen, haben wir herausgefunden, wie man Story Points richtig verwendet: Falls Sie nämlich sagen, Instant-Kaffee hat auch 5 Punkte, weil ich das Wasser dafür erst von einer Quelle hole, dann können wir darüber sprechen und ein gemeinsames Verständnis über die Aufgabe bekommen.
Indem wir uns im Team über unsere individuellen Ansichten – ausgedrückt durch eine Schätzung in Zahlenform – unterhalten, bekommen wir ein gemeinsames Verständnis von der Komplexität einer Aufgabe, weil wir darüber sprechen, was mit der Aufgabe alles verbunden ist. Wir können anfangen, Komplexität in Relation zueinander zu bringen, ob Themen größer oder kleiner sind – im Verhältnis zueinander. Und dadurch, dass wir Zahlen verwenden, können wir damit rechnen – dann ist es nur noch Mathe.
Wahrscheinlichkeiten bestimmen
Wir können eine genauere Wahrscheinlichkeit berechnen, wann wir unseren Kunden etwas liefern können. Wir bekommen eine bessere Vorhersagbarkeit, was wir als Team in einem Sprint umsetzen können. Außerdem sorgen wir dafür, dass das Team mit einer nachhaltigen Auslastung regelmäßig liefern kann. Wenn wir im Schnitt 30 Story Points liefern, macht es keinen Sinn, 60 einzuplanen. Wenn in ein Glas ein Liter Wasser passt, wäre es nicht gut, zwei Liter reinzuschütten. Der kleine, aber feine Unterschied liegt hier darin, einem Backlog Item einfach einen Zahlenwert zu geben und dadurch ein gemeinsames Verständnis im Team zu schaffen.
Story Points hinterfragen
Allerdings geht es Teams häufig nur noch darum, eine Zahl an das Backlog Item zu bekommen. Typische Aussagen: „Wer kümmert sich denn um diesen Task? Patrizia? Ah ja, dann sag mal, wie viele Points das hat. Wir wissen ja nicht, worum es hier geht.” Und genau hier liegt das Problem: Story Points können meiner Meinung nach nur dann sinnvoll eingesetzt werden, wenn ein gemeinsames Verständnis über die Komplexität und den Aufwand der Arbeit besteht. Wir müssen hinterfragen, worum es geht, was erreicht werden soll, welcher Mehrwert geliefert wird. Und was es braucht, um diesen Mehrwert zu liefern.
Dann erst kann das Team als Einheit die Story Points genauer schätzen. Und dann kann ich als Agile Coach oder Scrum Master darüber sprechen, wenn einzelne Teammitglieder unterschiedliche Ansichten über die Höhe der Schätzung haben. Um als Ergebnis eben ein gemeinsames Verständnis über unser Produkt zu bekommen. Für mich sind Story Points ein gutes Messwerkzeug, wenn Teams sie richtig verwenden und nicht versuchen, eine Schraube mit einem Hammer in die Wand zu bekommen. Das kann funktionieren, aber wirklich gut ist es nicht.
Sie haben Fragen zum Thema agile Teamarbeit? Dann kontaktieren Sie mich gerne direkt über die Kontaktdaten in meinem Autorenprofil oder über LinkedIn.
