Von unseren agilen Entwicklungsteams wird erwartet, spontan und in kürzester Zeit Aufwandsschätzungen zu geplanten Projekten herausgeben zu können. Egal ob als Forecast zur internen Planung oder als Kostenindikation für eine Offerte, die Aufwandsschätzung sollte in jedem Fall trotz aller Dringlichkeit möglichst valide zustandekommen. Würfeln scheidet also schon mal aus. Und Planning Poker führt zwar zu relativ genauen Schätzungen, nimmt aber für die Aufwandsschätzung von ganzen Projekten aufgrund des Umfangs auch relativ viel Zeit in Anspruch. Bei Projekten im Planungsstadium liegt zudem selten ein bereits schätzbereites Backlog mit ausreichend im Detail spezifizierten Backlog Items vor. Wir haben in solchen Fällen gute Erfahrung mit so genanntem relativen Schätzen gemacht…
Was ist relatives Schätzen?
Beim relativen Schätzen ist, wie beim Planning Poker, das ganze Team beteiligt. Der Unterschied ist aber, dass die Komplexität von Backlog Items ausschliesslich relativ zueinander geschätzt wird. D.h. man bestimmt gemeinsam im Team, ob ein Item X entweder weniger komplex, gleich komplex oder komplexer als Item Y ist. Eine Umrechnung (Triangulation) solcher relativen Komplexitätsgrössen in Story Points oder Personentagen findet dann über eine Werteskala statt.
Relatives Schätzen eignet sich sehr gut, um auch eine grosse Anzahl Items und/oder Items mit einem niedrigen Detailgrad (beispielsweise Epics) mit einem vertretbaren Zeitaufwand zu schätzen. In der Regel benötigen unsere Schätzungen damit nicht mehr als zwei Stunden Zeitaufwand zusammen mit allen Teammitgliedern.
Es gibt verschiedene Techniken zum relativen Schätzen und unzählige Varianten von diesen. Grundsätzlich unterscheiden sich die Techniken bzw. Varianten in folgenden Punkten.
- Wie stark strukturiert ist der Schätzablauf? (“Spielrunden” vs. unkoordiniertes Vorgehen)
- Welche Werteskala bzw. Umrechnung findet Anwendung? (linear vs. nicht linear)
- Finden Referenzwerte Verwendung? (selektive Detailschätzungen bzw. tatsächliche Aufwände aus vergleichbaren abgeschlossenen Projekten)
Wir wenden unter anderem die Schätztechnik “Team Estimation Game” (ursprünglich von Steve Bockman) an, die wir hier im Detail beschreiben. Ein Beispiel für eine andere populäre Technik mit ähnlichen Prinzipien ist “Magic Estimation” (eine detaillierte Beschreibung findet sich hier).
Allgemeine Regeln
Es gibt nicht viele Regeln, die beim relativen Schätzen allgemeingültig sind. Folgende Regeln haben wir uns auferlegt, um jeweils ein valides Schätzergebnis sicherzustellen.
- Es schätzt das Entwicklungsteam, das das Projekt später auch umsetzen wird.
- Jeder aus dem Team schätzt mit
- Der Product Owner (bei uns entweder ein Projektleiter oder der Kunde) nimmt ebenso teil, um die Backlog Items vorzustellen und Rückfragen zu beantworten.
- Der Product Owner schätzt aber nicht mit.
- Es gibt einen Organisator/Moderator (muss nicht der Product Owner sein).
- Es gibt keine Zwischengrössen (ein Item X kann nicht ein “bisschen komplexer” sein als Item Y).
Projektumfang und Detailgrad
In unserem Projektkontext halten wir für wichtig, dass die zu schätzenden Backlog Items den Projektumfang möglichst vollständig abdecken.
Unterschiedliche Detailgrade unter den zu schätzenden Items sind grundsätzlich OK, aber zu grosse Unterschiede erschweren die Vergleichbarkeit der Items nur unnötig. Somit werden die Items von unserem Product Owner allenfalls noch zuvor “normalisiert”, so dass sie sich in ihrem Detailgrad untereinander nicht zu stark unterscheiden.
Es ist aber OK – sogar vorteilhaft – wenn zu einem Item zusätzlich bereits schon im Detail spezifizierte Anforderungen (beispielsweise User Storys oder Arbeitspakete) bestehen. Ein solches Item kann uns nämlich ohne viel Mehraufwand sehr gut als Referenz für die Umrechnung der relativen Komplexitätsgrössen herhalten (später mehr dazu).
Hilfsmittel
Theoretisch ist relatives Schätzen ausschliesslich virtuell mit einem Tool wie beispielsweise JIRA möglich. Praktisch ist das jedenfalls nicht, da es möglich sein sollte, die Backlog Items von jedem Teammitglied jederzeit relativ zueinander zu platzieren. Aus diesem Grund eignen sich physische Backlog Items besser. Die beste Erfahrung haben wir damit gemacht, die zu schätzenden Items alle auf Papier auszudrucken (bei uns dient JIRA hierfür immerhin noch als Datenquelle) und an eine Wand zu befestigen.
Diese Ausdrucke verwenden wir jedoch nicht für die eigentliche (Um-)Platzierung, da es sich um teilweise mehrseitige DIN-A4-Seiten pro Item handelt. Zudem sind die Ausdrucke auch nicht selbstklebend und an der Wand stattdessen mit Klebeband bzw. Stecknadeln befestigt. Beide Umstände laden also nicht gerade zum Umplatzieren ein. Deswegen verwenden wir zusätzlich Post-its oder (noch besser) Stattys, die wir auf einer benachbarten Wand oder einem Whiteboard befestigen, und die jeweils ein Item referenzieren. Die Referenzierung geschieht bei uns der Einfachheit halber mittels Buchstaben.
T-Shirt-Grössen als Skala
Als Werteskala für die spätere Umrechnung der relativen Komplexitätsgrössen in Story Points oder Personentagen verwenden wir eine Skala mit T-Shirt-Grössen, also beispielsweise XS / S / M / L / XL oder XXS / XS / S / M / L / XL / XXL. Eine solche Skala hat den Vorteil, dass sie präzise genug ist, um eine grobe Orientierungshilfe zu sein, aber zu unpräzise um die Teammitglieder zu zeitraubenden Detaildiskussionen über Aufwände verleiten zu können.
Da es sich bei T-Shirt-Grössen (noch) nicht um Zahlenwerte handelt, bietet diese Art Skala darüber hinaus den Vorteil, dass man sich erst zum Zeitpunkt der Umrechnung entscheiden kann, diese linear oder nicht-linear vorzunehmen (später mehr dazu). Schliesslich sind T-Shirt-Grössen bekanntermassen nicht genormt und nur “so ungefähr” proportional zueinander.
Detailschätzung eines Backlog Item als Referenz
Als Vorbereitung zu einem Team Estimation Game hat der Organisator/Moderator die zu schätzenden Backlog Items und die Werteskala physisch bereitgestellt und gibt dem Team kurz Zeit, sich diese durchzulesen (Ausdrucke). Items, die dem Team noch gänzlich unbekannt sind, stellt er vorab zusammenfassend in eigenen Worten vor.
Wir haben sehr gute Erfahrung damit gemacht, zu diesem Zeitpunkt im Team ein Item zu bestimmen, welches vorab im Detail geschätzt wird, so dass es uns später beim Umrechnen der relativen Komplexitätsgrössen in Story Points oder Personentagen als Referenz dienen kann.
Für diese Detailschätzung wird das Item in mehrere Detailanforderungen zerlegt (Dekomposition), die mit einer akzeptablen Gewissheit schätzbar sind. Die Schätzung dieser Detailanforderungen kann beispielsweise “konventionell” mittels Planning Poker vorgenommen werden. Die Summe der Schätzungen dieser Detailanforderungen ergibt dann eine sehr valide Schätzung des Item, womit dieses auch eine entsprechend valide Basis für die spätere Umrechnung ist.
Team Estimation Game
Das eigentliche relative Schätzen per Team Estimation Game läuft anschliessend in mehreren Spielrunden ab, an denen die Teammitglieder in einer festen Spielreihenfolge teilnehmen. Pro Spielrunde kann der Teilnehmer, der jeweils an der Reihe ist, zwischen drei Möglichkeiten wählen:
- Ein ungeschätztes Backlog Item schätzen
- Ein bereits geschätztes Backlog Item “umschätzen”
- Eine Runde kommentarlos aussetzen
Bevor der Teilnehmer, der an der Reihe ist, eine Schätzung eines Item vornimmt, beantwortet der Product Owner allfällige Rückfragen des Teilnehmers zu diesem Item. Ein noch ungeschätztes Backlog Item wird dann geschätzt, indem der Teilnehmer das Item (Post-it/Stattys) kommentarlos an der entsprechenden Stelle an der Wand mit der Skala platziert.
Es geht zunächst nicht darum, wie viel komplexer bzw. weniger komplex ein Item ist. D.h. ob ein Item nun die Komplexität L oder XL hat, ist nicht so entscheidend, nur dass es in jedem Fall grösser als eines der Komplexität M ist.
Möchte ein Teilnehmer lieber ein bereits geschätztes Backlog Item “umschätzen”, so platziert er es einfach an die entsprechende Stelle um anstatt ein ungeschätztes Item neu zu platzieren. Jetzt kann man beispielsweise abwägen, ob das L/XL-Item eher ein L. oder eher ein XL.Item ist. Der Teilnehmer begründet seine Umschätzung und bei Bedarf kann im Team eine kurze Diskussion darüber stattfinden. Es liegt hier am Organisator/Moderator ausufernde Diskussionen abzuwenden.
Setzen der Reihe nach alle Teilnehmer nur noch aus, so ist das Team Estimation Game beendet. Es bietet sich an, dass der Organisator/Moderator oder der Product Owner Backlog Items mit extrem kleiner bzw. grosser Komplexität punktuell nochmal kurz anspricht und das Team um eine abschliessende Gesamtbetrachtung bittet: Erfahrungsgemäss stechen am Ende doch noch ein bis drei Items heraus, die relativ zu den Items der benachbarten Grössen doch nicht “passen”. Im Zweifelsfall legt man einfach mit einem erneuten (kurzen) Durchlauf des Team Estimation Game nach.
Umrechnung (Triangulation)
Der Organisator/Moderator kann nun das Ergebnis des Team Estimation Game ohne das Team nachbereiten (Tipp: Fotoprotokoll machen). Wie zuvor angesprochen, kann ausgehend von den T-Shirt-Grössen eine lineare oder eine nicht-lineare Umrechnung vorgenommen werden. Für eine nicht-lineare Umrechnung eignet sich die vom Planning Poker gewohnte, auf der Fibonacci-Folge basierende Skala sicherlich am besten, da ihre Anwendung meistens schon bekannt ist und die dahinterliegende Motivation grundsätzlich auch beim relativen Schätzen relevant ist.
Die Abwägung, ob eine lineare oder eine nicht-lineare Umrechnung vorgenommen werden soll, handhaben wir folgendermassen: Ist der Detailgrad der Backlog Items generell sehr niedrig (beispielsweise nur Epics) oder handelt es sich um ein Projekt mit bisher unbekannten Stakeholdern und Schnittstellen oder vagen Rahmenbedingungen, so spricht das für die eine nicht-lineare Umrechnung. Andernfalls ist eine lineare Umrechnung vorzuziehen.
An einem Beispiel skizzieren wir hier ein mögliches Vorgehen um eine lineare Umrechnung in Personentagen vorzunehmen. Hierbei gehen wir davon aus, dass das zuvor detailgeschätze Backlog Item ebenfalls in Personentagen geschätzt worden ist (im Beispiel 24 Personentage). Dieses dient uns als Einstiegspunkt bei der Umrechnung.
Voilà! Nun muss man nur noch zusammenzählen (1 Item à 8 Personentagen + 3 Items à 16 Personentagen + …) und erhält den Gesamtaufwand (im Beispiel 288 Personentage).
Fazit
Relatives Schätzen führt schnell zu brauchbaren Aufwandsschätzungen. Aus diesem Grund setzen wir es in unseren Projekten zunehmend für eine erstmalige Schätzung ein. Diese erstmalige Schätzung behandeln wir allerdings auch als das, was sie ist: eine Grobschätzung. So machen wir im Projektverlauf, unter anderem in unseren Sprint Plannings, nach wie vor detailliertere Schätzungen per Planning Poker oder anderen Schätztechniken.
Auch sollte der Vorteil der Zeitersparnis nicht falsch verstanden werden: Was die Beteiligung des Teams betrifft, ist relatives Schätzen auf jeden Fall deutlich zeitsparender (maximal zwei Stunden Zeitaufwand), das betrifft jedoch nicht den Product Owner. Der muss als Vorbereitung schliesslich erst mal ein grob schätzbares Backlog erstellen. Dieser Aufwand fällt aber früher oder später so oder so an.
Wichtig zu erwähnen ist auch, dass wir hier eine für uns passende Schätztechniken (Team Estimation Game) in einer bestimmten Variante (T-Shirt-Grössen-Skala, Detailschätzung als Referenz) und mit auf unsere Organisation zugeschnittenen Best Practices (JIRA-Ausdrucke, wahlweise lineare bzw. nicht-lineare Umrechnung) beschrieben haben. Für andere Kontexte, die nicht gleichermassen projekt- und teambasiert sind, eignen sich andere Vorgehen vielleicht besser. Und selbst in dem von uns beschriebenen Kontext mag es noch geeignetere Vorgehen geben, die wir nur noch nicht entdeckt haben. So sind wir stets bestrebt, immer wieder neue Vorgehen auszuprobieren und unsere etablierten Schätztechniken und Best Practices anzupassen.
