Story Points und Personentage

Klassische Bewertung von Arbeitspaketen

In der klassichen Projektplanung werden Arbeitspakete üblicherweise mit Aufwand und Dauer geschätzt (beides in Tagen), teilweise wird auch mit Spannbreiten gearbeitet. Zusätzlich zu der Angabe des Aufwands und der Dauer kann noch eine Risikobewertung hinzugefügt werden. Es wird üblicherweise nicht mit relativen Größen gearbeitet.

Story Points in Scrum

In Scrum nutzt man zur Einschätzung von Stories relative Größen, die sogenannte Story Points (SP). Die SPs sind keine absoluten Werte (wie Personentage) sondern ein recht unscharf definiertes Konstrukt, welches Komplexität und Aufwand beschreibt. Wichtig hierbei ist, dass eine Story mit 5 SP größer/komplexer ist als eine Story mit 2SP. Die Einträge im ProductBacklog werden durchgeschätzt, für eine Sprint-Planung werden die Schätzungen meist noch einmal evaluiert und geprüft, ob die Stories auch wirklich gut geschrieben und gut geschätzt sind. Letztendlich muss eine Entscheidung getroffen werden, wieviele Stories mit ihren Story Points in einen Sprint übernommen werden können. Zumindest wenn die Sprint Planung auf Basis von Story Point durchgeführt wird, was von den meisten Scrum-Evangelisten so vorgeschlagen wird.

Sprint Planning ohne Story Points

Mike Cohn verweist in einem älteren Beitrag darauf, dass er Abschätzungen mit Story Points nur für die Release Planung, nicht für die Sprint Planung einsetzt. Im Sprint Planning lässt er das Team die vom PO gewünschten Stories im Detail analysieren und in Stunden/Tage bewerten.

Sein Hauptargument:

Suppose a basketball team is in the middle of their season. They’ve scored an average of 98 points per game through the 41 games thus far. It would be appropriate for them to say “We will probably average 98 points per game the rest of the season.” But they should not say before any one game, “Our average is 98 therefore we will score 98 tonight.”

This is why I say velocity is a useful long-term predictor but is not a useful short-term predictor.

Planning 1 und Planning 2

Wir setzen ein zweistufiges Verfahren ein: Planning 1 und Planning 2. In Planning 2 diskutieren wir auf Basis Story Points und einer durchschnittlichen bisher erreichten Velocity und prüfen, ob das Ergebnis “passen kann”. In Planning 2 werden die ausgewählten Stories wie von Mike beschrieben vom Team im Detail nochmals analysiert und die einzelnen Tasks bewertet. Hierbei kann es vorkommen, dass eine Korrekturmaßnahme nötig ist oder weitere Detailinformationen benötigt werden. In Planning 2 ist der ProductOwner üblicherweise nicht anwesend, sondern wird nur bei Rückfragen hinzugezogen.

Umrechnung/Abbildung von Story Points auf Personentage

Sobald Story Points benutzt werden stellt sich immer die Frage der Umrechenbarkeit von Story Points zu Personentagen. Wie bereits erwähnt nutzen wir hierzu eine durchschnittliche Velocity (Velocity der letzten n Sprints).

Eine Herausforderung ist hierbei, dass gerade bei komplexen langlaufenden Projekten die Forderung “fixed sprint length” zwar meist eigehalten werden kann, allerdings im Ergebnis nicht immer gleich viele verplanbare Tage vorliegen. In den letzten 4 Sprints unseres Teams gab es beispielsweise nie eine gleich große Anzahl verplanbarer Tage (sizeable days) sondern stets große Schwankungen. Hier spielen Themen wie “Einfluss der Linie”, “Urlaub”, “Weiterbildung” etc. eine Rolle. In einem Sprint können 20 PT verplant werden, im nächsten 15 und im übernächsten 30. Es ist also sehr wichtig festzuhalten, wieviele Story Points in wievielen Tagen umgesetzt werden konnten.

Puffer und Story Points

Interessant ist auch die Frage, wie mit (“den elenden”) Support-Puffern umgegangen wird. Die reine Scrum-Lehre stößt sich an solchen gedeckelten Puffern, die böse harte Welt da draussen fordert diese jedoch aktuell (noch) ein. Ziel muss es IMHO immer sein, den Puffer so klein wie möglich zu behalten, d.h. so viele Tage wie möglich mit Stories zu belegen (“sizable days”) und so wenig wie möglich für Support-Tasks zu blocken.

Wenn mit Puffern gearbeitet wird, dann kommen Frage auf wie:

  • Sollen solche Puffer – die eigentlich in Tagen reserviert werden müsssen – auch in Story Points ins Planning einfliessen?
  • Falls Stories (geschätzt mit SPs) in einem Support-Puffer umgesetzt werden – zählen die Story Points zur Velocity falls man die dazu benötigten PTs in die verfügbaren (sizeable) Tage hinzufügt?
  • Wie kommuniziert man den Erfolg eines Teams nach aussen, wenn sich dieser zusammensetzt aus erledigten Stories und extrem produktiven Support-Puffern?

Es ist ersichtlich, dass dieses Thema ein sehr ergiebiges ist, in dem die unterschiedlichsten Meinungen vertreten sein können.