LuckyStep - stock.adobe.com
Was sind Story Points und wie verwendet man sie in Agile?
Komplexe Variablen und unbekannte Faktoren können die Abschätzung des zeitlichen Aufwands für Entwicklungsprojekte erschweren. Story Points könne Abhilfe schaffen.
Oftmals ist der schwierigste Teil der Softwareentwicklung nicht die technische Arbeit des Entwerfens und Schreibens von Code. Es ist die Vorhersage, wie lange es dauern wird, diese Arbeit abzuschließen.
Genaue Arbeitseinschätzungen sind von entscheidender Bedeutung, um Stakeholdern, wie zum Beispiel Produkteigentümer, eine zuverlässige Erwartung zu vermitteln, wann eine neue Anwendung oder Funktion verfügbar sein wird. Genaue Schätzungen zu erstellen, ist jedoch aufgrund der vielen Variablen und Unbekannten innerhalb des Software Development Lifecycles (SDLC) in der Regel eine ziemliche Herausforderung.
Eine Möglichkeit, diese Herausforderung zu bewältigen, sind agile Story Points. Durch einen flexiblen Ansatz bei der agilen Schätzung – das heißt die Vorhersage, wie lange eine Aufgabe während der agilen Softwareentwicklung dauern wird – helfen Story Points Teams bei der Planung von Sprints, der termingerechten Erledigung von Aufgaben und der effizienteren Arbeitsweise.
Was sind Story Points in Agile?
Im agilen Projektmanagement sind Story Points Maßeinheiten, mit denen Teams den Zeit- und Arbeitsaufwand für die Erledigung verschiedener Aufgaben abschätzen können.
Story Points ermöglichen ein System der Zeitschätzung, das auf einer relativen Basis funktioniert. Das bedeutet, dass Teams nicht vorhersagen, wie lange eine Aufgabe in Stunden, Tagen oder Wochen dauern könnte, sondern Story Points verwenden, um die geschätzte Fertigstellungszeit einer Aufgabe mit der einer anderen zu vergleichen.
Beispielsweise kann das Team einem Produktrückstand vier Story Points zuweisen, zum Beispiel einer User Story, die die Implementierung einer einfachen neuen Funktion beinhaltet. Ein anderes Element kann hingegen acht Story Points erhalten, weil das Team davon ausgeht, dass die Fertigstellung doppelt so lange dauern und doppelt so viel Aufwand erfordern wird wie die User Story mit vier Punkten.
Mithilfe von Story Points können Teams Sprints – also feste Zeiträume, in denen sie an einem Projekt arbeiten, in der Regel zwischen einer und vier Wochen – in kleinere Arbeitseinheiten aufteilen und die Zeit und den Aufwand schätzen, die jede einzelne Einheit im Verhältnis zum gesamten Sprint erfordern wird.
Story Points versus Zeitschätzungen
Teams benötigen keine Story Points, um Scrum oder andere beliebte agile Methoden zu praktizieren. Ein alternativer Ansatz besteht darin, Sprints mit direkten Zeitschätzungen zu planen. Teams können beispielsweise zwei Tage für die Fertigstellung einer User Story und vier Tage für eine andere einplanen.
Zeitschätzungen können in Szenarien gut funktionieren, in denen die folgenden Bedingungen erfüllt sind:
- Alle Mitglieder des Softwareentwicklungsteams können ungefähr im gleichen Tempo arbeiten, das heißt ein Entwickler ist in der Lage, eine bestimmte Aufgabe in der gleichen Zeit wie jeder andere zu erledigen.
- Die Arbeitsaufgaben sind gut verständlich, bevor die Arbeit beginnt, sodass sich die Dauer einer Aufgabe leichter genau vorhersagen lässt.
- Nur wenige Risiken und Unwägbarkeiten, wie zum Beispiel ein unerwarteter Serverausfall, der Arbeitsabläufe unterbrechen könnte, drohen die Fertigstellung der Arbeitsaufgabe zu verzögern.
Die meisten Entwicklungsprojekte sind jedoch selten so konsistent, vorhersehbar und risikoarm. Viel häufiger arbeiten in Teams Ingenieure mit unterschiedlichem Erfahrungsniveau, sodass nicht alle im gleichen Tempo arbeiten können. Darüber hinaus ist es oft schwierig, den genauen Zeit- und Arbeitsaufwand für die Erledigung einer Aufgabe mit hoher Genauigkeit vorherzusagen, da Entwickler erst bei der Arbeit an einer Aufgabe genau wissen, wie schwierig oder zeitaufwendig sie sein wird.
Vorteile bei der Verwendung von Story Points in Agile
Es ist praktisch unmöglich, die verschiedenen Risiken und Unwägbarkeiten zu vermeiden, die Projekte zum Scheitern bringen könnten. Aus diesem Grund ist ein Story Point oft eine bessere Maßeinheit für Zeit und Aufwand als die Verwendung einfacher Zeitschätzungsmethoden. Die relative Natur von Story Points bedeutet, dass Teams nicht daran gebunden sind, eine Aufgabe innerhalb eines festgelegten Zeitraums zu erledigen – und sie laufen auch nicht Gefahr, sich als Versager zu fühlen oder in Verzug zu geraten, wenn sie ein in Stunden oder Tagen definiertes Ziel verfehlen.
Darüber hinaus bieten Story Points den Vorteil, dass Teams die Wertschöpfung in Bezug auf den Aufwand für eine Aufgabe und nicht in Bezug auf die dafür aufgewendeten Gesamtstunden betrachten können. Auf diese Weise ermutigen Story Points Entwickler, innovativ und effizient zu arbeiten, um komplexe Aufgaben zu erledigen. Sie verhindern auch die unproduktive Praxis, Arbeit künstlich zu strecken, um sie an die dafür vorgesehene Stundenzahl anzupassen, wenn eine Aufgabe früher erledigt werden könnte.
Wie man Story Points in Agile verwendet
Story Points lassen sich am besten implementieren, indem der Prozess in fünf grundlegende Schritte unterteilt wird – sei es für ein neues Projekt oder für ein bestehendes Projekt, bei dem derzeit eine andere Zeitschätzungsmethode verwendet wird.
1. Das Team über Story Points informieren
Zunächst muss sichergestellt werden, dass alle Teammitglieder mit Story Points vertraut sind. Dies ist besonders wichtig bei Projekten, die von einer anderen Methode auf Story Points umgestellt werden oder bei denen die Entwickler bisher keine Story Points verwendet haben.
Um Zustimmung zu erhalten, sollten Projektmanager die Stakeholder darüber informieren, wie Story Points funktionieren und welche Vorteile sie gegenüber alternativen Methoden bieten.
2. Erstellen Sie eine Story-Point-Sequenz
Bevor sie Aufgaben Story Points zuweisen können, sollten Teams akzeptable Story Point-Werte festlegen. Dies ist wichtig, da Story Points am besten funktionieren, wenn es einen bestimmten Satz von Zahlen gibt, den Teams bei der Zuweisung von Story Points zu einer Aufgabe verwenden können. Andernfalls können sie am Ende zu spezifische Story Point-Werte zuweisen, wie zum Beispiel 2,8 oder 9,35. Dies untergräbt den Wert der Verwendung von Story Points, da es zu starren Schätzungen führt, die wahrscheinlich nicht genau sind.
Ein gängiger Ansatz zur Festlegung einer Reihe akzeptabler Punktwerte ist die Verwendung einer festen Zahlenfolge, wie zum Beispiel der Fibonacci-Folge, bei der jede weitere Zahl der Summe der vorhergehenden Zahlen entspricht – 1, 2, 3, 5, 8, 13, 21 und so weiter.
3. Erstellen Sie eine Story-Point-Matrix
Eine Story-Point-Matrix beschreibt in einfachen Worten die Arten von Aufgaben und den Umfang der Arbeit, die das Team mit Story-Point-Werten verknüpfen sollte. Eine grundlegende Story-Point-Matrix für Werte, die aus der Fibonacci-Folge abgeleitet werden, könnte beispielsweise wie folgt aussehen:
| Story-Point-Wert | Aufwand | Zeitaufwand | Schwierigkeitsgrad | Risiko und Unsicherheit |
| 1 | Minimal | Weniger als eine Stunde | Minimal | Keine |
| 2 | Niedrig | Eine Stunde | Niedrig | Minimal |
| 3 | Mittel | Mehrere Stunden | Mittel | Moderat |
| 5 | Mittel | Ein Tag | Mittel | Moderat |
| 8 | Signifikant | Ein bis zwei Tage | Hoch | Hoch |
| 13 | Hoch | Eine Woche | Hoch | Hoch |
| 21 | Maximal | Zwei bis vier Wochen | Sehr hoch | Sehr hoch |
4. Schätzung der Story Points für einen Sprint
Wenn die Story-Point-Matrix vollständig ist, kann das Team damit beginnen, Story Points bestimmten Arbeitselementen zuzuweisen.
Eine beliebte Methode hierfür ist die Durchführung eines Planning-Poker-Meetings, bei dem Entwickler Karten verwenden, um die mit jeder Aufgabe verbundene Zeit, den Aufwand und das Risiko abzuschätzen. In einem typischen Planning-Poker-Meeting besprechen die Teilnehmer jede User Story einzeln. Anschließend wählt jeder Teilnehmer eine Karte aus, die angibt, wie viele Story Points die Story seiner Meinung nach erhalten sollte.
Wenn alle oder die meisten Karten übereinstimmen, hat das Team einen Konsens erzielt und kann sich auf die Anzahl der Story Points für die Aufgabe einigen. Andernfalls geht es zurück in die Diskussionsphase, in der die Teilnehmer weitere Erkenntnisse darüber austauschen können, warum sie der Meinung sind, dass die Aufgabe einen höheren oder niedrigeren Punktwert erhalten sollte, bevor sie erneut Karten auswählen. Das Team wiederholt diesen Prozess, bis es ein gemeinsames Verständnis erreicht hat, und arbeitet dann auf die gleiche Weise weitere User Stories ab.
5. Nachverfolgung und Verbesserung der Story-Point-Schätzung
Der letzte Schritt im agilen Story-Point-Implementierungsprozess besteht darin, zu überwachen, wie genau die Story-Point-Schätzungen den tatsächlichen Zeit-, Arbeits- und Risikolevel widerspiegeln. Nachdem das Team jeden Sprint abgeschlossen hat, sollte es diese Daten überprüfen und die gewonnenen Erkenntnisse nutzen, um die Story-Point-Schätzungen für den nächsten Sprint zu verbessern.
Die Daten können beispielsweise zeigen, dass das Team den angemessenen Story-Point-Wert für eine bestimmte Art von User Story deutlich unterschätzt hat. Wenn eine ähnliche User Story auftaucht, können die Entwickler diesen Fehler vermeiden.
