Autor
Ein kontroverses, beinahe philosophisches Thema
Was ist agiles Schätzen?
Eine Aufwandsschätzung ist wichtiger Bestandteil der Planung eines Softwareprojektes. Klassisch wird dabei das Lastenheft analysiert und den Anforderungen eine Anzahl konkreter Personentage zugeordnet. Die Erfahrung (nicht nur der agilen Projektwelt) hat aber gezeigt, dass das vergleichende Schätzen in abstrakten Schätzmaßen zu deutlich schnelleren und besseren Ergebnissen führt.
Ein wichtiger Unterschied zu klassischen Schätzverfahren liegt zunächst in der Unterscheidung zwischen Komplexität und Aufwand. Geschätzt wird nicht mehr der Aufwand, sondern nur die Komplexität eines umzusetzenden Features.
Der Wegbereiter dieser Methodik war Barry W. Boehm, der mit der Function-Point-Analyse den Fokus von der Umsetzungsdauer hin zur Komplexität eines Features verschoben hat. Der Umfang eines fachlichen Features lässt sich in einem abstrakten Komplexitätsmaß (den Function Points) ausdrücken. Der Aufwand, der zur Umsetzung des Features benötigt wird, leitet sich dann aus weiteren Faktoren ab.
Welche Vorteile bietet agiles Schätzen
- Vergleichende/abstrakte Schätzungen sind schneller durchführbar als das Schätzen absoluter Größen. Menschen können schlecht absolute Dinge schätzen. Sie können aber gut Dinge zueinander in Relation setzen und erkennen, was größer oder kleiner ist.
- Komplexitätsschätzungen altern nicht. Werden konkrete Zeitmaße verwendet, dann müssen häufig diese Schätzungen im Laufe eines Projektes durch Neuschätzung korrigiert werden. Beispielsweise dauert das Erstellen einer Formulareingabe zu Beginn eines Projektes durch fehlende Erfahrung vielleicht deutlich länger als im späteren Projektverlauf. Die Komplexität hingegen bleibt aus Anwendersicht die gleiche und muss deshalb im Projektverlauf nicht angepasst werden.
- Objektivität: Durch die Trennung von Komplexität und Aufwand können Komplexitätsschätzungen abgegeben werden, ohne die umsetzenden Individuen zu kennen. Bei der Schätzung der Komplexität muss nicht bereits die Geschwindigkeit unterschiedlicher Developer einkalkuliert werden, was die Schätzung aufwendig und personenbezogen machen würde.
- Einbindung des Teams: Durch die Diskussion mit und in dem Team über die User Storys bekommt das Team ein gemeinsames Verständnis von der Story. Unklarheiten werden früh erkannt und offene Fragen können schon vor dem Sprint mit den Stakeholdern geklärt werden.
Story-Point-Schätzungen
Im Kontext agiler Projekte hat sich das Schätzen in abstrakten Schätzmaßen durchgesetzt. Hier wird nicht ein großes Lastenheft "am Stück" vor Projektstart geschätzt. Stattdessen werden die Anforderungen in Storys zerlegt. Jede Story beschreibt eine Anforderung, die für das Produkt einen Mehrwert darstellt. Die Storys sind so zu formulieren, dass sie innerhalb eines Zeitrahmens von ein bis zwei Wochen umsetzbar sind.
Der Vorteil dieser Zerlegung besteht darin, dass Storys dieser Größe sich in ihrer Komplexität schnell schätzen lassen. Als Einheit werden Story Points verwendet, die durch das Vergleichen verschiedener Storys vergeben werden (Analogieverfahren).
Wie wird aus der abstrakten Schätzung eine Aufwandsabschätzung?
Zur Aufwandsschätzung gelangt man durch den Velocity-Faktor. Der Faktor gibt an, wie viele Story Points in einem definierten Zeitbereich umgesetzt werden können.
Im Wesentlichen gibt es drei Möglichkeiten zur Ermittlung des Velocity-Faktors:
- Historische Daten: Aus der Vergangenheit ist bekannt, wie viele Story Points das Team pro Zeiteinheit schafft. Dabei ist es wichtig, dass die Teamzusammensetzung vergleichbar ist.
- Vorprojekt: Ein kleiner Ausschnitt des Gesamtprojektes wird in einem kurzen Vorprojekt umgesetzt und daraus die Velocity-Kennziffer ermittelt.
- Schätzen: Liegen keine historischen Daten vor und kann kein Vorprojekt durchgeführt werden, dann kann ein grober Wert der Velocity aus der Erfahrung geschätzt werden. Natürlich können dann alle abgeleiteten Aufwandsschätzungen nur sehr grobe Näherungen darstellen.
Durchführung der Schätzung
In agilen Projekten wird großer Wert auf das Commitment und die Selbststeuerung eines Teams gelegt. Deshalb ist es beim Schätzen besonders wichtig, dass das gesamte Team einbezogen wird und die Schätzwerte stützt. Eine im agilen Umfeld weitverbreitete Technik ist das Ermitteln der Story-Point-Werte über Schätz-Poker.
Pro Story legt jedes Teammitglied verdeckt (und damit von anderen unbeeinflusst) eine Karte mit dem geschätzten Komplexitätswert auf den Tisch. Dann werden alle Karten gleichzeitig aufgedeckt.
Gibt es nach dem Aufdecken der Karten große Abweichung in der Einschätzung, dann wird im Team über diese unterschiedlichen Bewertungen diskutiert. Nach ein bis zwei weiteren Schätzrunden sollten die Werte dann konvergieren.
Auf diese Weise gelangt das Team schnell zu einem tieferen Verständnis der umzusetzenden Storys und zu guten Schätzwerten.
Literaturempfehlungen
- Mike Cohn: Agile Estimating and Planning
- Barry W. Boehm: Software Engineering Economics
- Delphi method: http://en.wikipedia.org/wiki/Delphi_method
Über den Autor
Markus Gärtner
Markus arbeitet seit 2010 als Organizational Design Consultant, Certified Scrum Trainer (CST) und Agile Coach für it-agile. Markus präsentiert regelmäßig auf agilen Konferenzen und widmet sich dem Schreiben über agile Softwareentwicklung, Software Craftsmanship und Software Testen, vornehmlich in einem agilen Umfeld.
Veröffentlichungen (u. a.)
Kennen Sie eigentlich schon it-agile?
Die Expert:innen zu agiler Arbeit und agilen Methoden
Kund:innen wollen begeistert werden. Mit innovativen Produkten, durch Schnelligkeit, Transparenz und auch Verlässlichkeit. Unsere erfahrenen Agile Coaches sorgen gemeinsam mit Ihren Teams und Führungskräften dafür, auch in komplexer Umgebung Ihre Ziele nicht aus dem Auge zu verlieren und implementieren die richtigen agilen Methoden für nachhaltige Veränderung.
- Wir integrieren Pragmatismus mit Idealismus
- Wir befähigen Sie nachhaltig ohne Abhängigkeit von uns
- Wir erzeugen Kundenfokus mit wirkungsvoller Agilität
