Story Points Definition
In der agilen Softwareentwicklung kommen oftmals sogennante Story Points (auch: Scrum Points; agile Points; Storypoints) zum Einsatz, um eine Aufwandsschätzung durchzuführen. Dabei wird zumeist nicht der Aufwand in Personentage zum Erledigen geschätzt, sondern die Komplexität einer Aufgabe. Die Definition der Komplexität erarbeitet und definiert dabei das Team.
In der Regel sind hohe Schätzwerte ein Indiz dafür, dass die aktuellen Informationen nicht ausreichen, um eine konkrete Schätzung abgeben zu können. Gegebenfalls muss in einem solchen Fall der Product Owner mehr Informationen und Anforderungen liefern oder das Team muss die Story in besser schätzbare Teile auseinander brechen.
1. Erstellen eines Wertebereiches
Als Wertebereich wird zumeist die Fibonacci-Reihenfolge bis 13, ergänzt mit 20, 40 und 100, verwendet. Zur Verdeutlichung der Bedeutung eines Wertes, kann eine Wertetabelle erstellt werden. Ein Beispiel stellt die folgende Tabelle dar:
| Wert | Bedeutung | Beschreibung |
|---|---|---|
| 0 | – | Bereits erledigt |
| 1 | Sehr klein | Aufgabe mit niedriger Komplexität |
| 2 | Klein | Doppelt so große Komplexität wie eine sehr kleine Aufgabe |
| 3 | Mittel | Entspricht einer sehr kleinen und kleinen Aufgabe |
| 5 | Mittelgroß | Komplexität entspricht bereits einer mittleren Aufgabe und einer kleinen Aufgabe |
| 8 | Groß | Komplexität entspricht einer mittelgroßen und einer mittleren Aufgabe |
| 13 | Sehr groß | Komplexität entspricht einer großen und einer mittelgroßen Aufgabe |
| 20 | Riesig | Ca. so groß wie eine große und eine sehr große Aufgabe zusammen |
| 40 | Gigantisch | Kaum schätzbar, doch mindestens so groß wie zwei riesige Aufgaben |
| 100 | Unendlich | Nicht schätzbar mit aktuellem Wissenstand. Unfassbar! |
2. Der Vorteil von Sprint Story Points
Die Verwendung von Story Points hat den Vorteil, dass anhand einer Schätzung nicht auf Anhieb der Aufwand abgeleitet werden kann. Schätzungen sind somit weiterhin das, was sie sind: eine vage Ausgabe über die Komplexität, basierend auf einer Schätzung. Ein weiterer Vorteil ist, dass Schätzungen basierend auf Story Points nicht verwendet werden können, um die Performance von Team-Mitgliedern oder Teams miteinander vergleichen zu können. Jedes Team erstellt für sich selbst eine eigene Wertetabelle der Schätzpunkte und findet ein für sich passendes System, um Aufgaben zu schätzen. Daher sind Abweichungen innerhalb eines Unternehmens bisweilen unausweichlich.
3. Referenz-Story
Eine Methode zum Definieren einer Wertetabelle ist das Heranziehen einer Referenz-Story. Dabei einigt sich das Team zunächst auf eine Referenz-Story, die nicht zu groß und nicht zu klein ist und die von allen Team-Mitgliedern geschätzt werden kann. Aufbauend auf dieser Referenz, werden die weiteren Stories im Backlog geschätzt und in eine Relation zueinander gesetzt. Aufgaben mit vergleichbaren Schätzungen können gestapelt werden, so dass im Idealfall am Ende eine überschaubare Anzahl Stapel übrig bleibt. Eine Lösung zum Aufbau der Wertetabelle kann sein, dass der Stapel mit der niedrigsten Schätzung die Story Point-Wertung 1 erhält, der nächste Stapel die 2 usw.
4. Schätzung der Dauer anhand der Velocity
Um aus geschätzten Stories ableiten zu können, wie lange es in etwa dauern wird, bis sie umgesetzt worden sind, wird die Velocity herangezogen. Die Velocity ist der Durchsatz an Story Points, den das Team bisher erzielt hat (bzw. die Anzahl der Story Points, die das Team pro Sprint erledigt). Über mehrere Sprints hinweg wird festgehalten, wie viele Story Points erledigt werden konnten. Bleiben Wertetabelle, Referenz-Stories und Team-Zusammensetzung über diesen Zeitraum gleich, kann diese Velocity zur Release-Planung verwendet werden. Ein eingespieltes Team wird im Laufe eines Projektes die Velocity vermutlich steigern und folglich mehr Story Points pro Sprints als am Anfang umsetzen können. Die Schätzungen der Stories sind davon nicht betroffen und müssen nicht angepasst werden, da sie lediglich etwas über die Komplexität, aber nicht den Aufwand aussagen.
Wenn Du die hier vorgestellten Punkte umgesetzt hast, kannst Du mit dem Schätzen der User Stories im Product Backlog beginnen. Solltest Du bereits über viele User Stories verfügen, kannst Du eine Schätzmethode dafür einsetzen. So lässt sich zum Beispiel mithilfe von Magic Estimation das gesamte Backlog in 60 Minuten schätzen.
Workshop-Methode: Planning Poker
Eine bewährte Methode zur Schätzung von Story Points in einem Workshop-Format ist Planning Poker. Diese Methode fördert die Zusammenarbeit und Diskussion innerhalb des Teams und hilft dabei, eine gemeinsame Einschätzung der Komplexität zu erreichen.
Ablauf des Planning Poker Workshops:
- Vorbereitung:
- Jeder Teilnehmer erhält ein Set von Planning Poker Karten mit den Werten der Fibonacci-Reihe (1, 2, 3, 5, 8, 13, 20, 40, 100).
- Der Product Owner stellt die zu schätzenden User Stories vor und beantwortet Fragen zur Klärung.
- Schätzungsrunde:
- Jede User Story wird nacheinander besprochen.
- Nach der Diskussion wählen alle Teammitglieder gleichzeitig eine Karte, die ihrer Schätzung der Komplexität entspricht, und legen sie verdeckt auf den Tisch.
- Aufdecken und Diskussion:
- Alle Karten werden gleichzeitig aufgedeckt.
- Bei großen Abweichungen in den Schätzungen diskutiert das Team die Gründe für die unterschiedlichen Einschätzungen.
- Nach der Diskussion wird erneut abgestimmt, bis eine Einigung erzielt wird.
- Dokumentation:
- Die finalen Schätzungen werden dokumentiert und in das Product Backlog eingetragen.
Weiterführender Aspekt 1: Berücksichtigung von Unsicherheiten
Bei der Schätzung von Story Points ist es wichtig, Unsicherheiten zu berücksichtigen. Hohe Schätzwerte können auf Unsicherheiten hinweisen, die durch fehlende Informationen oder unklare Anforderungen entstehen. Um diese Unsicherheiten zu minimieren, können folgende Maßnahmen ergriffen werden:
- Spike Stories: Diese speziellen User Stories dienen dazu, Unsicherheiten zu klären und notwendige Informationen zu sammeln, bevor eine genaue Schätzung vorgenommen wird.
- Refinement Meetings: Regelmäßige Meetings zur Verfeinerung des Backlogs helfen dabei, offene Fragen zu klären und die Anforderungen präziser zu definieren.
Weiterführender Aspekt 2: Kontinuierliche Verbesserung der Schätzmethoden
Die Schätzung von Story Points ist ein iterativer Prozess, der kontinuierlich verbessert werden kann. Teams sollten regelmäßig ihre Schätzmethoden und -prozesse überprüfen und anpassen, um die Genauigkeit und Effizienz zu steigern. Hier sind einige Ansätze zur kontinuierlichen Verbesserung:
- Retrospektiven: In regelmäßigen Retrospektiven kann das Team die Schätzprozesse reflektieren und Verbesserungspotenziale identifizieren.
- Feedback-Schleifen: Durch das Einholen von Feedback nach jedem Sprint können Teams ihre Schätzungen mit den tatsächlichen Ergebnissen vergleichen und daraus lernen.
- Schulungen und Workshops: Regelmäßige Schulungen und Workshops zu agilen Schätzmethoden können das Wissen und die Fähigkeiten des Teams erweitern.
Das könnte Dich auch interessieren:
- Agiles Projektmanagement mit SCRUM
- Das Estimation Meeting als Sprint Vorbereitung
- Definition of Ready & Definition of Done
- Das Scrum Team Kick off
