Agiler Adventskalender: (Agile) Schätzmethoden

Zur Halbzeit in unserem Agilen Adventskalender beschäftigen wir uns mit (agilen) Schätzmethoden und folgender Frage:

Wann nehme ich welche Schätzmethode?

Der Schätzvorgang

Zunächst einmal ist es wichtig zu wissen, dass der Schätzvorgang immer ein recht ungenauer Vorgang ist. Deshalb heißt es ja Schätzen.

Es ist hilfreich, das Schätzen von Product Backlog Items als Lerninstrument zu sehen: Als Entwicklungsteam (inklusive Product Owner!) möchten wir verstehen, wie ein Product Backlog Item zum Beispiel von der Komplexität her eingeschätzt wird.

Dabei ist es wichtig, die Schätzungen transparent zu machen. Ein Verfahren wie das bekannte Planning Poker versucht zunächst, durch geheime Einordnung eine individuelle Schätzung auf einer bestimmten Skala (meist auf einer Fibonacci-Reihe) zu erreichen. Durch Aufdecken der individuellen Einschätzungen ergibt sich die Einladung zum Gespräch, sollten die Einschätzungen (zu) stark voneinander abweichen.

Es ist wie ein Kompass zu sehen, der Aufschluss darüber gibt, ob ein Backlog Item vielleicht zu groß ist und kleiner geschnitten werden sollte. Oder ob noch Informationen fehlen, und die Entwickler dadurch Schwierigkeiten haben, einen guten Lösungsweg für die Realisierung zu finden. Aus der Diskussion, die sich dadurch ergibt, kann gemeinsam gelernt werden. 

Schätzungen mit T-Shirt-Größen

Die Schätzungen bieten grundsätzlich weder Exaktheit noch Präzision. Falls die Schätzgrößen mit tatsächlichen Aufwänden verwechselt werden (was oftmals auf Stakeholder-Seite passieren kann), ist es hilfreich, in T-Shirt-Größen zu schätzen.

Das Schätzverfahren wie zum Beispiel Planning Poker bleibt das Gleiche, nur die Skala wird abgeändert in Größen wie S, M, L, XL, XXL, … So kann zum Beispiel entschieden werden, dass ein Backlog Item der Größe XXL zu groß ist und aufgesplittet werden sollte. Die Gefahr, in tatsächlichen Aufwänden zu denken, fällt hierbei weg.

Magic Estimation

Oftmals bleibt nicht viel Zeit in den Refinement-Treffen. Manchmal ist auch eine sehr große Anzahl an Product Backlog Items vorhanden. Es herrscht also Unklarheit über die Komplexität in der großen Menge der Backlog Items, die Übersicht leidet. Hier hat sich die Methode der Magic Estimation bewährt, um ein Backlog mit vielen Items schnell zu schätzen.

Während der Magic Estimation, die von einem Scrum Master oder Agile Coach begleitet wird, wird im Stillen geschätzt: Zunächst wird ein Referenz-Backlog-Item, das gut schätzbar ist, herausgesucht, besprochen und eingeordnet. Alle anderen Backlog Items werden relativ zu diesem Backlog Item im stillen Verfahren ohne weiteres Gespräch eingeordnet. Der Reihe nach werden also die Backlog Items den einzelnen Skalen-Werten (zum Beispiel T-Shirt Sizes S, M, L, XL, XXL, …) zugeordnet. Es ist möglich, ein bereits zuvor einsortiertes Backlog Item umzuordnen. Passiert dies mehrmals, so ist dies ein Zeichen für Unklarheit innerhalb des Teams. Somit sollte dieses Backlog Item aussortiert und für die spätere Diskussion vorgemerkt werden.

Es ist damit gut möglich, ein dreistelliges Backlog innerhalb kurzer Zeit einzuordnen. Ergänzt mit Erfahrungswerten kann sogar eine grobe Einschätzung getroffen werden, wie viele Team-Sprints mindestens benötigt werden.

Drei-Punkt-Schätzung

Ein anderes Mittel ist die Drei-Punkt-Schätzung: Hier wird in Worst Case, Likely Case und Best Case geschätzt, und zwar in (idealen) Personentagen. Wir raten jedoch stark dazu, eine Drei-Punkt-Schätzung ausschließlich als Ergänzung zu vorhandenen abstrakten Schätzungen zu nutzen und immer wieder dabei zu beachten: Absolute Schätzungen sind von uns Menschen nur schwer zu treffen. Schätzungen auf Basis abstrakter Werte (zB Fibonacci-Reihe oder T-Shirt-Sizes) und im Vergleich zu anderen abstrakten Werten helfen, diese Fehler zu vermeiden.

Zudem ist es so, dass eine Schätzung nicht nur Komplexität, sondern auch weitere Faktoren wie Risiko, Unsicherheit, Aufwand betrachtet. Eine passende Erläuterung findet sich im Blog bei Mike Cohn.

Du suchst einen tatkräftigen Entwicklungs-Partner und möchtest mit uns Dein Software-Vorhaben diskutieren? Dann melde dich gerne bei kontakt@mayflower.de

Oder schau Dir unser Training “Become a Product Leader” an, mit dem Du das nächste Level der Product Ownership erklimmst. Unsere Interims Product Owner helfen Euch auch direkt im Maschinenraum.