Ein Weg zu Scrum: Karteikarten statt Software

Ausgangssituation:
Tasks mit Karteikarten übersichtlich und effizient zu planen ist für lokal arbeitende Teams zwar möglich, wird aber dennoch nicht überall mit offenen Armen angenommen. Das Team oder das Management ist es nicht gewohnt oder hat kein Vertrauen in diese lapidaren Karten.

Prinzip:
Mit der Einfachheit der Karten kann man den grundlegenden Ablauf der Zusammenarbeit und auch den Fortschritt wesentliche besser sehen, als mit einer Softwarelösung (ein häufiger Vertreter sei hier Bugzilla genannt).

Lösungsweg:
Die ersten 2-3 Iterationen mit Karteikarten beginnen und entsprechend des Feedbacks aus den Retrospektiven kann man mit einer Software den Prozess ergänzen. Zum Beispiel mit einem Ablagesystem für Detailinformationen wie einem Wiki.

Falls es wirklich nötig ist kann man die Karteikarten dann auch mit einer Software ersetzen. Das Team kann die Erkenntnisse und Erfahrungen über dem Planungsprozess mit den Karten dann besser auf das Softwaresystem übertragen.

Verwandte Artikel:

Warum dauert die Sprintplanung so lange?

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:

Agile Estimation – Ein Migrationspfad von Manntagen zu Storypoint

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: