Sprint Planung mit Scrum for Team System

Nach nun 20 Sprints hat sich für unser Team ein optimaler Ablauf der Organisation von Sprints eingestellt. Als Werkzeuge nutzen wir Excel, TFS, Scrum for Team System (Conchango) und das Task Board for Team System. Ich möchte Euch drei Blog-Teilen vorstellen, wie wir die Tools für SCRUM nutzen und wie sich der Ablauf der Sprints damit gestaltet.

Teil 1: Sprint Planung
Teil 2: Daily Scrums
Teil 3: Sprint Review & Retrospektive

Teil 1: Sprint Planung

Wir bauen seit unserem 4. Sprint alle Artefakte der Sprints in TFS auf. Die Benutzung von TFS war zu Begin zeitaufwendiger als der Einsatz von Karteikarten auf altbewährten Whiteboards. Man hat aber schnell eine gewisse Routine und wird umgehend belohnt durch automatisch erzeugte Burndown-Charts, User Stories, Backlogs, Testpläne oder Versionsplänen. All diese Informationen bereitet TFS zeitnah und komfortabel auf. Und dafür lohnt sich Mühe und Zeitaufwand wirklich!
Die Sprint Planung steht am Anfang jedes Sprints. Folgender Ablauf (und Zeitaufwand) hat sich etabliert:

1. Kapazitätsplanung des Teams für den Sprint-Zeitraum
   ( 15 Minuten)
   
2. Aufbau eines TFS Work Items vom Typ "Sprint"
   ( 1 Minute)
   
3. Festlegen aller Sprint Backlog Items (SPI) für die anstehenden Product Backlog Items (PBI)
   ( 1 Nachmittag)
   
4. Commitments des Teams zum Sprint-Ziel
   (10 Minuten)
   
5. Übertragen der Ergebnisse ins TFS
   (30 Minuten)
   

a) Kapazitätsplanung des Teams für den Sprint-Zeitraum
Bevor man die Sprintplanung beginnt, muss die Kapazität des Teams im Sprint-Zeitraum erfragt werden. Ich habe hierfür eine Excel Vorlage erstellt. In dieses trägt jedes Teammitglied ein, wie viele Tage es pro Woche im anstehenden Sprint-Zeitraum zur Verfügung steht.

	Fritz	Günther	Anna	Gerd
1.Woche	3	5	5	5
2.Woche	5	0	5	5
3.Woche	5	0	5	4
Summe (Tage)	13	5	15	14
Summe (Std)	104	80	120	112
Korrekturfaktor	0.9	0.9	0.8	0.7
Stunden (ca.)	93	72	96	78	330

Für Teammitglieder, die ungeliebte Nebenjobs haben, welche nur schwer Teil der Planung sein können, haben wir empirisch einen Korrekturfaktor eingebracht. Dadurch verbessen wir unsere Zeitschätzung. Anna ist unsere Build-Masterin (auch für andere Teams) und kann nur zu 80% entwickeln, Gerd unterstützt den Support und hat daher einen Faktor von 0.7 (70%). Hier geht es nicht darum die genaue Stundenzahl mit "Kommastelle" auszurechnen. Wichtig ist lediglich die Größenordnung.

b) Aufbau eines TFS Work Items vom Typ "Sprint"
Nun wird ein neues TFS Work Item vom Typ "Sprint" angelegt.
Dies erfolgt über den Menüeintrag Add Work Item.



Die aus der Kapazitätsplanung ermittelten Stunden werden im Feld Capacity (hours) eingetragen.
Im Feld Sprint Name wird die Iteration ausgewählt (Iterationen werden in den TFS Project Settings angelegt).
Das Feld Sprint Goal bleit noch leer und wird erst nach Ende des Planungsmeetings mit der Zusammenfassung des Commitments zum Sprint-Ziel gefüllt.

c) Festlegen aller Sprint Backlog Items (SPI) für die anstehenden Product Backlog Items (PBI)
Jetzt endlich kommen wir zum Kernstück: zur eigentlichen Sprint-Planung!
Hierfür trifft sich das Team in einem Raum. Die anstehenden PBI sind bekannt nun gilt es für jedes der PBIs die SPIs zu ermitteln. Dazu steuert jedes Teammitglied seinen Input für die anstehenden Aufgaben bei. Wir halten dies einer Excel Tabelle fest, die wir mit einem Beamer an die Wand projizieren. Das ist oft sehr dynamisch. Es kommen Punkte hinzu, es werden welche gestrichen, es wird geschätzt, verteilt, zusammengefasst… Diese Dynamik ist der Grund weshalb wir alle Punkte zunächst in Excel festhalten und nicht gleich in TFS anlegen. WorkItems können nicht gelöscht, zusammengeführt oder auf gesplittet werden.

Wie sieht das Excel Template aus?

Unter die Liste der anstehenden PBIs schreiben wir alle notwendigen SPIs und schätzen deren Aufwand.

Legende
Product Backlog Item (nach Prio sortiert)	Summe Stunden
Sprint Backlog Items (in dieser Planungsrunde festgelegt)	Stunden geschätzt

Über die Summenfunktion von Excel werden die Stunden für die PBIs ermittelt. Mit der Kapazität im Hinterkopf ist schnell klar welche PBIs im Sprint umsetzbar sind und welche nicht mehr.
Das untere Beispiel zeigt eine Planungstabelle in Excel. Die User Story D kann beispielsweiser nicht mehr durchgeführt werden, da die Kapazität bereits mit User Story C ausgeschöpft ist.

1 User Story A	120
Neues Datenfeld "expired" in DB	4
Property und Validierung in MT	8
Unit Test	4
GUI erweiterung	4
usw…
2 User Story B	88
SPI 1	8
SPI 2	2
usw…
3 User Story C	120
SPI 1	6
SPI 2	6
usw…
4 User Story D	48
SPI 1	6
SPI 2	6
usw…

Hier ein Screenshot der Sprint-Planung mit Excel:


d) Commitment des Teams zum Sprint-Ziel
Zum dem Abschluss der Sprint-Planungsrunde muss das Team ein Commitment zum Sprint-Ziel abgeben.
Das Sprint-Ziel ist eine knappe Zusammenfassung dessen, was in dem geplanten Sprint geleistet wird.

e) Übertragen der Ergebnisse ins TFS
Für die Team-Mitglieder ist die Planung nun abgeschlossen. Daraufhin bereite ich in TFS alles für den kommenden Sprint vor. Dazu müssen alle Product Backlog Items (PBI) aktualisiert und die neuen Sprint Backlog Items (SPI) angelegt werden.
Zunächst weise ich allen angegangenen PBI den kommenden Sprint zu.

Über die Work Item Liste sortiere ich Product Backlog Items nach Business Priority.
Hier kann ich der Reihe nach schnell allen betroffenen PBIs im Feld Release and/or Sprint den Sprint zuweisen.

Sind alle PBIs aktualisiert mache ich mich an die dazugehörenden SPI. Dies kann man ebenfalls über den Team Explorer erledigen. Ich nutze dafür aber das Task Board for Team System. Diese Tool macht diese Arbeit wesentlich effizienter und nach 2-3 Sprints hat man die Lizenzkosten von ca. 50€ locker amortisiert.

Man startet das Task Board, wählt den gewünschten Sprint aus und es erscheint eine ansprechende WPF Oberfläche, die an ein Task Board auf einem Whiteboard erinnert.



Alle SPIs zu einem PBI kann man nun rasch anlegen,
indem man über das Kontextmenü den Menüeintrag Add Sprint Backlog Item aufruft.

Unter Title und Description trägt man ich die wichtigsten Punkte zum SPI ein.
Das Feld Description bleibt tatsächlich oft leer.
Wichtig ist es die Stunden zum SPI unter Estimanted Effort und unter Work Remainig einzutragen.
Das Feld Assigned To bleibt zu Beginn leer. Erst während der Daily Scrums teilen sich Team Mitglieder Aufgaben selbst zu.

Sind alle PBIs aktualisiert und alle SPIs aufgebaut kann der Sprint beginnen…