Aus der agilen Methodenkiste: Speed Estimation – 150 Stories in weniger als zwei Stunden abschätzen

SCRUM – Gewusel im Football (Foto: Quelle Pixabay)

Ich möchte in meine 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 Ferstigstellungszeitpunkt 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 Management System zu entwickeln. Welche Funktionen in diesem Client zur Verfügung stehen sollten, war offensichtlich: er sollte möglichst das können, war schon mit dem alten Client verfügbar war.

Allerdings war ein neues Team zusammengestellt worden, das auf Basis neuer Technologie entwickelt werden sollte. Und so war das Wissen um die Funktionen bei den meisten Teammitgliedern entweder kaum oder doch eingeschränkt vorhanden war. 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 Infrastuktur 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 vor hatte, nach und nach an das Team zu geben, an. Es waren über 150 Stories. Und da das Refinement einer einzigen Story zwischen 30 und 90 Minuten lag, um eine fundierte Schätzung abgeben zu können, musste ein geeignets Verfahren her, 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 ein Vorstellung davon, welche Komplexität zu den unterschiedlichen Storypoints passt.

An dem einen Kopf des Tisches hatte ich mich mit meinem Stapel mit den vorbereiteten Stories positioniert.

Vorbereitung der Stories

Ich hatte jede Story auf einem Zettel so groß wie 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 innerhalb von 3 Minuten entsprechend 8 Stories vom Stapel genommen und kurz vorgestellt. Eines der Team-Mitglieder hat dann den Zettel übernommen. Meist Jener, der die beste Vorstellung von der Komplexität hatte.

Nach der letzten Übergabe wurde eine Stopuhr mit wieder 3 gestartet. In dieser Zeit hat jeder seinen Zettel vor einen der 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 erfolgte.

Nach Ablauf der Zeit wurden die Story-Zettel dann hinter die Storypoint-Zettel zur Mitte des Tisches gelegt.

Abschlussarbeit

Es 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 doch 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:

  1. Schätze den Aufwand „1 Prozess ins DMS überführen“ im Projektteam. Führe dazu wird 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.
  2. 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).
  3. 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.
  4. 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.

Autor: Dr. Martin Bartonitz

Geboren 1958 und aufgewachsen in Dortmund, am Rande des Kohlenpotts, einem Schmelztiegel während der Gründerzeit eingewanderter Menschen. 1992 nach der Promotion in experimenteller Physik gewechselt von der Messprozess- in die Geschäftsprozesssteuerung. Mit Blick auf die Erfahrungen in der Optimierung der Effizienz von Prozessen in der Bürowelt kam in den letzten Jahren immer mehr die Erkenntnis: Das Business machen die Menschen. Und wenn nur nach der Effizienz geschaut wird, dann wird auch noch die letzte Motivation in den Unternehmen zerstört. Daher sollten Organisation und auch die eingesetzte Software die Menschen in ihrer Kreativitität unterstützen und sie nicht knechten. Selbstbestimmtheit statt Fremdbestimmung sollte uns den nächsten Schub in unserer gesellschaftlichen Entwicklung bringen. Aufgrund dieser Überzeugung schreibe ich hier mit.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s