Agile Techniken – Story Points

Was ist das?

Story Points sind numerische Werte, meist angelehnt an Fibonacci-Zahlen: 0, 1, 2, 3, 5, 8, 13, 20, 40, 80. Das Scrum-Team verwendet sie zur Bewertung der Komplexität von Anforderungen in Stories.

Sie dienen als „psychologischer Trick“ und Diskussionsanker, um Komplexität zu bewerten und zu erforschen.

Wozu kann ich das verwenden?

Die Erstellung von Aufwandsschätzung ist fehlerbehaftet:

• Menschen sind schlechte Schätzer – und zwar fast alle! Insbesondere haben wir keinen Instinkt für Wahrscheinlichkeiten. Zur Illustration kann ich nur empfehlen: Rolf Dobelli, Die Kunst des klaren Denkens. 
• Menschen halten sich jedoch für gute Schätzer, die wenigsten kennen jedoch ihr „Handicap“.
• Implizite Annahmen und widrige Umstände führen zu massiven Schätzabweichungen. Umso mehr, wenn z.B. in der Softwareentwicklung gerade mal wieder Hektik vorherrscht und man keine Zeit für endlose Analysen hat.
• In Stresszeiten gerät man häufig auch unter Druck: „Das können wir nicht verkaufen“ – „Das muss doch einfacher gehen, die sollen mal richtig programmieren und nicht rumprobieren“. 

Der Trick der Story Points ist nun die Loslösung der Komplexität vom Aufwand: Wenn ich einmalig 1000 Sätze in einer Excel-Tabelle bearbeiten muss mit einfachen Editier-Vorgaben, dann ist dies womöglich aufwändig – aber nicht komplex! 

Muss ich jedoch die gleiche Excel-Tabelle aus meiner Anwendung erzeugen, dann kann das komplex sein: woher bekomme ich die Daten? Welche Umwandlungen muss ich vornehmen? Sind diese Transformationen algorithmisch lösbar oder nur durch Menschen? Welche Zeichensätze verwende ich?

Agile Teams verwenden Story Points, um Komplexität zu bewerten und in eine Diskussion zur Erforschung der Anforderungen einsteigen zu können: Abweichungen in den Einschätzungen im Planning Poker zeigen Bedarf zur Klärung von Annahmen auf – wenn die Fragen geklärt sind, dann kann das Team die Anforderung realistisch einschätzen.

Worauf muss ich achten?

Meist nutzt das Team implizit oder explizit einen Wert für „unendlich“ oder „viel zu hoch“, z. B. die 100. Die Fibonacci-Reihe ermöglicht eine Vorstellung über die Größenordnungen – jedoch müssen die Teammitglieder in den ersten Zyklen gemeinsam eine Skala nach und nach festlegen.

Gerne verwenden Anfänger Stunden statt Story Points – weil das Management ja Aufwandschätzungen, Budgets und Pläne verlangt und man das jahrelang so gemacht hat. Häufig haben diese Teams noch nicht am eigenen Leib erfahren, wie gefährlich Schätzungen und darauf basierende Aussagen sind: wenn ein Auslieferungstermin nicht gehalten oder ein Budget überschritten wird, ist oft noch das Management in der Pflicht – nicht das Team. 

Abschätzungen in Story Points helfen dem Team, sehr schnell und effizient Fallstricke zu identifizieren und Komplexität in den Griff zu bekommen.

So kann das Team vom Product Owner verlangen, eine komplexe Story aufzuteilen in beherrschbare Teile, um das Risiko zu verringern.

Beispiele 

Story: „Als Anwender kann ich mich jederzeit ausloggen, damit ich den Zugriff auf  meine Daten verhindern kann.“

Das Team bewertet die Komplexität einstimmig mit 2, weil neben dem Logout im Test geprüft werden muss, ob der Anwender noch Zugriff nach Logout hat.

Story: „Als Anwender kann ich die angezeigten Daten der Maske als XML abrufen, damit ich sie in anderen Anwendungen weiter verwenden kann.“

Das Team bewertet mit: einmal 1, viermal 3, einmal 8. Das Teammitglied mit der niedrigsten Schätzung (1) befragt das Teammitglied mit der höchsten Schätzung (8), worin die Komplexität besteht. Es stellt sich heraus, dass ggf. ein XML-Schema zu verwenden ist oder eine DTD, während die einfachste Variante in einer Standard-Konvertierung der verwendeten Library besteht. Der Product Owner entscheidet sich für die einfache Variante, erneutes Pokern führt zu einer einstimmigen 3.

Story: „Als Anwender kann ich jede Maske auf DIN-A4 ausdrucken, damit ich die Inhalte mitnehmen kann.“

Das Team bewertet fast einstimmig mit 80, weil unklar ist, wie viele Masken es gibt und ob sie überhaupt auf das Format angepasst werden können. Daraufhin gibt sie dem Product Owner die Story zur Reduktion zurück. Der Product Owner ändert die Story in „Als Anwender kann ich die Maske Nr. 1 ohne Grafiken in einer Druckansicht im Browser anzeigen, damit ich sie über die Browser-Funktionalitäten ausdrucken kann.“