Gegebenheiten:
- Die Anforderungen im ProduktBacklog werden in idealen Personentagen abgeschätzt (GF-Beschluss).
- Die Anforderungen sind am Sprintende sehr oft nicht vollständig umgesetzt (Muss zusätzlich untersucht werden!).

Effekt:
Im ersten Sprintplanungs-Teil, in dem sich das Team die Anforderungen auswählt, zu denen es sich committed, wird der Restaufwand in idealen PT abgeschätzt. Über mehrere Iterationen hinweg werden also immer wieder die gleichen Anforderungen neu abgeschätzt. Das kostet Zeit und ist ermüdend. Dadurch wird der zweite Sprintplanungs-Teil, in dem die Anforderungen in Tasks herunter gebrochen und auf Stundenbasis geschätzt werden nur mühsam und wird nur unvollständig gelebt.
Vor allem die Entwickler, die es nicht gewohnt sind große Aufgaben in kleine aufzuteilen haben damit Schwierigkeiten.

Lösungsmöglichkeit:
Wenn die Anforderungen ohnehin schon in idealen Personentagen geschätzt werden, kann SP1 und SP2 zusammengefasst werden.
Dabei werden direkt die (restlichen) Aufgaben je Anforderung ermittelt, in Stunden abgeschätzt und notiert.
Lediglich neue Anforderungen könnnen vorab grob in PT geschätzt werden.
Das Sprint Burndown Chart kann somit ggf. auch ohne Aufteilung der Anforderungen in Aufgaben mit der Summe der Anforderungsaufwände auf der Y-Achse gestartet und bei vollständiger Erledigung abgetragen werden.

Verwandte Artikel:

In 3 Schritten vom Manntag zum Storypoint

Bei jedem, der es gewohnt ist in Manntagen zu schätzen und nun zum ersten mal in Story-Points abschätzen soll, krümmt sich die Hirnmasse zu einem gordischen Knoten zusammen. Hier ein einfacher Weg vom alten ins neue System.

Schritt 1:
Die Abschätzung geschieht wie gehabt in idealen Personentagen (PT). Einzige Neuerung: Es sind nur noch bestimmte Abstufungen erlaubt. Z.B. entsprechend der beliebten Fibonacci Folge: 0 – 0,5 – 1 – 2 – 3 – 5 – 8 – 13 – 20 – 40 – 100, unendlich.

Für den ersten Sprint sollte sich das Team nicht viel mehr als etwa die Hälfte der kompletten Teamkapazität vornehmen.

Schritt 2:
Am Ende eines Sprints wird die Velocity berechnet. Wieviele ideale Tage konnten wir im vergangenen Sprint umsetzen? Wenn da dann z.B. 89 Tage rauskommen, dann für den nächsten Sprint ebenfalls nur 89 PT vornehmen, auch wenn der Kalender 140 anzeigt.

Wer möchte, kann sich den Korrekturfaktor berechnen, als Quotient aus idealen und erreichten Tagen. Zum Beispiel: 126 abgeschätzte PT / 89 erreichte PT = 1,4. Eine mit 10 PT initial geschätze User Story bzw. Use Case dauert also eher 14 MT.

Schritt 3:
Nach einigen Iterationen hat man erlebt, dass die Einheit Personentage tatsächlich relativ ist und man genauso gut Storypoint dazu sagen kann. Vor allem bekommt man in dieser Zeit Referenz-Stories, die als Vergleich mit neuen Stories dienen.

Ergänzung: Auf Taskebene ist die o.g. Folge in Tagen zu grobgeanular. Für Tasks einfach die gleiche Folge mit idealen Stunden als Einheit anwenden.

Verwandte Artikel: