Egal ob in einem klassischen oder einem agilen Projekt, an irgendeinem Punkt müssen Aufwände für die bevorstehenden Anforderungen oder Aufgaben ermittelt werden. Was im Wasserfall ganz zu Anfang schon für Kopfschmerzen sorgt, wird im Scrum jeden Sprint durchgeführt – dafür aber in kleinerem Umfang. Gerade durch den Einzug der agilen Prozesse haben sich für das heikle Thema der Aufwandsbestimmung einige Methoden etabliert. Nicht zuletzt bedeutet ein ungenau ermittelter Aufwand auch immer gleichzeitig für zumindest eine der Vertragsseiten einen Verlust: Wird der Aufwand – also effektiv auch die Kosten – zu niedrig angesetzt, kann der Lieferant eventuell seinen Deckungsbeitrag nicht erreichen. Und wird der Aufwand zu hoch angesetzt, schreckt der Auftraggeber vor der Beauftragung eines Features oder des gesamten Produktes zurück. In beiden Fällen aber verliert das Projekt als solches. Erfahren Sie in diesem Beitrag was die Wall Estimation ist, wie sie die Technik mit dem TFS einsetzen können und warum Ihnen WordToTFS hierbei besonders behilflich sein wird!
Eine Prämisse die wir bereits in vielen Projekten bestätigen konnten ist, dass Menschen dann am besten schätzen wenn sie als Team zusammen arbeiten. Es können Hintergrundwissen und Bauchgefühl aller Parteien zusammenfließen. Das Resultat ist nicht ein exaktes Ergebnis, aber sicherlich eines, das öfter weniger falsch ist. Einer der bekanntesten Vertreter der Team-Abschätzung ist zum Beispiel das Planning Poker. Eine weitere sehr effektive aber leider weniger bekannte Technik ist die Wall Estimation.
Die Vorbereitung
Zur Vorbereitung auf die Wall Estimation benötigt das Team zwei Dinge: Ein Whiteboard oder Planning Board sowie die anstehenden Aufgaben oder Anforderungen, die abgeschätzt werden sollen, auf Moderations-Karten. Im Falle des TFS bedeutet das, dass wir zumindest die ID und den Titel auf den Karten benötigen. Wie in der Abbildung zu sehen wird auf das Board eine Tabelle gezeichnet. Wir verwenden eine leicht modifizierte Fibonacci-Reihe als Spaltenüberschrift. Genauso würde auch eine Reihe von T-Shirt Größen: XS,S,M,L,XL funktionieren. Die Einteilung der Spalten in relativ zueinander stehenden Größen hilft uns später bei der Schätzung. Denn statt sich bereits zu einem sehr frühen Zeitpunkt auf einen exakten Aufwand festzulegen, verwenden wir eine relative Schätzung: “Anforderung X ist komplexer als Anforderung Y” ist sehr einfach zu erkennen, wohingegen “Anforderung X dauert 40h und Anforderung Y dauert 60h” oft eher dem Lesen in der Glaskugel gleicht.
Damit unser Team also erst einmal anfangen kann mit einem relativen System zu arbeiten, benötigen wir eine Referenz-Story: Eine Aufgabe die jedes Teammitglied vollständig versteht und im Idealfall bereits einmal durchgeführt hat, wird als eine mittlere Größe, also Size: M oder 8 verwendet. Die Story kann ein Datenadapter ebenso wie ein UI Dialog oder eine Konverter sein. Wenn ein Team neu ist, und noch nicht im Projekt zusammen gearbeitet hat, kann der Prozess einige Zeit dauern. Es ist durchaus üblich, mehr als nur eine Referenz-Story zu definieren. Gerade wenn zum ersten mal in einem Cross-Funktionalen Team gearbeitet wird, ist das Wissen zwischen Datenbank-, Applikations- und UI-Entwicklern über die Komplexität einer Entwicklung oft sehr gering. Sollten also alle Möglichkeiten einer Themenbezogenen Story scheitern ist es nur legitim als Referenz die Komplexität eines “Reifen-Wechsel an einem PKW” oder auch das “Zubereiten eines Boeuf Bourguignon” zu verwenden.
Das Spiel
Das Team steht im Halbkreis vor dem Board, die Karten werden gemischt und auf einen Stapel gelegt. Das Spiel geht reih um. Der Spielleiter startet einen Timer von einer Minute und der erste Spieler beginnt:
- Er nimmt die oberste Karte vom Stapel.
- Liest die Karte den anderen vor.
- Befestigt die Karte in einer der Spalten am Board.
- Erklärt dem Team den Grund für seine Entscheidung.
- Startet die Stoppuhr für den nächsten Spieler.
Für den Fall das sich der Spieler sich nicht innerhalb der einen Minute für eine der Spalten entscheiden kann, wird die Karte in einer zuvor festgelegten mittleren Spalte angeheftet.
Nach ein paar Runden sollten somit bereits einige Karten am Board hängen. Jetzt kann jeder Teilnehmer für sich selber entscheiden, ob er eine neue Karte vom Stapel anheften möchte, oder ob er eine der bereits am Board angehefteten Karten umhängen möchte. In letzterem Fall gelten die gleichen Regeln:
- Karte vorlesen,
- Karte anheften,
- Begründung der neuen Abschätzung für das Team.
Nach einigen Runden sind nun alle Karten auf dem Board. In diesem Fall können die Spieler neu abschätzen, oder aber auch einfach passen. Haben alle Teilnehmer eine Runde gepasst ist das Spiel zu Ende. Alle Aufgaben wurden abgeschätzt und das Ergebnis von allen Teilnehmern akzeptiert.
Nachbereitung
Sofern wir manuell, also ohne den TFS arbeiten, schreiben wir die geschätzten Aufwände auf die Karten, je nach dem in welcher Spalte sie am Ende hängen. Arbeiten wir mit dem TFS, tragen wir die Daten entsprechend in die dafür vorgesehenen Felder der Work Items ein.
WordToTFS
Gehen wir nun einmal davon aus das wir alle unsere Aufgaben, Anforderungen Bugs, Issues usw. mit dem TFS als zentrales Repository verwalten, haben wir das Problem, dass wir die Work Items zu Beginn auf die benötigten Karten „Exportieren“ und nach der Session wieder „Importieren“ müssen. Und genau hier hilft uns WordToTFS:
Work Item Export
Mit dem Template „Wall Estimation“ können Sie Ihre Work Items aus dem TFS einfach nach Word exportieren, ausdrucken, ausschneiden und an das Board mit Magneten oder Nadeln anheften. Diese Funktion eignet sich übrigens auch für alle Teams die gerne ein klassisches Scrum-Board im Büro haben möchten – Zeitgleich aber auch nicht auf die digitalen Vorteile des TFS verzichten wollen.
Und so legen Sie los:
- Laden Sie sich das für Sie passende “Wall Estimation”-Template herunter.
- Entpacken Sie das Paket auf ihrem lokalen Rechner oder auf eine Netzwerk-Freigabe.
- Binden Sie das Template in WordToTFS ein
- Starten Sie Word und wählen Sie das WordToTFS-Ribbon aus
- Wählen Sie den Template Manager an
- Tragen Sie über “Add Source” die Daten Ihres neuen Templates ein:
- Legen Sie eine neue Work Item Query an
- Die Work Item Query für das Backlog eines CMMI basierten Team Projektes könnte wie folgt aussehen:
Wir können jetzt die Work Items aus dem TFS mit WordToTFS exportieren
- Verbinden Sie sich mit Ihrem TFS Team Projekt
- Wählen Sie das passende Wall Estimation Template aus
- Öffnen Sie den Get Work Items Dialog
- Wählen Sie die zuvor angelegte “Wall Estimation”-Query aus
- Führen Sie die Abfrage mit “Find” aus und markieren Sie alle gewünschten Items mit einem Haken
- Starten Sie den Work Item Import mit “Import”
- Alle Ihre gewünschten Work Items sollten nun in Word als Tabellen abgebildet sein.
Jetzt nur noch drucken und die Wall Estimation wie beschrieben durchführen. Die grünen Linien stellen die Schnitt-Kanten dar.
Wie Sie sehen, verwenden wir ausschließlich den Titel des Work Items in diesem Template – ein Grund mehr, sich Gedanken über einen aussagekräftigen Work Item Titel zu machen.
Estimation Import
Die Wall Estimation Templates besitzen ein freies Feld auf der rechten Seite, in das die endgültige Abschätzung nach der Session – solange die Items noch an dem Board hängen – eingetragen wird. Ein Verwechseln oder falsches eintragen ist somit fast ausgeschlossen.
Eine Anpassung an Ihr eigenes Vorgehen dieser Vorlage könnte sein, dass der Wert auf der Karte nur noch angekreuzt werden muss. Nachfolgend haben wir nicht die Fibonacci-Reihe sondern T-Shirt-Sizes verwendet.
Der Import kann jetzt noch durch das Einblenden eines QR-Codes verbessert werden: Die Web URL des Work Items wird als QR-Code mit auf die Karte gedruckt, und mittels Bilderkennung über das Handy oder Tablet kann der Wert direkt eingetragen werden. Vielleicht kommt das Feature in einer der nächsten Versionen?
Fazit
Wie wir gesehen haben kann die Technik der Wall Estimation nicht nur in agilen Projekten für die Sprintplanung eingesetzt werden. Vielmehr ist es eine Methode aus unserem Werkzeugkasten des Projektmanagements die losgelöst von der Art oder des Prozesses des Projektes ist. Warum nicht mal mit der Wall Estimation die Bug-Liste verarbeiten? Oder die offenen Issues? Zusammen mit der automatischen Generierung der Work Item Karten durch WordToTFS (Link) und dem vorgemerkten Feld für die Schätzung ist es möglich, die Online- und Offline-Welt ideal miteinander zu kombinieren.