Die Karten auf den Tisch! | Aufwandsschätzung Teil 3

Aufwandsschätzung ist sinnvoll. So unser Fazit nach Teil 2 unserer Serie. Auch die Begriffe „Story Points“ und „Velocity“ konnten wir (hoffentlich) verständlich erklären. Aber jetzt ab in die Praxis: Wie läuft das konkret in den Teams und welche Schätzmethoden haben sich bewährt? Wir werden in diesem Artikel einen kurzen Überblick über die unterschiedlichen Herangehensweisen geben und dann im Detail vor allem auf agile Schätzspiele wie den „Planning Poker“ eingehen.

agil = undiszipliniert?

Dieses Prinzip wird häufig von den Teams, aber auch von Kunden falsch interpretiert: „Wir arbeiten eben agil“ ist keine Ausrede für Projekte, deren Zeitplan oder Budget aus dem Ruder läuft oder bei denen Augenwischerei betrieben wurde, um den Aufwand zu Projektbeginn möglichst kleinzureden! Ganz im Gegenteil ist es das Ziel agiler Methoden, zielführender und damit wirtschaftlicher zu arbeiten, indem individuell entschieden wird, wieviel Dokumentation und Planung zum jeweiligen Projektzeitpunkt wirklich nötig sind.

„So wenig wie möglich, so viel wie nötig“: Vor dem Hintergrund, dass die Schätzkosten im Schnitt satte drei Prozent der Projektkosten ausmachen, eine absolut sinnvolle Vorgehensweise!

Es gibt nicht „die“ Schätzmethode!

Um die verschiedenen Methoden besser in den Gesamtkontext einordnen zu können, holen wir kurz aus. Grob eingeteilt gibt es zwei Ansätze, um Schätzungen durchzuführen:

Eine algorithmische Schätzung berechnet den Aufwand mit Hilfe mathematischer Formeln aus historischem Datenmaterial, statistischen Analysen und der Bewertung bereits vorliegender Größen. Entscheidend für ein präzises Ergebnis ist die Kalibrierung, d.h. die Parameter der Formel müssen firmenspezifisch angepasst werden (z.B. die Erfahrung der Mitarbeiter). Zwei der bekanntesten algorithmischen Methoden sind COCOMO und das Function-Point-Verfahren  – vergleichsweise aufwändig, aber bei gutem Datenmaterial in der Regel sehr präzise.

Eine empirische Schätzung basiert auf Erfahrungswerten von Fachleuten und/oder früherer, vergleichbarer Projekte. Am gängigsten sind hier Expertenschätzungen, zu denen u.a. beispielsweise der auf der Delphi-Methode basierende „Planning Poker“ und die Schätzklausur zählen.

Auch wenn es gerade für kühle Rechner im Controlling verlockend erscheint, eine Formel mit Zahlen zu füttern und so den Aufwand berechnen zu können: Die Erfahrung zeigt, dass empirische Methoden hinsichtlich der Präzision locker mithalten können. Da in agilen Teams außerdem großer Wert darauf gelegt wird, dass die Schätzmethode von allen Beteiligten ohne großen Erklärungsaufwand angewendet werden kann, kommen die hochkomplexen algorithmischen Modelle im agilen Umfeld kaum zum Einsatz bzw. in adaptierter Form (z.B. „Agile COCOMO“).

Am weitesten verbreitet ist die Expertenschätzung – laut Umfragen in rund 80 Prozent der Unternehmen die Methode der Wahl. Die Qualität der Schätzung hängt nicht nur von der Erfahrung der Schätzenden ab, sondern auch von der Anzahl durchgeführter vergleichbarer Projekte. Grobe Abweichungen können beispielsweise entstehen, wenn Erfahrungen aus kleinen Projekten 1:1 auf große Projekte skaliert werden.

In Scrum-Projekten ist eine realistische Aufwandsschätzung unter anderem nötig, um zu entscheiden, wie viele User Stories in einen Sprint gepackt werden können. Wir stellen hier drei Schätzvarianten vor, die sich in agilen Teams bewährt haben – nicht zuletzt aufgrund ihres spielerischen Charakters: das beliebte „Planning Poker“ nach Mike Cohn, „Magic Estimation“ nach Lowel Lindstorms und das „Team Estimation Game“ nach Steve Bockman.

Planning Poker

Populär wurde Schätzpoker in den letzten 10 Jahren durch Mike Cohn’s Buch „Agile Estimating and Planning“. Vorteil: Es handelt sich um ein transparentes, konsensorientiertes Verfahren, d.h. das Team versucht gemeinsam zu einer möglichst realistischen Schätzung des Aufwands zu kommen – perfekt für agile Teams, um deren gewünschte Selbststeuerung zu unterstützen.

Moderiert wird der Schätzvorgang durch den Scrum Master, optimalerweise steht auch der Product Owner für Verständnisfragen zur Verfügung. Zu Beginn wird eine möglichst kleine und einfach zu schätzende User-Story als Referenz festgelegt. Jedes Teammitglied erhält nun einen Satz Schätzpoker-Karten. Die gängigen Kartensätze arbeiten mit der Fibonacci-Zahlenreihe 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, „?“ (kann nicht geschätzt werden) und „Pause“ (z.B. eine Kaffeetasse).

Nun stellt der Scrum Master die einzelnen zu schätzenden User Stories vor. Wichtig ist, bei der Beschreibung Wertungen wie „einfach“ oder „kompliziert“ zu vermeiden, um das Team nicht zu beeinflussen.

Anschließend kommen die Karten ins Spiel: Jedes Teammitglied legt für die betreffende Story verdeckt (!) eine Karte mit dem geschätzten Story-Points-Wert auf den Tisch. Die Zahlen auf den Karten sind eine Maßeinheit für die Komplexität in Bezug auf die anfangs festgelegte Referenzstory.

Weichen nach dem Umdrehen der Karten die einzelnen Bewertungen erheblich voneinander ab, begründen die Schätzer des größten und kleinsten Werts ihre Entscheidung. Die anderen Teilnehmer und der Product Owner können an der Diskussion teilnehmen. Dann wird die Schätzung wiederholt, bis es zu einem Konsens kommt. Wichtig ist es, dass es sich dabei nicht um einen „faulen Kompromiss“ handelt, sondern um einen Schätzwert, hinter dem jedes einzelne Teammitglied steht – sowohl die konservativen als auch die optimistischen Schätzer.

Teams mit ungeübten Schätzern verzichten häufig auch auf die Karten mit den Werten 20, 40 und 100 und brechen die User-Stories lieber auf mehrere kleinere, weniger komplexe Teileinheiten herunter. Sinnvoll ist es außerdem, eine Pokerrunde auf maximal 90 Minuten zu begrenzen – wenn die Konzentration nachlässt, ist es Zeit, die „Pause“-Karte auszuspielen.

Magic Estimation

Bei großen Projekten kann es zum Start sinnvoll sein, die einzelnen User Stories nicht nacheinander zu schätzen, sondern auf „magische“ Weise zu einem schnelleren Ergebnis zu kommen:  Wie beim Schätzpoker wird eine Referenzstory festgelegt und der Scrum Master stellt (bei Bedarf unterstützt vom Product Owner) die einzelnen User Stories vor. Anschließend verteilt er die Karten mit den User Stories unter den Teammitgliedern. Auf dem Boden wird (z.B. mit Schätzpoker-Karten) die Fibonacci-Reihe ausgelegt.

Nun läuft die Stoppuhr: Jeder hat nun 10 Minuten Zeit, seine Karten entlang der Skala gemäß seiner Komplexitätsschätzung zu platzieren UND auch Karten anderer Teammitglieder zu verschieben. So entsteht sehr zügig ein erstes Bild, wie die Teammitglieder die Aufwände der einzelnen User Stories im Vergleich zueinander sowie zur Referenzstory einschätzen. Gleichzeitig wird schnell klar, bei welchen Karten sich die Teammitglieder uneinig sind – diese werden zur Seite gelegt und später gemeinsam diskutiert. Bei „Magic Estimation“ geht es noch nicht so sehr um Präzision, sondern um Relation und eine erste grobe Einschätzung.

Team Estimation Game

Haben Sie ein Team, dessen Schätzungen regelmäßig in lange technische Diskussionen über das „Wie“ ausufern? Dann ist das Team Estimation Game vielleicht die richtige Schätzmethode für Sie: Auch hier moderiert der Scrum Master das Meeting und der Product Owner beantwortet Fragen. Alle User Stories liegen verdeckt auf einem Kartenstapel.

Das erste Teammitglied zieht eine User Story aus dem Stapel und platziert sie in der Mitte des Whiteboards.

Das zweite Teammitglied zieht eine weitere User Story und hat nun drei Möglichkeiten, diese in Relation zur ersten User Story zu setzen:

• neben der ersten Karte: ähnliche Komplexität
• unter der ersten Karte: größere Komplexität
• über der ersten Karte: niedrigere Komplexität

Die nächsten Teammitglieder haben nun jeweils zwei Möglichkeiten:

• Sie ziehen eine neue Karte und platzieren diese entsprechend.
• Sie verändern die Position einer bereits gepinnten User Story, weil sie mit der bisherigen Komplexitätseinschätzung nicht einverstanden sind.

So geht es reihum, bis alle User Stories ausgespielt und platziert sind. Üblicherweise bilden sich „Cluster“, die am Ende des Spiels noch mit konkreten Story Points versehen werden können (z.B. indem das Team den Clustern Zahlenkarten aus dem Planning-Poker-Set zuordnet).

Unbedingt sinnvoll ist es, die Umpositionierung von Karten zu vermerken, z.B. durch Klebepunkte, und Karten ab 3 Klebepunkten später gemeinsam zu diskutieren.

Übung macht den Meister

Egal ob Planning Poker, Team Estimation Game oder eine ganz andere Methode: Wichtig für möglichst gute Expertenschätzungen ist üben, üben, üben. Jeder Mitarbeiter hat eine individuelle Zeitspanne, die er realistisch abschätzen kann und die noch dazu je nach Schwierigkeitsgrad der Aufgabe variiert. Die Einteilung des Projekts in User Stories sollte deshalb auf das Schätzvermögen Ihres Teams zugeschnitten sein.

Tipp: Notieren Sie VOR jedem Projekt Ihre Schätzungen und gleichen Sie NACH der Umsetzung ganz ehrlich ab, wie viel Zeit tatsächlich benötigt wurde. So trainieren Sie Ihre Wahrnehmung – bis sich im Idealfall Soll und Ist irgendwann decken.