Sinn und Unsinn von Schätzungen – Teil 2

Im zweiten Teil dieser kleinen Artikelserie betrachten wir einige prinzipielle Methoden für Schätzungen und wie wir mit der richtigen Auswahl den Aufwand dafür deutlich reduzieren können.

Nachdem wir uns im vorigen Teil hauptsächlich mit den Gründen und den Zielgruppen für Schätzungen befasst haben, wollen wir in diesem Teil einmal beleuchten, welche Ansätze für die Durchführung von Schätzungen es uns ermöglichen können, den Aufwand für die Schätzung an sich deutlich zu reduzieren oder gar gegen Null gehen zu lassen.

Schätzung als Aktivität unterliegt in den meisten Fällen einer Art Evolution. Es beginnt in einer Art chaotischem Urzustand. Aufgaben werden einfach begonnen, ohne vorher genauere Überlegungen über die Aufgabe an sich oder deren Umsetzung zu machen. Ein Begriff, der mir dafür besonders gut gefällt ist „Cowboy-Programming“. Man braucht aber schon verdammt gute (Programmier-)Revolverhelden, um damit längerfristig zu überleben. Daraus ergibt sich aber auch, dass nur sehr kleine Teams damit überhaupt zurecht kommen. Bei größeren Teams würden sich die Revolverhelden sonst irgendwann ihre „Duelle“ liefern. Frei nach „Highlander“: Es kann nur einen geben!

Als nächste Stufe hat sich die Fremdschätzung herauskristallisiert. Manche sagen auch Expertenschätzung dazu. Ein oder mehrere „Experten“ schätzen dabei Aufgaben ab, ohne selbst die Verantwortung für die Umsetzung zu übernehmen. Das geht manchmal sogar so weit, dass selbst die Experten nichts voneinander wissen (Delphi-Methode). Aber: Wo finde ich die Experten, die sagen können, wie lange ich für die Umsetzung brauchen würde?

Warum also nicht gleich die schätzen lassen, die auch später die Aufgaben umsetzen sollen? Solch Teamschätzungen sind inzwischen zum Glück eher der Standard und auch in traditionellen Methoden wird zunehmend darauf gebaut. Problematisch ist hier oft die Erreichung einer einheitlichen Sicht innerhalb des Teams. Durch unterschiedliche Wissensgebiete und Talente ergeben sich zum Teil sehr unterschiedliche Meinungen darüber, wie aufwendig eine Aufgabe ist. Während mein Kollege als DB-Experte die stark datenbank-lastige Aufgabe als eher wenig aufwendig einschätzt, scheint sie mir doch sehr aufwendig zu sein. Dafür eine Lösung zu finden kann problematisch und langwierig werden. Oder es kristallisieren sich Wort- und Meinungsführer heraus, womit wir wieder nahe bei der Expertenschätzung landen.

Um diese Probleme zu umgehen (oder zumindest zu reduzieren), nutzt beispielsweise Scrum die Vergleichsschätzung. Hierbei werden keine absoluten Größen geschätzt. Man bewertet Aufgaben relativ zueinander und verwendet dazu meist neutrale Bewertungsskalen, z.B. Story Points.

Aber egal auf welcher Evolutionsstufe sich das eigene Vorgehen bei Schätzungen befindet, fast immer wird dabei auf (pseudo-)wissenschaftliche (z.B. Function Point Analyse) oder empirische Methoden gesetzt. Und bei den empirischen Methoden gibt es zwei, die besonders oft und unter vielfältigsten Namen genutzt werden – Analogieschätzung und Bauchgefühl.

• Analogieschätzung: „Wir haben doch letztens den Online-Shop für XY gebaut. Im neuen Projekt bauen wir auch einen Online-Shop mit vergleichbaren Funktionen. Letztes Mal hat es 6 Monate gedauert. Mit ein bisschen Sicherheitspuffer sagen wir dieses Mal 7 Monate.“
• Bauchgefühl: „Ich habe irgendwie den Eindruck, dass wir uns da ein wenig zu viel vorgenommen haben. Lasst uns lieber auf diese Aufgabe verzichten. Dann bin ich ziemlich zuversichtlich, dass wir den Termin schaffen.“

Solche oder ähnliche Argumentationen kommen den meisten wahrscheinlich bekannt vor. Gerade Scrum hat mit den Planning Meetings die Nutzung des Bauchgefühls stark gefördert (und mit ein wenig Statistik gewürzt). „Wenn dies …, dann könnte ich mir vorstellen …“ zählt zu den gängigsten Argumentationen wenn es darum geht, die Aufgaben für den kommenden Sprint festzulegen. Aber wenn wir eh schon stärker darauf setzen, welches Gefühl wir haben und weniger, welche Schätzwerte hinter den einzelnen Aufgaben stehen, warum schätzen wir dann überhaupt noch? Gibt es einen „nächsten“ Schritt in der Evolution?

Aus meiner Sicht werden statistische Methoden ein immer stärkeres Gewicht bekommen. Das ist dann zwar kein Schätzen im eigentlichen Sinn mehr, kann aber an vielen Stellen die gleiche Informationsqualität zu einem viel geringeren Aufwand liefern. Die Grundidee ist, dass über statistische Werte eine qualitative Aussage zu Kapazität und Geschwindigkeit von Teams und Projekten getroffen wird. Da die Werte praktisch automatisch entstehen, mal abgesehen vom meist eher geringen Aufwand für die Messung, reduziert sich der Aufwand für die Schätzung dramatisch.

Eine sehr bekannte, aber leider aus meiner Sicht auch sehr schlechte, statistische Methode ist die Velocity aus Scrum. Sie misst die Anzahl der Story Points, die in einem Sprint erreicht wurden. Dabei zählen nur Stories, die von Product Owner abgenommen wurden. Klingt erst einmal nicht so schlecht, hat aber einige gravierende Nachteile. Auf zwei entscheidende möchte ich kurz eingehen:

1. Velocity taugt nicht als Messgröße für die Geschwindigkeit in größeren Projekten. Die Schätzung mit Story Points ist teamspezifisch und nicht auf andere Teams übertragbar. Zwei Teams könnten der gleichen Story sehr unterschiedliche Werte zuweisen. Außer der Unterstützung des Bauchgefühls des Teams gewinne ich keine weiteren Erkenntnisse, speziell nicht für teamübergreifende Aspekte.
2. Velocity ist recht einfach manipulierbar. Da die Schätzung komplett teamgesteuert ist, kann die Velocity durch das Team bereits im Rahmen der Schätzung beeinflusst werden. Eine höhere Velocity lässt sich problemlos dadurch erreichen, dass alle Stories einfach einen Wert höher geschätzt werden. Das relative Verhältnis wird dadurch kaum verändert, die Velocity aber deutlich. Ein schönes Beispiel dafür beschreibt auch Joshua Kerievsky in seinem Blog (Stop Using Story Points).

Sehr viel besser funktionieren die nachfolgend kurz beschriebenen Methoden. Bei ihnen ist aber zu beachten, dass zum Teil Vorbedingungen für ihre Nutzung zu erfüllen sind. Für einige Projekte und Teams sind damit Veränderungen an ihren Vorgehensweisen verbunden. Auf jeden Fall gilt aber, dass man sich vorher darüber klar werden muss, welche Informationen überhaupt benötigt werden und für wen diese zur Verfügung gestellt werden sollen.

Die erste Methode nennt sich „Aufgabenzählung“ und funktioniert so einfach, wie der Name suggeriert. Wir zählen die Aufgaben, die in einem festgelegten Zeitraum fertig gestellt wurden und nehmen dies als Maßzahl für den folgenden Zeitraum. Dahinter steckt der Gedanke, dass alle Aufgaben annähernd gleichwertig (in Bezug auf Umfang und Lösungszeit) sind. Die tatsächlichen vorhandenen Unterschiede nivellieren sich über die Zeit. Anwendbar ist diese Methode, wenn für konstante Zeiträume geplant wird, wie beispielsweise bei den Sprints in Scrum. Die Teams sollten zudem schon einige Erfahrung in der Zusammenarbeit und mit anderen Schätzmethoden haben, um den Zuschnitt der Aufgaben tatsächlich einander anzunähern und eine stabile Arbeitsumgebung aufgebaut zu haben. Um Ausreisser bei den Messungen nicht zu viel Gewicht zu geben, sollte auch hier über mehrere Zeiträume ein Mittelwert gebildet werden.

Im Kern ist diese Idee schon recht alt. Don Wells, ein XP-Pionier, der unter anderem im berühmten Chrysler Comprehensive Compensation System Projekt gearbeitet hat, hat auf der XP Mailing Liste bereits beschrieben, dass sein Team nach einiger Zeit der Zusammenarbeit genau diesen Ansatz verfolgt hat.

Die zweite Methode misst die Zeit, die für die Lösung einer Aufgabe gebraucht wird. Für die Vorhersagbarkeit ist es wichtig, dass die gesamte Entwicklung einem stabilen Prozess folgt. Veränderungen am Prozess verändern meist auch die Durchlaufzeit von Aufgaben durch diesen. Mit einer Klassifizierung der Aufgaben in Größenkategorien, kann man die Genauigkeit der Vorhersagen erhöhen, handelt sich aber den zusätzlichen Aufwand für die Bewertung der Aufgaben vor ihrer Bearbeitung ein. Da gilt es sicherlich abzuwägen, ob der entstehende Nutzen den Aufwand rechtfertigt.

Diese Methode ist natürlich nicht neu. In Kanban wird die sogenannte „Lead Time“ gemessen, die den Zeitraum vom Start der Bearbeitung einer Aufgabe bis zu ihrer Übergabe erfasst. Hieraus können über Verteilungsmuster oder Mittelwerte Rückschlüsse für die Planung und Vorhersagbarkeit bei weiteren Aufgaben gezogen werden. Insbesondere in Kombination mit einer Kategorisierung der Aufgaben kann aber auch in anderen Kontexten diese Methode Anwendung finden. So kann bei der Verwendung von Scrum die Füllung der Sprint-Backlogs unterstützt werden. Statt jede User Story zu schätzen, können wir eine einfache Kategorisierung in 3 Größenkategorien verwenden. Aufgrund der vorherigen Messergebnisse kann dann ohne großen Aufwand zumindest eine erste Version des Sprint-Backlogs entstehen. Natürlich obliegt es weiterhin dem Team, dieses nach eigenen Einschätzungen anzupassen (womit wir wieder beim Bauchgefühl wären). Zumindest der Aufwand für die Schätzung an sich, kann so deutlich reduziert und beispielsweise für eine intensivere Auseinandersetzung mit den User Stories und ihrem Kontext genutzt werden.

Mit der Wahl des richtigen Ansatzes für das Schätzen, kann so deutlich an dessen Aufwand gespart werden. Soweit die Theorie. Im dritten Teil dieser Reihe betrachten wir an einem praktischen Beispiel, wie man mit unterschiedlich großen Schritten zu einer Verbesserung des Schätzprozesses gelangen kann.