Agiles Schätzen in Scrum

Scrum verlangt, dass wir unsere Backlog Items hinsichtlich Wert und Aufwand schätzen. Es sind dabei keine Schätztechniken festgelegt. Dennoch ist agiles Schätzen (Agile Estimation) in der Community ein kontroverses Thema. Häufig kommt die Frage auf: Brauchen wir das überhaupt? Neben der eigentlichen Sinnfrage gibt es häufig auch Unklarheiten in Bezug auf das Verständnis: In welcher Einheit schätzen wir? Wie gehen wir vor? Brauchen wir einen Umrechnungskurs?  

In Podcast-Folge #19  „Agiles Schätzen“ gehe ich auf diese Fragen ein und verdeutliche, warum das relative Schätzen dem zeitlichen Schätzen überlegen ist. Darüber hinaus zeige ich unterschiedliche Agile Estimation-Techniken und deren Einsatzgebiete. 

Warum uns relatives Schätzen so leicht fällt

Wir sind es gewohnt in Stunden, Tagen oder auch Monaten zu schätzen. Warum dies so ist, lässt sich simpel beantworten: Weil wir es immer so machen. Es stellt sich allerdings die Frage, ob Schätzungen basierend auf Zeit wirklich die sinnvollste Möglichkeit darstellen, einen Aufwand einzuschätzen. Zwar tun wir es schon seit geraumer Zeit, jedoch nicht lange genug, als dass uns zeitliche Einschätzung leicht genug fallen, um sie als zuverlässigen Indikator zu nutzen. In vielen Büchern wird aufgearbeitet, dass sich Menschen im Umgang mit Zeitschätzungen schwer tun und dass das eine völlig normale, evolutionsbedingte Einschränkung ist (Zu diesem Thema ein kleiner Buchtipp von mir: “Schnelles Denken, langsames Denken” von Daniel Kahneman). Anders verhält es sich mit dem Einschätzen von Entfernungen. Wir haben schon früh gelernt, zu erkennen, wann Gefahr droht und sich schnell nähert. Ob nun ein Bär auf uns zurennt oder ein Auto in rasantem Tempo naht: Wir können sehr gut entscheiden, ab wann es an der Zeit ist, vor der herannahenden Gefahr wegzurennen. Wir erfassen blitzschnell, wie lange es gedauert hat, bis der Bär von A nach B gerannt ist und schließen daraus, wann er bei C (also bei uns) eintreffen würde. Warum? Weil es überlebensnotwendig ist. Ausgehend von der Annahme, dass zeitliche Schätzungen nicht gerade die Stärke der menschlichen Spezies darstellen und daher relative Schätzungen diesen überlegen sind, greift man in Scrum bewusst auf eine Möglichkeit des Schätzens zurück, die mehr der menschlichen Natur entspricht. 

Das agile Schätzen basiert auf der Annahme, dass es  Menschen leichter fällt, Einschätzung für die Zukunft basierend auf Erfahrungswerten zu geben. Es fällt uns relativ leicht, Projekt B mit Projekt A zu vergleichen und zu schätzen, ob Projekt B genauso lange, halb so lange oder dreimal so lange dauert wie Projekt A. In der Praxis hat sich diese Annahme bewahrheitet. Es zeigt sich, dass das relative Schätzen dem zeitlichen Schätzen überlegen ist. 

Kleiner Unterschied mit großer Bedeutung:  Exaktheit vs. Präzision

Beim relativen Schätzen ist es wichtig, sich den Unterschied zwischen Exaktheit und Präzision vor Augen zu halten. Wenn wir eine Tasse als Referenz haben und wissen wollen, wie groß eine Flasche ist, so kann relativ einfach behauptet werden, dass die Tasse 3-4 mal größer ist. Nutzen wir die Tasse als Referenz um die Größe eines Hauses zu bestimmen, werden wir damit niemals auf eine ähnlich präzise Antwort kommen. Aus diesem Grund setzen wir in der Agile Estimation Zahlenreihen ein, welche in immer größeren Schritten steigen, um die Schätzungenauigkeit bewusst mit aufzugreifen. Am beliebtesten ist die Fibunacci Folge, die genau diese Eigenschaften erfüllt. Aber auch 2er Potenzen oder ähnliche Zahlenfolgen sind denkbar. Die Nutzung von Zahlenfolgen erfüllen ihren Zweck (nämlich das relative Schätzen von Aufwand) und sorgen gleichzeitig dafür, dass wir bei großen Schätzungen eine Pseudo-Genauigkeit vermeiden: Die Diskussion, ob das Haus etwas 512 oder 513 Mal größer ist als die Tasse, ist nicht zielführend und damit auch nicht notwendig.

Schätzen in Scrum: Ein weiteres agiles Werkzeug

Agiles Schätzen stellt ein weiteres Werkzeug in unserem Scrum Werkzeugkasten dar. Wie all unsere agilen Werkzeuge erfüllt es vornehmlich einen Zweck: Es stellt die Zusammenfassung eines Gesprächs dar oder ist der Trigger für ein Gespräch.  Vor diesem Hintergrund empfehle ich, sehr früh mit dem agilen Schätzen zu beginnen. Es geht primär nicht darum, 100 Prozent korrekte Schätzungen zu erzielen sondern es führt vielmehr dazu, dass früh Gespräche geführt und wertvolle Erkenntnisse gewonnen werden. Darüber hinaus lassen sich damit die unterschiedlichen Verhaltenstypen eines Teams durch Berücksichtigung ihrer jeweiligen Sichtweise abholen. Extrem gesprochen gibt es diejenigen, die eher schnell eine sehr optimistische Einschätzung abgeben. Dies führt meist dazu, sich zu verschätzen. Im Kontrast dazu gibt es diejenigen, die zuerst einen Katalog an Unmengen von Fragen abarbeiten möchten, bevor sie sich festlegen. Dies führt meist dazu, dass eine Einschätzung erst gar nicht abgegeben wird. Es ist daher hilfreich, beide Verhaltensmuster in einem Gespräch zu vereinen sodass am Ende klar wird, dass es zwar wichtig ist, den Referenzwert zu kennen und die wichtigsten Fragen vorab zu klären, dies aber nicht in epischem Ausmaß erfolgen muss. Dieses Gespräch hilft auch dabei herauszufinden, was genau die wichtigsten Fragen sind. Sollte sich das Team uneins sein, bewirkt dies eine Diskussion, die die Qualität der Schätzung mit Sicherheit positiv beeinflussen wird.

Sukzessive Vorgehensweise zum Start

Aller Anfang ist schwer – auch beim agilen Schätzen. Es können Techniken angewandt werden, die den Stein ins Rollen bringen und das Team sukzessive mit dem agilen Schätzen vertraut machen. Eine meiner Meinung nach sehr natürliche Möglichkeit, den Einstieg ins agile Schätzen zu finden, möchte ich euch hier verdeutlichen:  

Ich starte bewusst nur mit zwei Backlog Items und frage das Team, welches der beiden größer ist. Das Team wird sich für eine Karte entscheiden. An dieser Stelle frage ich offen ins Team, ob das jemand anders sieht und bitte diejenige Person, die Karte umzulegen und eine Begründung dafür zu geben. Jeder, der der Meinung ist, die Relationen seien falsch dargestellt, ist eingeladen, diese mit einer Begründung zu ändern. Wichtig ist, dass nur derjenige spricht, der die Karte bewegen möchte, da sonst unter Umständen der Fokus verloren geht.

Diese Vorgehensweise dient auch dazu, einen gewisse Unabhängigkeit zu wahren. Ein Gruppengespräch birgt die Gefahr, dass das Team sich aufgrund äußerer Einflüsse einfach nur gegenseitig bestätigt und nicht mehr hinterfragt wird. Auf diese Weise werden nach und nach Items hinzugefügt und hinterfragt, in welcher Relation sie zueinander stehen.

Wenn das Team sich auf eine sinnvolle Reihenfolge geeinigt hat, lege ich einen Baseline fest. Dort platziere ich eine 4 (entnommen aus meinen Karten an 2er Potenzen, die ich für solche Zwecke gerne nutze) im unteren Drittel der Items und bitte das Team, den Rest der Zahlen-Karten zu verteilen. Dies fällt den Teams in den allermeisten Fällen relativ leicht, da sie sich ja bereits ausgiebig mit den Items auseinandergesetzt haben.

Die daraus entstehenden Schätzungen können dann als Referenz für zukünftige Schätzungen genutzt werden. Der große Vorteil dieser sukzessiven Vorgehensweise ist, dass das Team sich schrittweise mit dem agilen Schätzen auseinandersetzen und sich daran gewöhnen kann. 

Planning Poker: Eine unabhängige Technik des agilen Schätzens

Die beliebteste Art des agilen Schätzens ist Planning Poker. Es handelt sich hierbei ebenfalls um eine relative Schätztechnik, die im Vergleich zur oben beschriebenen Vorgehensweise um einiges unabhängiger ist. 

Wie der Name schon verrät, kommen beim Planning Poker Karten zum Einsatz, anhand derer der Aufwand von Items geschätzt wird. Auf Basis von Referenzen wird das Team gebeten, sich gleichzeitig (beispielsweise “auf Drei”) zu einem Item zu äußern, indem jedes Mitglied eine Karte mit seiner Einschätzung zum Aufwand offen ablegt oder hoch hält. Das Teammitglied mit der höchsten sowie das mit der niedrigsten Schätzung wird dann gebeten, die Argumente mit dem Rest des Teams zu teilen. Aus diesen ergänzenden Eindrücken wird dann erneut geschätzt. Dies kann bis zu drei Runden so weitergeführt werden. In der Regel ist man sich danach einig. 

Planning Poker ist aufgrund des verdeckten Legens der Karten unabhängiger als die bereits beschriebene, sukzessive Vorgehensweise. Ich sehe in der Unabhängigkeit einen Benefit für die Qualität der Schätzungen. In der Praxis hat sich jedoch gezeigt, dass Planning Poker am Anfang häufig zur Überforderung des Teams führen kann. Der Grund hierfür ist, dass das Team gemeinsam seine Umgebung gut verstehen muss, um eine Einschätzung abgeben zu können. Aufgrund der unterschiedlichen Expertisen ist das Wissen häufig noch zu sehr bei Einzelpersonen angesiedelt. Auch wenn es die Erwartung ist, dass sich das mit Scrum ändert, fällt es den meisten Teams besonders am Anfang schwer, über derart große und übergreifende Übersichten zu sprechen. 

Aus diesem Schwerfallen können sich beim Planning Poker Dysfunktionen entwickeln. In der Praxis zeigt sich häufig, dass die eigentlich so unabhängige Technik durch (unbewusste) Beeinflussung an Unabhängigkeit verliert. Beispielsweise erlebe ich es häufig, dass ein Product Owner die Items in epischem Ausmaß präsentiert um sicherzustellen, dass auch jeder seine Domäne versteht (was eigentlich aber der Fall sein sollte). Danach ergänzt ein Senior Entwickler diese Eindrücke ausführlich mit technischen Hintergründen. Erst dann schätzt das Team. Dies hat zur Folge, dass das Team sich erst einmal durch einen quälend langen Vortrag von Product Owner und Lead-Entwickler kämpfen muss, und dann mit seiner Einschätzung lediglich die Möglichkeit hat, die Einschätzungen beider Redner zu bestätigen. Ein Dialog scheint in dieser Situation nicht zwingend notwendig. Er ist aber essentiell, um die unterschiedlichen Sichtweisen und das Expertenwissen miteinzubeziehen. Eine solche Vorgehensweise kann zu falschen Schätzungen führen.

Um dieser Beeinflussung vorzubeugen ist mein Tipp, beim Planning Poker folgendermaßen vorzugehen:

• • kurze Vorstellung der Items durch  den PO

• • Beantwortung von drei klärenden Fragen

• • Karten ziehen, schätzen, sprechen 

Generell empfehle ich das Planning Poker nur für Teams als Agile Estimation Methode, die schon Erfahrungen mit dem agilen Schätzen gesammelt haben. Aufgrund der beschriebenen anfänglichen “Überforderung” eignet es sich meiner Meinung nach nicht, um den Einstieg ins agile Schätzen zu finden. Um den Dialog zu forcieren und sich mit den Schätzungen aktiv auseinanderzusetzen,  ziehe daher beim Start die sukzessive Herangehensweise dem Planning Poker vor und wechsle erst nach einigen Sprint zum Planning Poker.

Beim agilen Schätzen ist eine Trennung der Rollen essentiell.

In der Agile Estimation ist es wichtig, die Rollenverteilung von Scrum zu wahren. Der Aufwand soll nur von denjenigen geschätzt werden, die aktiv am Sprint mitarbeiten. Der Hintergrund dafür ist, dass einige Akteure aufgrund ihrer Funktion in Scrum keine verlässliche Schätzung abgeben können. Es ist zum Beispiel nicht hilfreich, den Product Owner in die Schätzung des Aufwands mit einzubeziehen, da er aufgrund seiner Schnittstellenfunktion einem Interessenkonflikt ausgesetzt ist und tendenziell dazu neigt, optimistische Einschätzungen abzugeben. Es ist daher sinnvoller, den Product Owner lediglich im Falle von Fragen einzubeziehen und auf Basis seiner klaren Antworten eine Einschätzung zu treffen. Ebenso verhält es sich mit externen Experten: Einschätzungen aus der Ferne werden meist auch optimistischer getroffen und sind daher ebenfalls zu vermeiden. Der Scrum Master nimmt beim Schätzen eine moderierende Rolle ein. Er sorgt dafür, dass Gespräche zielgerichtet ablaufen und keine unabsichtlichen Beeinflussungen stattfinden um qualitativ hochwertige Schätzungen zu erhalten mit denen das Team weiterarbeiten kann.  

Ich hoffe, ich konnte mit meinen Tipps neue Impulse liefern, wie du agiles Schätzen effektiv nutzen kannst. Hast du Fragen oder Anmerkungen? Ich freue mich immer über Feedback.

Zusammenfassung

Es fällt leichter, relative Schätzungen abzugeben als zeitliche Schätzungen. In Scrum greift man daher auf das relative Schätzen zurück. Der größte Benefit beim Einsatz des Schätzens als agiles Werkzeug liegt darin, ein klärende Gespräche herbeizuführen. Es gibt verschieden Schätztechniken, die sich je nach Kontext besonders anbieten. Sukzessive Vorgehensweisen eignen sich zum Einstieg besonders. Planning Poker kann bei Fortgeschrittenen Teams als unabhängige Technik des agilen Schätzens eingesetzt werden.