Agiles Schätzen bezieht sich auf den Aufwand einer Anforderung (User Story) in der agilen Softwareentwicklung. Vor allem bei SCRUM ist als Vorgehen sehr beliebt. Das Schätzen zielt darauf ab, die strukturellen Eigenschaften einer Aufgabe zu erfassen, um deren Umfang zu beurteilen.
Für die folgenden Ausführungen gehe ich von einem relativen Schätzansatz aus. Das bedeutet: Wir setzen die Anforderungen zueinander ins Verhältnis und drücken unsere Einschätzung durch sogenannte Storypoints aus. Je mehr Storypoints vergeben werden, desto höher ist der Gesamtaufwand.
Ich vergleiche keine alternativen Ansätze wie „No Estimates“, sondern betrachte die Situation, in der ein Team User Stories schätzt.
Warum schätzen wir?
Die Aufwandsschätzung hilft uns, eine Grundlage für die Planung von Sprints zu haben. Und wir sind damit in der Lage, Prognosen abzugeben. Dadurch können wir den Inhalt für den anstehenden Sprint festlegen. Auch bietet agiles Schätzen uns weitere Möglichkeiten, zum Beispiel eine Aussage zum voraussichtlichen Umfang des nächsten Relase treffen zu können.
Was schätzen wir?
Für eine sinnvolle Planung benötigen wir den relativen Gesamtaufwand einer Anforderung. Der Gesamtaufwand setzt sich typischerweise wie folgt zusammen:
Gesamtaufwand = Menge an Arbeit + Risiken + Unsicherheiten + Komplexität
Dazu ein anschauliches Beispiel: Sagen wir mal, eine User Story besteht darin, Kerzen aufzustellen und anzuzünden. Der Project Owner stellt die User Story kurz vor. Anschließend bespricht die Gruppe den Gesamtaufwand.
- Die Menge an Arbeit bezieht sich auf die Frage, wie viel Arbeit für das Projekt zu leisten ist. Also: Sollen wir 1 Kerze anzünden, oder 100 Kerzen?
- Risiken sind Umstände, von denen wir wissen, dass sie Auswirkungen haben, wenn sie eintreten. Also: Der Wind könnte eine oder mehrere Kerzen ausblasen – und wir müssten die Kerzen erneut entzünden.
- Unsicherheiten sind Umstände, deren Zustand zum Zeitpunkt der Schätzung nicht klar ist. Also: Sind alle Kerzen gut zugänglich? Brennen alle Kerzen gleich schnell an? Gibt es abgebrochene Dochte?
- Komplexität ist der Schwierigkeitsgrad des Projekts oder der Aufgabe. Also: Stehen alle 100 Kerzen auf einem Tisch? Stecken die Kerzen in einem Leuchter mit mehreren Ebenen, der an der Decke hängt?
Wir können noch Maßnahmen festlegen. Beispielsweise solche, die die Eintrittswahrscheinlichkeit eines Risikos vermindern und/oder die Auswirkung abschwächen. Das nennt sich Mitigation.
In unserem Fall könnte die Mitigation daraus bestehen, die Fenster zu schließen oder ein Windschutz aufzustellen, um die oben genannten Risiken zu minimieren. Allerdings sollte uns klar sein: Auch eine Risiko-Mitigation verursacht Aufwand – und muss in die geschätzte Menge der Arbeit einbezogen werden.
In der Diskussion der Entwickler zu einer User Story können weitere Aspekte auftreten, die eine Schätzung beeinflussen. Doch es ist zielführend, bewusst wenige Aspekte zu nehmen – und weitere dann anzusprechen, wenn die Situation es nötig macht. Die vier oben genannten Aspekte bieten eine sehr gute Grundlage.
Ein typischer Fehler: Oftmals vermischen agile Teams die Menge an Arbeit, Risiken und Unsicherheiten mit der eigentlichen Komplexität einer Aufgabe zu einer Gesamtkomplexität.
In der Konsequenz leidet die Klarheit und Transparenz und damit die Qualität der Schätzung. Die Aspekte können nicht mehr einzeln betrachtet und diskutiert werden. Stattdessen erfolgen Diskussionen häufig auf Basis der intransparenten „Gesamtkomplexität“.
Wie beeinflussen die verschiedenen Aspekte eine Schätzung?
Menge an Arbeit
Die Menge an Arbeit beeinflusst unmittelbar die Schätzung. Das folgende Beispiel zeigt diesen Sachverhalt am Beispiel einer Weboberfläche auf:
Risiken und Unsicherheiten
Ungenau beschriebene Aspekte bekommen mehr Storypoints, um die Unsicherheit zu reflektieren. Betreffen Änderungen alte, unbekannte Teile eines Systems, passen wir die Schätzung ebenfalls nach oben an. Das ist z.B. der Fall, wenn keine automatisierten Tests existieren.
Die Einschätzung eines Risikos hat Einfluss auf die Höhe der Schätzung, also die Menge der Storypoints. Wenn wir z.B. eine nicht dokumentierte bestehende Weboberfläche ohne automatisierte Tests anpassen müssen, ist das Risiko, dass etwas nicht so verläuft, wie geplant, deutlich größer. Das beeinflusst die Höhe einer Schätzung.
Komplexität
Komplexität ist ein Maß dafür, wie schwierig eine Arbeit ist. Die Erstellung einer Maske für eine Oberfläche ist z.B. schwieriger, wenn es feldübergreifende Abhängigkeiten gibt.
Je höher die Komplexität, desto aufwendiger die Konzeption für die Umsetzung und der Test zur Überprüfung der korrekten Umsetzung. Auch die Wahrscheinlichkeit für Fehler in der Umsetzung steigt.
Das folgende Beispiel zeigt die unterschiedliche Komplexität zweier Weboberflächen:
Die Anzahl an Feldern ist in beiden Fällen gleich. Auf der rechten Seite sind die Anforderungen an die Felder bzw. das Zusammenspiel zwischen den Feldern komplexer.
Als Folge daraus ist die Komplexität der Gesamtanforderung auf der rechen Seite höher. Das führt zu einem höheren Aufwand in der Umsetzung.
Wie werden die verschiedenen Aspekte zusammengefaßt?
Wir verwenden Storypoints als relatives Maß für den Gesamtaufwand einer Aufgabe. Die Storypoints einer Aufgabe ergeben sich daraus wie die Entwickler die unterschiedliche Facetten wie Menge an Arbeit, Risiken, Unsicherheiten und Komplexität der Arbeit für eine zu schätzende Story bewerten.
Im Idealfall führt dasjenige Entwicklerteam die Schätzung durch, das die Aufgabe hinterher auch implementiert. Je mehr Storypoints das Team vergibt, desto höher ist der Gesamtaufwand der Aufgabe.
Die Höhe der Schätzung hängt nicht von den Fähigkeiten oder der Erfahrung des Entwicklerteams ab, sondern davon wie Stories relativ zueinander eingeschätzt werden. Natürlich kann ein erfahrenes Entwicklerteam mehr Stories und damit Storypoints in einem Sprint umsetzen als ein Junior-Team. Das beeinflusst nicht die Einschätzung der User Stories, sondern führt zur einer höheren Umsetzungsgeschwindigkeit. Diese wird als Velocity bezeichnet und misst die Menge der umgesetzten Storypoints.
Die Bedeutung von Referenzstories
Referenzstories sind eine wichtige Hilfestellung für eine relative Schätzung.
- Eine Refernzstory ist ein Beispiel für eine typische Story, die gut zu einer bestimmten Anzahl an Storypoints passt.
- Referenzstories sind für eine relative Schätzung als Vergleichsgröße wichtig. Denn an ihr kann das agile Team messen, ob die neue User Story mehr Aufwand bedeutet oder weniger als die Referenz.
- Referenzstories schaffen Klarheit, wenn es unterschiedliche Aufgabenstellungen gibt, die z.B. mit 8 Storypoints eingeschätzt werden.
Fazit
Beim agilen Schätzen berücksichtigen wir die Komplexität, die Menge an Arbeit sowie Risiken und Unsicherheiten einer Aufgabe. Was sich zunächst schwierig anhört, können wir in der Praxis erfahrungsgemäß einfach handhaben.
Bei der Diskussion des Entwicklerteams fallen verschiedene Blickwinkel auf eine Aufgabe. Diese können dann z.B. im Rahmen eines Planning Poker mit Punkten versehen werden. Wichtig ist, dass die unterschiedlichen Dimensionen zur Bewertung einer Aufgabe allen bekannt und präsent sind.
Denn daraus ergeben sich in der Folge ganz natürlich Diskussionen, die diesen Aspekten Rechnung tragen, z.B.:
- „Ich bin zu einer höheren Einschätzung als bei unserer Referenzstory gelangt, da wir in diesem Fall mehr feldübergreifende Abhängigkeiten haben.“
- „Die Anpassung betrifft den alten Teil der Anwendung. Wir müssen dort auch die Unit-Tests für die betroffenen Teile mit entwickeln. Daher ist meine Schätzung höher.“.
Sind Anforderungen für einen Sprint zu groß, gilt natürlich unverändert, dass wir Anfoderungen in kleinere Teile zerlegen.
