AGILE VERFAHREN ZUR AUFWANDS- BZW. UMFANGSSCHÄTZUNG
DIE SCHÄTZMETHODE – BESTIMMENDES ELEMENT DER PROJEKTPLANUNG
KLASSISCHE SCHÄTZMETHODE Die Aufwandsschätzung ist grundsätzlich ein wichtiger Bestandteil in der Planung eines Projekts. Klassisch wird dabei die Spezifikation des Ergebniszieles im Projektvorhaben (z. B. in Form eines Lastenheftes) analysiert. Dabei werden Anforderungen den konkreten Kosten und der Zeit gegenübergestellt.
ABSTRAKTE SCHÄTZMETHODE Ein wichtiger Unterschied zu klassischen Schätzverfahren liegt zunächst in der Unterscheidung zwischen dem Umfang (Größe und Schwierigkeitsgrad bzw. Komplexität) eines Vorhabens und seinem Aufwand. Geschätzt wird in abstrakten Schätzmethoden nicht der Aufwand, sondern vorab nur der Umfang. Dies geschieht in Form einer definierten Größeneinheit (Points) bzw. einer Einschätzung der Komplexität (Grad der Abhängigkeiten der Detailaspekte untereinander). Auch in Organisationsprojekten ist die Einschätzung von Umfang und Gewicht einzelner Aktivitäten und Aufgabenbündel ein wichtiger Schritt. Diese abstrakte Schätzmethode, bei der die Arbeitspakete in ihrer Relation zueinander eingeschätzt werden, gibt neue Perspektiven und eine höhere Treffsicherheit, weil sie auch ermöglicht, inhaltliche und soziale Komplexität intuitiv und relational im Team zu erfassen.
VORTEILE ABSTRAKTER SCHÄTZMETHODEN Vergleichende, d. h. abstrakte Schätzungen sind schneller durchführbar als das Schätzen absoluter Größen. Relationen einzuschätzen („was ist kleiner und was größer“) fällt in der Regel leichter, als absolute Größen zu schätzen. Umfangsschätzungen sind außerdem zeitlos, müssen also im Projektverlauf nicht angepasst werden. Objektivität ist ein wichtiger Faktor. Durch die Trennung von Umfang und Aufwand können Schätzungen abgegeben werden, ohne die umsetzenden Individuen und ihre Arbeitsgeschwindigkeit zu kennen.
VON DER ABSTRAKTEN SCHÄTZUNG ZUR AUFWANDSERMITTLUNG Zur Aufwandsschätzung gelangt man durch den sogenannten 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.
- Grobschätzung – liegen keine historischen Daten vor und kann kein Vorprojekt durchgeführt werden, dann kann ein grober Velocity-Wert aus der Erfahrung geschätzt werden. Natürlich können dann alle abgeleiteten Aufwandsschätzungen nur sehr grobe Näherungen darstellen.
SCHÄTZEN NACH DER METHODE „PLANNING POKER“
ALLGEMEIN Wie oben beschrieben, ist die Grundannahme der Methode Scrum, dass komplexe Produktfertigungs- und Entwicklungsprozesse so komplex sind, dass sich ihre Umsetzung nicht detailliert im Voraus planen lässt, geschweige denn die einzelnen Umsetzungsschritte. Daher wird in allen agilen Schätzungsmethoden nur die Größe und der Umfang einer Story, jedoch nicht die Dauer bestimmt.
Der eigentliche Schätzvorgang setzt verschiedene User Stories in Relation zueinander; die Schätzung wird umso konkreter, je mehr Erfahrung ein Team mitbringt. Die Kriterien für den Umfang und die Komplexität, damit die Größe einer User Story, können Faktoren wie die Anzahl von Einzeltätigkeiten, das generelle Arbeitsvolumen, die Komplexität, Risiken oder externen Abhängigkeiten, usw. sein. Es wird also nicht der Aufwand, sondern ausschließlich die Größe einer Story mit Umfang und Schwierigkeitsgrad geschätzt.
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 abgegebene Schätzung unterstützt. So werden auch die unterschiedlichen Erfahrungen, Perspektiven und Ideen der Teammitglieder zu den Stories und zur Einschätzung integriert und genutzt. Als Metrik für die Schätzergebnisse werden die Zahlenreihe der Fibunacci Funktion herangezogen. In Bezug zu Scrum bedeuten die Schätzwerte Schwierigkeitsgrade, werden in Story Points gemessen und in folgender Abstufung eingeteilt:
- 0 – kein Aufwand (wurde schon mal erstellt, ist schon vorhanden)
- 1 – sehr klein (kleinste Größe),
- 2 – klein (doppelt so viel wie die unter „1“ geschätzte Größe),
- 3 – mittel (so viel wie Größe „1“ und „2“ zusammen),
- 5 – gross (so viel wie Größe „2“ und „3“ zusammen),
- 8 – sehr gross (so viel wie Größe „3“ und „5“ zusammen),
- 13 – riesig (so viel wie Größe „5“ und „8“ zusammen),
- ? – unbestimmbar (User Story ist für das Team unbestimmbar und muss vom Product Owner neu oder kleiner gestaltet werden).
DIE SCHÄTZUNG Das Verfahren „Planning Poker“ ist in Scrum-Projekten die am häufigsten angewandte Schätzmethode. Am Beginn steht ein vom Product Owner einberufenes Initialmeeting auf dem Plan, auf das eine Schätzklausur folgt. Dort werden die ersten Sprints festgelegt. Zu Beginn des Meetings wird ein zeitlicher Rahmen definiert und die einzelnen User Stories werden vorgestellt und vom gesamten Team geschätzt. Bei größeren Abweichungen tritt der Scrum Master als Moderator in Aktion und es werden die beiden unterschiedlichsten Werte diskutiert. Darauf folgen weitere Schätzungen, bis eine Konvergenz entsteht. Bei Projekten, die als sehr groß geschätzt werden (>13 Points) muss die Story erneut geklärt bzw. eventuell in mehrere kleinere Stories zerlegt werden.
Derartige Schätzklausuren finden während agiler Projekte regelmäßig statt, sodass zumindest immer zwei Projekt-Phasen (Sprints) im Voraus die jeweiligen User Stories geschätzt werden. Erfahrungen legen nahe, zu Beginn des Projekts in einer initialen Schätzklausur den kompletten Backlog und regelmäßig nur die neu hinzugekommen User Stories zu schätzen.
ERGÄNZENDE AGILE SCHÄTZMETHODEN
MAGIC ESTIMATION METHODE Mit dieser Technik lassen sich trotz großer Backlogs mit relativ geringem Zeitaufwand sehr aussagekräftige Schätzungen erstellen. Wie beim Planning Poker Verfahren geht es bei der initialen Schätzung nicht um Präzision, sondern lediglich um eine erste Einschätzung. Man verwendet die Methode gerne bei der initialen Abschätzung eines gesamten Backlogs. Alle User Stories liegen dabei verteilt auf dem Boden und die Teammitglieder dürfen nacheinander innerhalb von zehn Minuten die einzelnen Stories schätzen. Dabei ordnet und bündelt der erste Schätzer die Stories je nach Schwierigkeitsgrad in der Metrik der „Planning Poker“ Karten (0 bis?). Sein Nachfolger darf dann diese Schätzung akzeptieren oder abändern. Auftretende Fragen sind dabei nur mit dem Product Owner auszutauschen. Der Rest des Teams kann die Informationen aufnehmen, darf aber nicht in Diskurs treten. Wenn die letzte Schätzung abgegeben wurde, wird diese ins Backlog aufgenommen. Bei komplexen und übergroßen Backlogs ist es von Fall zu Fall hilfreich, die Schätzzeit pro Person auf 3 – 5 Minuten zu reduzieren, was die Qualität in der Regel nicht mindert (Gloger, 2013).
VORAUSSETZUNGEN
- 1. Wie bei der Schätzmethode „Planning Poker“sollten auch hier vor dem ersten Sprint ausreichend Backlog Items für mindestens 1 – 3 Sprints vorhanden und vom Product Owner priorisiert sein, um diese dann anschließend vom Team schätzenzu lassen.
- 2. Die Kenntnis von Big Picture, Vision und Zielsetzung des zu entwickelnden Produktes ist vor dem Start wichtig.
- 3. Gut formulierte („geschnittene“)Backlog Items (User Stories) und ein prall gefülltes Product Backlog sind hilfreich. Dabei kann der Scrum Master dem Product Owner im Vorfeld unterstützend zur Seite stehen (vorab Besprechung der Backlog Items). Das Team sollte außerdem vor dem Meeting das Backlog einsehen können; so wird wertvolle Zeit beim eigentlichen Schätzmeeting gespart.
ANREGUNG Veränderungen der Schätzwerte zu einer User Story im Rahmen der Schätzklausur implizieren unterschiedliche Meinungen oder Erwartungen im Hinblick auf Umfang und Komplexität der Story. In diesem Fall ist es hilfreich, diese Story mit einem Markierungspunkt zu versehen. Die Anzahl der Markierungspunkte beschreiben dann den Grad der Meinungsunterschiedlichkeit betreffend dieser Story im Team. Der Product Owner muss dann diese unterschiedlich geschätzten Stories mit dem Team nochmals diskutieren bzw. im...
