"Dieses Projekt war bei jeder Statusmeldung im Rahmen von Zeit und Budget. Als das Budget dann verbraucht war, stellten wir aber fest, dass noch jede Menge Projekt übrig war."
Aussage eines Controllers über ein agiles Projekt

Das scheinbare Paradoxon dieser Aussage mag dem einen oder anderen bekannt vorkommen, der in agilen Projekten tätig ist. Jede Iteration wurde, wie geplant, erfolgreich umgesetzt; doch am Ende des Projekts fehlen notwendige Anforderungen, die nicht mehr innerhalb des veranschlagten Gesamtbudgets umgesetzt werden können. Wird dies erst kurz vor dem ursprünglich geplanten Projektende deutlich, sind Konflikte zwischen Auftraggeber und Dienstleister vorprogrammiert.

Doch welche Missverständnisse führen zu solchen Konflikten und wie können Sie diese verhindern? Wie lässt sich der Gesamtaufwand in einem agilen Projekt bestimmen? Ist das überhaupt möglich? Diesen Fragen widmet sich der vorliegende Beitrag.

Zunächst stelle ich die Charakteristika des Schätzens einzelner Sprints und des Gesamtaufwands gegenüber. Anschließend folgen Handlungsanweisungen, wie sich der Gesamtaufwand in agilen Projekten in den Griff bekommen lässt. Als agile Vorgehensweise wird in diesem Beitrag "Scrum" betrachtet (für eine Einführung in Scrum s. auch Wirdemann, Projekt Magazin 21/2009).

Schätzen von Sprints

Die Schätzung, wie viele User Storys im anstehenden Sprint umgesetzt werden können, erfolgt in Scrum in der Regel mit Hilfe von Storypoints und dem sogenannten Planning Poker (für Storypoints s. Wirdemann, Projekt Magazin 02/2010, für Planning Poker s. Linssen, Projekt Magazin 10/2012). Die wichtigsten Merkmale einer solchen Sprint-Schätzung sind:

• Die Anforderungen dürfen sich während eines Sprints nicht ändern.
• Allen Beteiligten ist klar, was zu tun ist, um eine User Story umzusetzen.
• Die Schätzung erfolgt durch die Entwickler, die die Anforderungen auch umsetzen.
• Durch die Verwendung von "Poker-Karten" geben die Entwickler ihre Schätzung unabhängig voneinander ab.
• Bei großen Abweichungen der Schätzungen einzelner User Storys werden deren Ursachen geklärt und die Entwickler schätzen erneut, bis ein Konsens erreicht wird.
• Das Team verständigt sich auf die Umsetzung der für einen Sprint besprochenen User Storys, d.h. es übernimmt die Verantwortung für deren Umsetzung.
• Durch die Verwendung der abstrakten Einheit "Storypoints" sind die Schätzungen unabhängig von Zeiteinheiten (wie z.B. Personentage) und lassen sich anhand von Erfahrungsdaten aus bisherigen Sprints auf Personentage umrechnen.

Lässt man Scrum-Spezifika wie Storypoints und Sprints weg, so ergibt sich daraus:

• Anforderungen müssen klar und unveränderlich sein.
• Die Entwickler, die die Anforderungen umsetzen, schätzen diese unabhängig voneiander.
• Im Falle stark abweichender Schätzungen wird ein Konsens gesucht.
• Es wird nicht in Tagen, sondern in einer abstrakten Größe geschätzt.
• Die geschätzten Anforderungen werden zeitnah umgesetzt.

Möchte man eine möglichst gute Expertenschätzung erreichen, so wird man bei ähnlichen Regeln landen (vgl. z.B. das Delphi-Verfahren, Schulz 2012).

Die Erfüllung dieser Punkte gewährleistet also – unabhängig vom Projektvorgehen – eine belastbare Aufwandsschätzung.

Schätzen des Gesamtaufwands

In einem Projekt, das mit einer traditionellen Vorgehensweise durchgeführt wird, existieren Pflichtenhefte oder Feinspezifikationen, die den Gesamtumfang des Projekts – idealerweise – genau dokumentieren. Damit ist es möglich, diese Dokumente zur Schätzung des Gesamtaufwands heranzuziehen.

Scrum hingegen fordert keine Dokumente, die zu Projektbeginn den Gesamtumfang beschreiben, sondern hier werden die Anforderungen im Product Backlog gesammelt. Dieses umfasst die noch nicht umgesetzten User Storys in einer priorisierten Reihenfolge. Im Gegensatz zu einem Pflichtenheft erhebt das Product Backlog allerdings nicht den Anspruch, initial alle Anforderungen eines Projekts zu enthalten. Es lässt sich jederzeit verändern, d. h. es können User Storys geändert, gelöscht oder hinzugefügt werden. Auch die Umpriorisierung von User Storys ist möglich und damit die Veränderung der Reihenfolge, in der diese abgearbeitet werden.