

Für das Schätzen eines Sprints stehen in Scrum verschiedene Methoden, wie z.B. Planning Poker, zur Verfügung. Mit etwas Erfahrung und Übung schaffen es agile Teams auf diese Weise, zuverlässige Vorhersagen darüber zu treffen, was sie in einem Sprint umsetzen können. Eine klare Aussage über den Gesamtaufwand eines agilen Projekts ist in vielen Fällen hingegen nicht möglich. Doch gerade zu Projektbeginn sind diese Informationen für den Auftraggeber von großer Bedeutung. Dorian Gloski gibt in diesem Beitrag Tipps, was beim Schätzen des Gesamtaufwands in agilen Projekten wichtig ist, um klare Aussagen treffen zu können.
Für das Schätzen eines Sprints stehen in Scrum verschiedene Methoden, wie z.B. Planning Poker, zur Verfügung. Mit etwas Erfahrung und Übung schaffen es agile Teams auf diese Weise, zuverlässige Vorhersagen darüber zu treffen, was sie in einem Sprint umsetzen können. Eine klare Aussage über den Gesamtaufwand eines agilen Projekts ist in vielen Fällen hingegen nicht möglich. Doch gerade zu Projektbeginn sind diese Informationen für den Auftraggeber von großer Bedeutung. Dorian Gloski gibt in diesem Beitrag Tipps, was beim Schätzen des Gesamtaufwands in agilen Projekten wichtig ist, um klare Aussagen treffen zu können.
"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).
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:
Lässt man Scrum-Spezifika wie Storypoints und Sprints weg, so ergibt sich daraus:
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.
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.
1 Monat unverbindlich testen!
Peter Jetter
30.10.2013