SCRUM – Gewusel im Football (Foto: Quelle Pixabay)
Ich möchte in meiner Rolle als Produktmanager und Scrum Product Owner eine Methode vorstellen, die wir mit Erfolg ausprobiert haben, um im Team die für das nächste Jahr umzusetzenden Stories des Backlogs abzuschätzen. Die Schätzung hilft, den ungefähren Fertigstellungszeitpunkt auf Basis der Team-Geschwindigkeit errechnen zu können. Diese Methode ist zwar im Kontext der Software-Entwicklung angewandt worden, sie sollte aber in allen anderen Kontexten genauso gut funktionieren.
Zum Hintergrund
Wir hatten vor zweieinhalb Jahren begonnen, einen neuen Browser-basierten Client für unser Enterprise Content Management System zu entwickeln. Welche Funktionen in diesem Client zur Verfügung stehen sollten, war offensichtlich: er sollte möglichst das können, was schon mit dem alten Client verfügbar war.
Allerdings war ein neues Team zusammengestellt worden, das den Client auf Basis neuer Technologie entwickeln sollte. Und so war das Wissen um die Funktionen bei den meisten Teammitgliedern entweder kaum oder doch eingeschränkt vorhanden. Denn auch die Zusammenstellung des Teams war neu: Es waren sowohl Entwickler für die Oberfläche als auch für die Service-Infrastruktur dabei. Und so war meist nur ein gewisser Ausschnitt der Funktionen bekannt.
Das Team arbeitete inzwischen 3 Monate zusammen, die Infrastruktur war geklärt, und der Rumpf des Clients war funktionstüchtig. Für die Firma neu war die agile Entwicklungsmethodik Scrum, die wir als erstes Team erproben durften. Inzwischen arbeiten alle 6 Teams nach dieser Methode.
Erste Erfahrung mit den Schätzungen von Storypoints waren vorhanden. Und nun konnte begonnen werden, den Umfang des gesamten Vorhabens zu verstehen. Sprich, es stand der Blick auf alle Stories, die ich inzwischen für das erste Entwicklungsjahr geplant hatte, nach und nach an das Team zu Abschätzung zu geben, an. Es waren über 150 Stories. Und da das übliche Verfahren eines Refinement einer einzigen Story zwischen 30 und 90 Minuten lag, um eine fundierte Schätzung abgeben zu können, musste ein geeignetes Verfahren her, in kürzester Zeit dennoch zu einer Schätzung zu kommen.
Das Speed Dating … sorry: SPEED ESTIMATION
Wir hatten von einer ähnlichen Methode gehört (leider kann ich mich nicht mehr erinnern, woher), dann einige Anpassungen vorgenommen, und dem Kind einen passenden Namen gegeben.
Räumlichkeit
Wir hatten uns in einem Raum mit einem großen Tisch getroffen. Die Stühle haben wir an den Rand gestellt, so dass alle bequem um den Tisch herumlaufen konnten.
Auf dem Tisch lagen gleichmäßig verteilt Zettel mit den für SCRUM typischen Storypoints 1, 2, 3, 5, 8, 13, 20, 40, 100, ?. Das Team hatte inzwischen eine Vorstellung davon, welche Komplexität zu den unterschiedlichen Storypoints passt.
An dem einen Kopf des Tisches hatte ich mich mit dem Stapel der vorbereiteten Stories positioniert.
Noch ein Hinweis zu den Storypoints. Die Stories werden nicht in Personentagen geschätzt, sondern in den oben aufgezählten Komplexitätsgraden. Das Team hatte schon einige Stories umgesetzt und hatte damit eigene Erfahrungen, wie es Komplexitäten beurteilt.
Vorbereitung der Stories
Ich hatte jede Story auf einem Zettel so groß wie ein 1/4 DINA4 Blatt ausdrucken lassen und auf einem Stapel unsortiert liegen. Auf jedem Blatt stand ein Satz: „In der Rolle des XYZ möchte ich die FUNKTION, so dass der ZWECK erreicht ist.“. Anschließend habe ich den Ablauf des Schätzens mit dem Team besprochen.
Ablauf der Schätzung
Time boxing ist hier die Basis!
Es waren 8 Teammitglieder anwesend. Ich hatte innerhalb von 3 Minuten insgesamt 8 Stories vom Stapel genommen und kurz vorgestellt. Eines der Team-Mitglieder hat dann den Zettel mit der gerade vorgestellten Story übernommen. Meist Jener, der die beste Vorstellung von der Komplexität hatte.
Nach dem der letzte der 8 Zettel übergeben war, wurde die Stoppuhr mit erneut mit 3 Minuten gestartet. In dieser Zeit hat jeder seinen Zettel vor einen der oben beschriebenen Storypoint-Zettel gelegt, der ihm passend erschien. Anschließend sind alle nochmals rumgegangen und haben ggf. bei einem scheinbar unpassend gelegten Zettel kurz mit dem Legenden diskutiert, so dass noch ein Verrücken möglich war.
Nach Ablauf der Zeit wurden die Story-Zettel dann hinter die Storypoint-Zettel zur Mitte des Tisches gelegt.
Abschlussarbeit
Es gab drei Stories, die zum Fragezeichen gelegt wurden. Diese Stories hatten wir beschlossen, in einer eigenen Sitzung noch zu schärfen, da ihre Komplexität auf Basis von zu wenig Wissen darum noch nicht eingeschätzt werden konnte.
Zusammenfassung und Erkenntnisse
So wurden pro 6 Minuten jeweils 8 Stories geschätzt, also waren die über 150 Stories in 120 Minuten durch.
Nun war das Team mit mir auf Augenhöhe, was das gesamte Vorhaben betraf. Und ich war mir sicherer als zuvor, was die Menge an anstehender Arbeit betraf.
Ich hatte mir erlaubt, die Stories auf Basis der bisherigen Sprint-Ergebnisse zuvor selbst zu schätzen. Inzwischen hatte ich als Nicht-Programmierer ein relativ gutes Gefühl, wie das Team agiert. Und so hatten sich zwar die Schätzungen der einzelnen Stories in der Regel nach oben oder unten verschoben, aber die Gesamtsumme hatte sich am Ende doch nur wenig nach oben verschoben.
Versuchen wir noch einen Transfer mit ein wenig Abwandlung auf eine konkrete Anforderung im öffentlichen Dienst:
Einführung eines Dokumentenmanagementsysteme – #eGovernance
Ein kleine Kommune stellt dem Umsetzungsteams die Frage: Wie lange wird es dauern, bis das DMS flächendeckend eingeführt ist? Und wie hoch wird unser Ressourcenverbrauch sein (= Projekt-Manntage)?
Dabei lässt sich folgendermaßen vorgehen:
- Schätze den Aufwand „1 Prozess ins DMS überführen“ im Projektteam. Führe dazu eine Checkliste aus 13 Schritten, die den Ablauf eines Bausteins „1 Prozess ins DMS überführen“ darstellt. Der Aufwand pro Schritt ist aber sehr variabel, je nachdem, wie komplex der Prozess ist. Also lasse für jeden Baustein drei Varianten „einfach“, „mittel“, „komplex“ schätzen und nehme den Mittelwert dieser Varianten (dabei wird die mittlere Variante doppelt gewichtet).
Aus der Summe ergibt sich eine grobe Aufwandschätzung. - Schätze die Zahl der Prozesse in der Verwaltung. Dazu gibt es Erfahrungswerte aus vergangenen Projekten. Die Anzahl der Prozesse einer Verwaltung hängt von der Ebene ab (kleine Gemeinde, Stadtkreis, Landkreis).
- Dann schätze die Rüstkosten pro Abteilung. Jede Abteilung, die in das Projekt aufgenommen wird, braucht ca. 1,5 Tage an Einstiegsschulung in Projektmanagement, Kennenlernen des Rahmen-Aktenplans, wie man ihn an die eigenen Bedürfnisse anpasst usw.
- Dann kommt noch der Aufwand für Rüst- und Beratungskosten der Gesamtverwaltung hinzu (Bericht vor dem Bürgermeister, vor dem Gemeinderat oder Ausschuss, Projektcontrolling). Das setze mit 10% an (knapper Erfahrungswert bei gut laufenden Projekten, wo die Führungskräfte nicht mit Mikromanagement stören).
Mit diesem Verfahren steht am Ende eine Summe an Manntagen, gegliedert nach Umsetzungsteam und Tagen, die von Mitarbeitern der Fachabteilungen geleistet werden.
Agile Verwaltung 