Story Points: Agile Schätzung mit Fibonacci & Planning Poker

Story Points sind eine relative Maßeinheit in agilen Projekten zur Schätzung von Aufwand, Komplexität und Risiko. Teams nutzen die Fibonacci-Skala und Planning Poker, um Backlog-Items zu bewerten. Die daraus berechnete Velocity ermöglicht verlässliche Sprint- und Release-Planung.

Kategorie:Agile Methoden

Story Points sind eine relative Maßeinheit in der agilen Softwareentwicklung, die verwendet wird, um den Arbeitsaufwand für die Umsetzung einer User Story oder eines Backlog-Items zu schätzen. Im Gegensatz zu absoluten Zeitschätzungen (wie Stunden oder Tagen) repräsentieren Story Points eine relative Größe, die verschiedene Faktoren berücksichtigt.

Was machen Story Points einzigartig?

Story Points unterscheiden sich von traditionellen Zeitschätzungen durch mehrere Eigenschaften:

  • Relativität: Story Points drücken das Verhältnis zwischen verschiedenen Aufgaben aus, nicht deren absolute Dauer.
  • Ganzheitlichkeit: Sie berücksichtigen nicht nur den reinen Arbeitsaufwand, sondern auch Komplexität, Unsicherheit und Risiko.
  • Teambasierung: Die Bedeutung eines Story Points ist teamspezifisch und variiert zwischen verschiedenen Teams.
  • Abstraktion: Sie lösen die Schätzung von individuellen Leistungsunterschieden und externen Faktoren.

Bestandteile von Story Points

Bei der Bewertung mit Story Points werden typischerweise drei Hauptfaktoren berücksichtigt:

  1. Komplexität: Wie komplex ist die technische Umsetzung? Wie viele Komponenten sind betroffen? Wie viel Denkarbeit ist erforderlich?
  2. Unsicherheit/Risiko: Wie neu oder unbekannt ist die Technologie? Wie hoch ist das Risiko von Problemen? Wie viele Abhängigkeiten gibt es?
  3. Umfang/Aufwand: Wie viel "Arbeit" muss erledigt werden? Wie viel Code muss geschrieben, getestet und dokumentiert werden?

Schätzungstechniken für Story Points

Es gibt verschiedene Methoden, mit denen Teams Story Points schätzen können:

Planning Poker

Die am weitesten verbreitete Technik für Story-Point-Schätzungen:

  • Jedes Teammitglied erhält einen Satz Karten mit Werten (meist Fibonacci-Folge: 1, 2, 3, 5, 8, 13, 21...)
  • Eine User Story wird vorgestellt und diskutiert
  • Jedes Teammitglied wählt verdeckt eine Karte, die seine Schätzung repräsentiert
  • Alle Karten werden gleichzeitig aufgedeckt
  • Bei großen Abweichungen werden die Gründe diskutiert und es wird erneut geschätzt
  • Ziel ist ein Konsens oder zumindest eine Annäherung der Schätzungen

Team Estimation Game

Eine alternative Methode, die den Fokus auf die relative Größe legt:

  • User Stories werden auf Karten geschrieben
  • Das Team sortiert die Karten der Größe nach von klein nach groß
  • Nachdem alle Karten sortiert sind, werden konkrete Story-Point-Werte zugewiesen
  • Diese Methode betont die Relativität zwischen Stories

Dot Voting

Eine schnellere Methode für erfahrene Teams:

  • Stories werden auf einem Board platziert
  • Teammitglieder erhalten eine bestimmte Anzahl von "Dots" (Punkten)
  • Sie verteilen ihre Dots auf die Stories basierend auf dem wahrgenommenen Aufwand
  • Die Anzahl der Dots wird in Story Points übersetzt

Fibonacci-Skala und andere Skalierungen

Für Story Points werden häufig spezielle Skalen verwendet:

  • Fibonacci-Folge (1, 2, 3, 5, 8, 13, 21...): Die am häufigsten verwendete Skala. Die zunehmenden Abstände zwischen den Werten spiegeln wider, dass Schätzungen mit zunehmender Größe ungenauer werden.
  • Modifizierte Fibonacci-Folge (1, 2, 3, 5, 8, 13, 20, 40, 100): Vereinfacht größere Werte für bessere Handhabbarkeit.
  • T-Shirt-Größen (XS, S, M, L, XL, XXL): Betont den relativen Charakter und wird oft als Zwischenschritt vor der Umwandlung in numerische Werte verwendet.
  • Potenzen von 2 (1, 2, 4, 8, 16, 32...): Eine Alternative, die ebenfalls zunehmende Unsicherheit bei größeren Stories abbildet.

Velocity: Die Verbindung zwischen Story Points und Zeit

Obwohl Story Points selbst keine Zeiteinheiten sind, ermöglicht das Konzept der Velocity die Übersetzung in zeitliche Prognosen:

  • Definition: Die Velocity ist die Summe der Story Points aller User Stories, die ein Team in einem Sprint fertigstellen kann.
  • Berechnung: Nach mehreren Sprints wird der Durchschnitt der erledigten Story Points pro Sprint ermittelt.
  • Anwendung: Mit der bekannten Velocity kann ein Team vorhersagen, wie viele Story Points es in zukünftigen Sprints schaffen kann.
  • Release-Planung: Die Velocity ermöglicht Prognosen darüber, wie lange die Umsetzung eines Produktbacklogs dauern wird.

Vorteile von Story Points

  • Reduzierung psychologischer Verzerrungen: Vermeidet die Tendenz, Zeitschätzungen auf "schöne" Werte wie Stunden oder Tage zu runden.
  • Teamkonsens: Fördert Diskussionen und ein gemeinsames Verständnis der Aufgaben.
  • Berücksichtigung mehrerer Faktoren: Integriert Komplexität und Risiko, nicht nur Arbeitszeit.
  • Relativität: Erleichtert das Schätzen durch Vergleiche mit bereits bekannten Stories.
  • Teamunabhängigkeit: Die Velocity passt sich automatisch an die Leistungsfähigkeit des jeweiligen Teams an.
  • Genauere langfristige Prognosen: Durchschnittliche Velocity ist oft zuverlässiger als Zeitschätzungen.

Herausforderungen und Fallstricke

Bei der Arbeit mit Story Points können folgende Probleme auftreten:

  • Story Point Inflation: Die Tendenz, dass Story Points im Laufe der Zeit "aufgebläht" werden.
  • Überfokussierung auf Zahlen: Story Points werden zum Selbstzweck, statt als Mittel zur Planung.
  • Missverständnisse bei Stakeholdern: Nicht-technische Stakeholder verstehen das Konzept möglicherweise nicht.
  • Vergleiche zwischen Teams: Der Versuch, Story Points teamübergreifend zu vergleichen, führt zu falschen Schlüssen.
  • Mangelnde Kalibrierung: Ohne regelmäßige "Kalibrierung" können die Schätzungen inkonsistent werden.

Best Practices für Story Points

Für einen effektiven Einsatz von Story Points empfiehlt sich:

  • Regelmäßige Kalibrierung anhand von Referenz-Stories
  • Konsistente Anwendung der gewählten Skala
  • Berücksichtigung aller Aspekte der Definition of Done bei der Schätzung
  • Verwendung relativer statt absoluter Vergleiche
  • Einbeziehung des gesamten Teams in den Schätzprozess
  • Akzeptanz von Ungenauigkeit, insbesondere bei großen Stories
  • Splitting von Stories, die mehr als 13 Story Points erhalten würden
  • Fokus auf den Dialog und Wissensaustausch während der Schätzung

Story Points in der Praxis: Ein Beispiel

Ein Scrum-Team hat folgende Referenz-Stories definiert:

  • 1 Point: Einfache UI-Textänderung ohne Logikänderung
  • 3 Points: Hinzufügen eines neuen Formularfelds mit einfacher Validierung
  • 5 Points: Implementierung einer neuen API-Schnittstelle zu einem bestehenden System
  • 8 Points: Entwicklung eines neuen Features mit mittlerer Komplexität
  • 13 Points: Integration eines komplexen neuen Subsystems mit mehreren Abhängigkeiten

Das Team schätzt nun neue Stories relativ zu diesen Referenz-Stories. Nach mehreren Sprints stellt das Team fest, dass seine durchschnittliche Velocity bei 30 Story Points pro zweiwöchigem Sprint liegt. Dies ermöglicht dem Product Owner zu prognostizieren, dass ein Backlog mit 150 Story Points etwa 10 Wochen (5 Sprints) zur Umsetzung benötigen wird.