Home Blog Estimations #1: Was schätzen wir da eigentlich?

Estimations #1: Was schätzen wir da eigentlich?

Wohl keine der klassischen Scrum-Praktiken und Meetings ist so umstritten wie das Estimation. Pro und Contra, Nutzen und Kosten, berechtigte Erwartungen und vor allem auch viele Missverständnisse gehen damit einher. In einer zweiteiligen Serie geben wir einen Überblick.

Die Theorie

Ein bis zwei mal im Sprint stellt der Product Owner seinem Team neue oder neu zugeschnittene User Stories vor und bittet um eine Einschätzung des Komplexität.

Das Team, so die Idee, lernt dadurch die mittelfristig anstehenden Aufgaben kennen und kann frühzeitig Feedback geben über eventuelle Schwierigkeiten oder Möglichkeiten.

Der Product Owner erhält neben diesen Hinweisen eine Einschätzung der Komplexität. Diese hilft ihm, unter Abwägung des potentiellen Aufwands gegenüber dem Nutzen, über die Priorität der Story zu entscheiden und außerdem im Abgleich mit der bisherigen Velocity des Teams eine Release- oder Epic-Planung vorzunehmen.

Meist werden die Größen der Stories mittels Storypoints angegeben, wobei dies explizit abstrakte Größen sind und der Abstand zwischen den Zahlenwerte immer weiter auseinander liegen, je höher sie sind. Der Abstand repräsentiert hier unter anderem die enthaltene Unsicherheit. Denn: Je größer eine Sache ist, desto ungefährer und unsicherer ist die Schätzung.

Das Missverständnis

Es gibt eine Vielzahl von typischen, aber nicht idealen Handlungs- und Sichtweisen auf das Estimation, die letztlich alle auf dem gleichen Missverständnis beruhen. Dieses Missverständnis ist ebenso groß wie verführerisch: „Wir schätzen den Aufwand – oder?“

Nein. Geschätzt, so die allgemeine Empfehlung von Scrum Experten, wird die Komplexität einer Aufgabe, also die Menge an Denkarbeit, Unwägbarkeiten und Unsicherheit, die in einer Aufgabe stecken. Aber nicht (primär) die reine Menge der Arbeit oder der Zeit, die voraussichtlich in die Erledigung der Aufgabe eingeht.

Fast jedes Team diskutiert früher oder später darüber ob das gut und fair sei, wenn die stupide, aber umfangreiche Fleißaufgabe eine sehr kleine Schätzung erhalten soll, während der trickreiche Spezialauftrag, für den man höchste Konzentration aber im Idealfall nur 15 Minuten Zeit benötigt, eine furchtbar große Schätzung erhält. Doch diese Sichtweise hat diverse Vorteile und nur so sind Estimations wirklich sinnvoll.

Erstens müssen Schätzungen unabhängig sein, genauso wie die geschätzten User Stories selbst: Nur wenn Story und Größe nicht davon abhängen, von wem sie umgesetzt werden, in welcher Reihenfolge oder wie oft zuvor es ähnliche Aufgaben gab, ist der Product Owner frei, ausschließlich nach dem erwartbaren Nutzen zu priorisieren. Um diese Unabhängigkeit zu haben, muss sich der geschätzte Wert auf eine Eigenschaft der Story selbst beziehen, nämlich die Komplexität. Der Aufwand selbst variiert erheblich, je nachdem, welche Vorarbeiten schon gemacht sind oder wer mit welchen Mitteln und wie ordentlich die Aufgabe umsetzt. Eine Schätzung mit Voraussetzungen („Nur wenn Stefan und Andrea da sind und Story XY vorher erledigt ist!“) verkompliziert die Angelegenheit ungemein und hilft letztlich niemandem.

Zweitens birgt eine Aufwands-Schätzung die große Gefahr, dass Storypoints mehr oder weniger offen in Stunden und Minuten umgerechnet und Schätzungen „mit der Stoppuhr überprüft“ werden. Das führt dann schnell zu einem gefühlten Rechtfertigungsdruck und zur Angst des Teams, „falsch“ zu schätzen und sich später rechtfertigen zu müssen. Die Komplexität bleibt richtig und gerechtfertigt, egal, wie lange die Aufgabe letztlich tatsächlich braucht.

Drittens führt die Verbindung von Storypoints und Zeit dazu, dass die Teams in der  Sprintplanung nicht mehr anhand der Stories entscheiden, wie viele sie mit in den Sprint nehmen, sondern nur noch abzählen: Normale Velocity minus abwesende Teammitglieder minus Feiertage und Firmenevents ist gleich Sprint Commitment.  Das inhaltliche Verständnis und damit die Erfahrung der Teammitglieder geht dabei völlig verloren.

Dass der Scrum Guide inzwischen empfiehlt, das Commitment auf das Sprint-Ziel abzugeben, und nicht mehr auf die einzelnen Stories, wird damit erst recht zur schönen aber vergeblichen Theorie.

Und viertens hängt eine Aufwands- bzw. Zeitschätzung schlichtweg und maßgeblich davon ab, wie ich arbeite. Während sich der Aufwand auf die Umsetzung bezieht, die ich mehr oder weniger umständlich oder gewissenhaft vollziehen kann, beschreibt die Komplexität viel mehr: den Inhalt der Aufgabe und deren Abhängigkeiten innerhalb des Systems, also meist des gesamten Codes.

Bei der Komplexität frage ich also nicht: „Wie sorgfältig arbeitest du?“ sondern:  „Wie schwierig ist es, das Problem zu lösen?“ Das ist – siehe den Absatz erstens – nicht nur unabhängiger, sondern auch die einzig vernünftige Herangehensweise, wenn man verhindern will dass Geschwindigkeit zu Lasten von Qualität geht.

 

Das Schätzen und Messen in Zeiteinheiten ist vertrauter und damit einfacher, keine Frage. Doch es hat, wie man sieht, zahlreiche direkte und indirekte unliebsame Nebenwirkungen, die in vielen Teams dazu führen, dass die Estimations als lästige Zeitverschwendung angesehen werden.

Im zweiten Teil dieses Artikels setzen wir uns daher mit diesen Vorwürfen auseinander.


Newsletter_abo

Sie wollen regelmäßige Updates über neue Blog-Artikel?
Jetzt unseren Newsletter abonnieren!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

© by leanovate GmbH - Impressum