Im letzten Blogbeitrag ging es um das Schätzen in der Wissensarbeit. Heute wollen wir das Thema noch ein kleines bisschen vertiefen, indem wir uns verschiedene Mittel und Dimensionen für Schätzungen anschauen. Grundsätzlich erinnern wir uns:

• Es wird nur Komplexität geschätzt.
• Es wird keine zeitliche Komponente geschätzt.
• Es wird keine Schätzung in Zeiten umgerechnet.
• Die einzig legitime Einschätzung zeitlicher Art ist ein zeitlicher Korridor, in dem eine Aufgabe mit einer Wahrscheinlichkeit <1 fertig werden kann, basierend auf historischen Daten mit ähnlicher Komplexität geschätzter Aufgaben.

Vor dem Hintergrund schauen wir auf ein paar einfach zu verstehende relative Maßeinheiten, die von Teams zum Einschätzen von Komplexität genutzt werden.

T-Shirt-Größen

T-Shirt-Größen bieten eine einfach zu verstehende Möglichkeit, Aufgaben jeglicher Größe in Relation zueinander zu setzen. Welche Spannweite gewählt wird, ist dabei erstmal egal – ob von XXS bis XXL oder von S bis XL oder von 5XS bis 5XL, das bleibt der schätzenden Gruppe überlassen. Was dabei nicht aus den Augen gelassen werden sollte: Eine höhere Anzahl an Größen bietet nur vermeintlich eine genauere Einschätzung.

Tatsächlich hat sich in meinen Projekten gezeigt, dass eine Einteilung in S, M, L und XL völlig ausreicht. Sobald jemand in Richtung XXL tendierte, war das für uns ein Indikator, dass die Aufgabe noch zu groß ist und weiter runtergebrochen werden kann.

Tierarten

Scheinbar eine unnötig spielerische Variante, steckt hier viel mehr drin, als auf den ersten Blick erkennbar ist. Grundlage ist die Einschätzung auf einer nicht-kardinalen Skala von Tieren. Zum Beispiel: Ameise, Huhn, Schwein, Löwin, Elefant. Die Reihenfolge ist intuitiv nach der Tiergröße erfassbar.

Der Vorteil: Durch die fehlende Kardinalität, also die nicht eindeutigen Abstände zwischen zwei Tieren, erübrigen sich sämtliche Diskussionen über Nuancen relativ schnell, in welche Gruppe eine Aufgabe gehört. Spätestens dann, wenn zwei oder drei bereits bekannte Storys vorliegen:

„Ist diese Aufgabe komplexer als die Aufgabe, die wir vorher als Huhn eingeschätzt haben, aber weniger komplex als die Aufgabe, die wir als Löwin eingeschätzt haben? Oder gleicht sie einer der beiden bereits bewerteten Aufgaben mehr?“ Niemand sollte anfangen, davon zu reden, dass es sich um ein Schwein ohne Ringelschwänzchen handelt. Und falls doch, ist es recht leicht, das sofort zu unterbinden.

Story Points

Last but not least: Die Story Points aus dem Titel dieses Beitrags. Aufgaben werden häufig als Storys bezeichnet. Darüber und darunter gibt es auch manchmal Abstufungen, aber das soll uns hier egal sein. Zur Abschätzung werden nicht selten die sogenannten Story Points verwendet. Diese orientieren sich meistens an der berühmten Fibonacci-Folge*, siehe auch im obigen Bild.

Die Anlehnung an die Fibonacci-Folge sorgt dafür, dass die Abstände zwischen den einzelnen Komplexitätsgrößen bei höheren Zahlen größer werden. Das entspricht der zunehmenden Unfähigkeit des Menschen bei der Abschätzung von Komplexität, je größer eine Aufgabe wird. Während wir uns im niedrigen Bereich durchaus begründet (kurz!) darum streiten können, ob eine Story eine 3 oder eine 5 ist, wäre ein Streit darum, ob sie eine 20 oder 21 ist, komplette Zeitverschwendung.

Anchoring

Wichtig bei allen Schätzungsmethoden ist, dass alle an einer Schätzung Teilnehmenden ihre Schätzung gleichzeitig abgeben, zum Beispiel mit vorbereiteten Karten („Planning Poker“ oder „Estimation Poker“). Im Scrum heißt das zum Beispiel, dass niemand in der Schätzrunde, insbesondere aber Product Owner und Scrum Master, einen Wert nennen darf, bevor nicht alle gleichzeitig ihre Schätzung offenlegen. Zur Erinnerung: Es schätzen ohnehin nur diejenigen, die eine Aufgabe umsetzen. Scrum Master und Product Owner also meistens schon per definitionem nicht.

Einen solchen Vorgang des vorherigen Aussprechens oder Signalisierens eines Wertes nennt man Anchoring. Dabei ist es egal, wer zuerst eine Größenordnung öffentlich ausspricht, wobei der Effekt umso schlechtere Auswirkungen auf das Team hat, wenn es eine erfahrene Person ist (oder gar eine Person in einer Rolle wie Product Owner). Egal, wie sehr jede einzelne Person anschließend versucht, eine unvoreingenommene Einschätzung zu treffen, sie wird sich immer an dieser vorher getroffenen Aussage orientieren.

Anchoring ist daher unter allen Umständen zu vermeiden und ein sogenanntes Anti-Pattern.

Jetzt kennt ihr ein paar Schätzungsmethoden. Gibt es andere Methoden, die ihr nutzt? Was sind eure Erfahrungen? Wie gut geht das Team mit dem Bedürfnis nach Schätzungen um? Halten sich alle daran, ein Anchoring zu vermeiden?

Meine Story Points sind euer (direktes und indirektes) Feedback. Wie immer gilt daher: Danke für’s Lesen, abonniert sehr gerne meinen Newsletter, und wenn euch der Artikel gefallen hat, tut mir einen Gefallen und verbreitet ihn weiter, das hilft mir sehr! Dankeschön!

* Achtung, Wikipedia-Link, Artikel kann entsprechend Spuren von cis-hetero-männlich geprägten Administrator-Strukturen enthalten

[waglerit-newsletter-block]