Certified Scrum Master (CSM)

Am 12. - 13.04.2010 nahm ich an einem Training zum Certified Scrum Master (CSM) teil. Referent war Boris Gloger. Das Training dauerte 2 Tage - inklusive eines abendlichen Scrum-Cookings. Das Zertifikat erhält man im Anschluss, indem den Online-Test "Certified ScrumMaster Candidate Evaluation" auf www.scrumalliance.org durchführt.

Sprint Review & Retrospektive mit Scrum for Team System

In diesem Teil beschreibe ich, wie wir Scrum for Team System bei Sprint Reviews und bei Sprint Retrospektiven nutzen. Und weshalb wir Impediments nicht mit Scrum for Team System verwalten…

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

Teil 3: Sprint Reviews & Retrospektive

3.1 Sprint Review
Zu dem Sprint Review treffen sich die Team-Mitglieder, die Product Owner oder Fachexperten. Es wird an einem Beamer das Product Increment vorgestellt.
War die Implementierung erfolgreich, werden die entsprechendes Product Backlog Items auf "done" gesetzt. Entspricht ein Product Backlog Item aber nicht den Vorstellungen, muss nachgebessert werden. Solch ein Product Backlog Item verweilt mit dem Status "in Progress" im Product Backlog und steht mit der höchsten Priorität für den Folgesprint an oberster Stelle. Wir nutzen üblicherweise das Task Board, um den Status von PBIs zu setzen.

3.2 Retrospektive
Zur Retrospektive treffen wir uns nach einem Sprint für eine Stunde, um die Aktivitäten des Sprints zu reflektierene:

• Was war gut?
• Was war nicht so gut?
• Was wollen wir besser machen? 

Jeder im Team liefert "Input".Die Ergebnisse halten in einem Work Item Type "Retrospective" fest:


Da war doch noch was? Richtig die Impediments…

3.3 Impediments (Hindernisse) besser auf einem Whiteboard!
Impediments hindern das Team daran das Produkt-Inkrement fertig zu stellen. Hindernisse müssen schnell aus dem Weg geräumt werden. Dies zu tun ist Aufgabe des SCRUM Masters. Ein Hindernis kann beispielsweise "Mehr RAM für den Build-Server" sein, oder "es fehlt noch die Prozessabsprache mit Fachabteilung XY". Unsere Hindernisse sind vielschichtig und meist nur kurzlebig. Darum verwalten wir sie nicht über das WorkItemType "Impediments" in TFS, sondern auf einem Whiteboard - für jeden im Team sichtbar!

Daily Scrums mit Scrum for TeamSystem

In diesem Teil beschreibe ich, wie wir Scrum for Team System in unseren Daily Scrum Meetings einsetzen.

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

Teil 2: Daily Scrum Meetings

Unsere Daily Scrums finden immer vor dem gemeinsamen Mittagessen statt und dauern ca. 15 Minuten. Reihum beantwortet jeder die Punkte:

• Was hast Du seit dem letzten Daily Scrum gemacht?
• Was wirst Du bis zum nächsten Daily Scrum machen?
• Wo hast Du Hindernisse?

Wir nutzen das digitale Task Board, um die angesprochenen Punkte festzuhalten. Bei der Frage "Was hast Du seit dem letzten Daily Scrum gemacht?" verweisen wir an einem großen Monitor auf die entsprechenden gelben Zettel. Wir stellen kurz den Verlauf, Fortschritt, Kontext, etc. der eigenen Punkte dar und schätzen - falls möglich - die noch verbleibende Zeit. Auch hier ist es so, dass wir die noch offenen Stunden nur über den Daumen schätzen. Es kommt nur auf den geimeinsammen Fortschritt an.

Das verschieben der gelben Zettel (die Sprint Backlog Items) erfolgt komfortabel über drag&drop:

Aus dem "Schieben" der Sprint Backlog Items (SPI) während der Daily Scrums ergeben sich automatisch tolle und aussagekräftige Burndown Charts mit Trend-Forecast:

Die digitale Version des Task Boards bringt zwar einerseits viel positives, andererseits fehlt hier das haptisches Erleben von genau "meiner gelben Karteikarte", die ich am Whiteboard auf "done" setze. Ich habe schon gehört, das Teams zwei Task Boards nutzen. Ein klassisches Whiteboard mit konventionellen Karteikarten und daneben eine digitale Version. Beide werden nach jedem Daily Scrum synchronisiert. Auch eine gute Idee!

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…

Team Velocity

Team Velocity = Story Points pro Sprint.
Wir hatten einige Sprints hinter uns, nun war der Velocity-Report interessant. Hier sieht man wie viele Story Points das Team in den Sprints geschafft hat. Nun ergab sich zwar ein wirklichkeitsnaher Mittelwert von 34 Story Points. Aber es fanden sich auch Werte von 5 bis 82. Woher kommen diese Schwankungen im Velocity Report?
1. PBIs laufen über mehrere Sprints.
Ja wir haben sie! Diese Product Backlog Items (PBIs), die von einem Sprint zum nächsten "schlüpfen" und nie so richtig fertig werden. Das klassische "Everything in Progress" Problem. Es fehlt halt nur noch ein Review mit der Fachabteilung oder ein Test einer Daten-Schnittstelle. Aber die Ressourcen außerhalb des Teams sind nicht verfügbar, krank, im Urlaub oder mit anderen "Prio 1 Themen" beschäftigt. Wir können dann das Product Backlog Items (PBIs) nicht vollständig abschließen. Es wandert in den nächsten Sprint. Wird das PBI schließlich auf "Done" gesetzt, wertet TFS die Story Point vollständig zum aktuellen Sprint, obwohl der Großteil der Arbeit in einem vorigen Sprint verrichtet wurde.
Fazit: Blockieren Ressourcen außerhalb des Team den Fortschritt muss man leider damit leben
2. Reporting Problem: Story Points tauchen im Folgesprint auf.
Ein ähnliches Problem liegt hier vor. Auch hier entscheidet der Tag an dem das PBI auf "Done" gesetzt wurde, für welchen Sprint dessen Story Points zählen. Oft wurden die Story Points erst im Folgesprint angezeigt (rote Pfeile). Wir hatten das PBI aber rechtzeitig fertiggestellt! Was war passiert?


Den letzen Daily Scrum eines Sprints hielten wir immer am Vormittag des Planungstages für den Folgesprint ab. Hier haben wir oft noch offenen Punkte auf "done" gesetzt (meist irgendwelche Branching- ,Build- oder Infrastruktur-Aufgaben). Und das war das Problem. Die PBIs zählten dann schon zum nächsten Sprint, dessen Zeitintervall schon begonnen hatte. Wir haben das Problem dadurch gelöst, dass die Planung eines Folgesprints noch im Zeitintervall des aktuellen Sprints stattfindet. Dann kann man auch noch am letzen Tag Punkte auf "done" setzen, ohne dass das Reporting beleidigt ist…
Fazit: Story Points werden zu genau dem Sprint-Zeitintervall gezählt in dem der Status des PBI auf "Done" gesetzt wurde.

Vom Traum durch präzise Arbeitsplanung keine Ressourcen zu vergeuden

Wir nutzen TFS und die Projektvorlage ScrumForTeamSystem. Unser Taskboard für die Daily Scrums ist also digital. Wir treffen uns täglich rund um einen 24" Monitor und schieben unsere digitalen Aufgabenzettel übers Taskboard. Die Burndown Charts des Sprints wird daraus automatich ermittelt.
Neulich hatte ich mit einem Kollegen, der Scrum nicht kennt, eine interessante Diskussion. Der Anstoß der Diskussion war ein Blick auf unser aktuelles und vergangene Burndown Charts.
Die Fragestellung: "Warum weicht den Euer Fortschritt in den Burndown Charts so stark vom Plan ab?" und "Warum plant ihr die Sprints nicht so, dass die Ist-Kurve auf der Plan-Kurve liegt?"

Oben sind drei Beispiele von Burndown Charts aufgezeigt. Stellt die rote Kurve eine falsche Planung dar? "Vertrödelt" das Team gar die Zeit und bringt nichts fertig?
Was würde es denn bedeuten ein Team exakt auf die grüne Kurve hin zu trimmen? Wir Entwickler würden in in unseren Aufwandsabschätzungen dazu einfach genügend Puffer einbauen. Wir wollen dann ja auch ganz sicher gehen, dass wir im Zeitraster der Plankurve bleiben. Nun kann sein, dass sie diesen Puffer benötigen. Wahrscheinlicher ist es aber, dass sie ihn nicht benötigen. Dies bedeutet, dass in einer grünen Kurve eine Menge Zeitreserven stecken. In einer Roten aber keine.
Fazit: Allzu glatte Burndown Charts können nur mit genügend Zeitreserven erreicht werden.

Scrum - Unser Kick-Off

Seit dieser Woche arbeiten wir nun mit Scrum. Wir entschließen uns die Tasks (also eigentlich die Sprint Backlog Items) in unserem TFSs aufzubauen. Dort verwenden wir noch das MSFA Projekt Template. Den eigentlichen Scrum Workflow werden wir aber an einem Whiteboard für jedermann ersichtlich durchzuspielen. Wir wollen erst mal den Prozess etablieren, ehe wir das komplette Visual Studio Projekt in ein neues Scrum-TFS-Projekt umziehen.
Was gab es für Erkenntnisse beim ersten Planungsmeeting?

• Die Forderung "alle kritischen Punkte zuerst angehen" behindert eine gleichmäßige Auslastung im Team
  Scrum fordert, dass die kritischen Aspekte bei Iterationen/Sprints immer zuerst angegangen werden. Wir erstellten also eine Liste mit allen Punkten die ein hohes Risiko haben oder kritisch sind. Diese wollten wir zuerst angehen. Beim durchsehen der Punkte fiel uns gleich auf, das nur ganz bestimmte Personen diese Aufgaben durchführen konnten. Eine gleichmäßige Auslastung im Team war nun nicht mehr gegeben. Wir haben Experten ("Kopfmonopole") und das Know-How ist sehr ungleichmäßig verteilt. Wir schafften es trotzdem die Aufgaben einigermaßen gleichmäßig zu verteilen.
  
• Entwickler tun sich schwer den Aufwand ihrer Arbeitspakete abzuschätzen.
  Diese ernüchternde Feststellung hat mich nicht verwundert. Die Abschätzung der Dauer einzelner Arbeitspakete benötigt man für die die Planung eines Sprints. Oft wird empfohlen mit Story Points die Aufwände und die Kapazität des Teams zu ermitteln. Wir versuchen es erst mal mit Stunden. Das ist uns vertrauter. Mal sehen, ob Story Points später nicht doch besser geeignet sind.
  
• Die Erste Sprint-Planung dauert (und dauert und dauert…)
  Wir haben sehr lange für die erste Sprint-Planung gebraucht. Mehr als drei Tage haben wir damit verbracht bis die Planung stand. Die Planung sollte an einem Tag durchführbar sein. Man hört und liest aber, dass es beim ersten Mal immer sehr lange dauert…

Was waren die Ergebnisse?

• Unser Sprint Ziel:

"Complete SQL Interfaces & Finish GUI Basis-Funktion für…"

• Die Aufgaben (Sprint Backlog Items bzw. Tasks)

Gelbe Zettel auf dem White-Board sind die Tasks im Sprint. Wir bauen die Tasks parallel in TFS auf.

Fazit
Fürs erste sieht's schon mal nicht schlecht aus!

• Die Planung steht.
• Alle haben mitgearbeitet.
• Jeder kennt das Ziel für die nächsten 3 Wochen