FAQ - Agilität und Scrum verstehen

Scrum ist ein agiler Managementrahmen, der zu mehr Transparenz und Flexibilität führt. Hier sind ein paar Begriffe beschrieben, welche die Werte und Prinzipien beschreiben.

Was sind eigentlich Story Points?

Während unseren Coachings werden wir häufig nach Literatur und Konzepten zu „Story Point Schätzungen“ gefragt. Bis auf Beschreibungen von Mike Cohn in seinem Buch “Agile Estimation & Planning” kennen wir keine einheitliche Definition. Ohne jeden Artikel gelesen zu kennen rsp. alle Quellen geprüft zu haben, gehen wir mit den Story Points wie folgt um.

Story-Points sind Einheiten, welche die Grösse einer User Story beschreiben

Wie ist diese Grösse definiert? Handelt es sich dabei um Aufwand in Stunden? Diese und weitere Fragen kann man nicht pauschal beantworten. Es müssen verschiedene Faktoren berücksichtigen werden, die von den Teams abhängen welche die “Grösse” definieren.

Ein Team hält die Grösse wie folgt fest:

  • Die Grösse der Story ergibt sich aus ihrer Komplexität und dem Aufwand. Die Komplexität hängt davon ab, in diesem Beispiel, wie oft welche Schichten des Architekturmodells durchstossen werden müssen.
  • Der Aufwand beschreibt die Zeit, welche man für die eigentliche Umsetzung vorsieht. Wichtig: der Aufwand hat dabei keinen Bezug auf die Durchlaufzeit in Tagen!

Ein anderes Team regelt dies so:

  • Wie komplex sind die Interaktionen zur Umsetzung? Um diese Story umzusetzen müssen wir mehrere Abstimmungs- und Anpassungsrunden zwischen Designer, Interaction Designer und Frontend-Entwickler durchführen.

Wie ein Team die Grösse definiert ist nicht relevant. Wichtig ist:

  • Es geht nie um die Zeitdauer, die benötigt wird, um die Story umzusetzen, sondern um eine Eigenschaft der “Struktur” der User Story.

Das ist ein wichtiger Unterschied. Das bedeutet, dass die wachsende Erfahrung eines Teams und schnellere Abarbeitung von Stories die Grösse einer Story nicht verändert, denn die Eigenschaften der Story haben sich nicht geändert. Ein erfahrenes Team schafft einfach mehr bzw. grössere Stories in der selben Zeit als ein unerfahrenes Team. Das hat keinen Einfluss auf die Grösse!

Welchen Einfluss hat dies nun auf die eigentliche Schätzung

Die Diskussionen über wer die Story umsetzt sind wichtig (erfahrener oder unerfahrener Entwickler). Es spielt jedoch keine Rolle für die Schätzung einer Story. Dies unterstützt cross-funktionale Teams in ihrer Arbeit und macht Schätzungen leichter und schneller. Es müssen nur die Eigenschaften identifiziert und ein Vergleich mit schon bearbeiteten oder ähnlichen Stories angestrebt werden. Dann hat man schon die Grösse.

Wie erstellt man mit Story Points einen Releaseplan?

In Scrum wird der Zeitfaktor durch die Teamgeschwindigkeit (Velocity) in der Planung abgebildet. Diese Velocity definiert den Durchschnitt über die Summe aller vom Team erledigten Story Points pro Sprint:

  • V = ø (SUM (Story Points der erfolgreich abgeschlossenen Stories im Sprint))

Wenn man nun für alle Product Backlog Items Story Point Werte schätzt, sie in der Reihenfolge durch eine Form von Priorisierung sortiert und zudem weiss, wie viele Story-Points das Team pro Sprint umsetzt (Velocity), kann man die Aussage wagen, in welchem Sprint man das Feature liefern wird.

Während der Umsetzung entstehen somit gemessene Zeitwerte, die man dann auf die Grösse appliziert. Zeiten schätzen wird daher mit Story Points niemand mehr. Das ist eine gute Konsequenz, wenn man sich überlegt, wie schwer es ist die Entwicklung von Softwarebausteinen durch Zerlegung zeitlich abzuschätzen.

Detail Diskussionen sind zu vermeiden

Ein wichtiger Aspekt ist, dass durch die Betrachtung der Eigenschaften einer Story vermieden wird, nicht zu tief in die für die Umsetzung notwendigen kleinteiligen Elemente einzutauchen. Die Merkmale einer Story können auch ohne eine detaillierte Tätigkeitsanalyse identifiziert werden. Das ist bei Aufwandsschätzungen in Tagen häufig anders. Hier werden alle notwendigen Tätigkeiten identifiziert und deren Aufwände aufsummiert.

Einfach in der Anwendung

Gemäss unseren Erfahrungen ist es in der Praxis viel einfacher ein Planning Poker durchzuführen, als es abstrakt zu. Nimmt man zu Beginn eine Referenzstory und einigt sich darauf, dass diese eine mittlere Grösse hat, gibt das Team der Story die Grösse “5”. Andere Stories werden dann mit dieser verglichen und als gleich gross, kleiner oder grösser eingestuft. Die "Agilisten" nehmen dann gerne die nach Mike Cohn angepasste Fibonacci-Reihe und verteilen die Elemente darauf 1, 2, 3, 5, 8, 13, 20, 40, 100.

Die Skala dient unter anderem dazu, auszudrücken, dass umso komplexer die Story ist (also umso grösser), die Genauigkeit der Schätzung in die Binsen geht. De facto sollte man mit sehr grossen Stories vorsichtig in der Releaseplanung sein, denn es herrscht hier eine hohe Unsicherheit in Bezug auf das korrekte Verständnis des Teams für diese Story – aber das ist ein anderes Thema.

 

Zuletzt aktualisiert am 12.10.2017 von Adi Hospenthal.

Zurück