Gesamtaufwände in agilen Projekten schätzen – darauf müssen Sie achten

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.

Download PDFDownload PDF

Gesamtaufwände in agilen Projekten schätzen – darauf müssen Sie achten

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.

Wir empfehlen zum Thema Scrum
3 x 4 Stunden
07.11.2024
1.295,00,-
User Story Mapping - Die Nutzer im Blick mit der Produkt-Landkarte

Stellen Sie Kundenanforderungen – ohne endlose Dokumentationen – strukturiert dar und behalten Sie mit diesem Seminar die Kontrolle über den gesamten Entwicklungsprozess. Mit vielen Praxisübungen und direkt anwendbar. Mehr Infos

"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.

Alle Kommentare (1)

Peter
Jetter

"•Allen Beteiligten ist klar, was zu tun ist, um eine User Story umzusetzen" In meiner Erfahrung sind klare Vorstellungen der Requirements sehr selten. Auf keinen Fall die Regel. Das Problemverständnis entwickelt sich parallel zum Lösungsverständnis (Wicked dilemma: cannot completely understand the problem until it is solved) Meist nähert man sich iterativ einem Punkt, wo die Kosten jeder weiteren Iteration nicht mehr vom Nutzen gerechtfertigt werden. Maximierung des Business Values im Rahmen der constraints. Insbesondere bei komplexen "brown field"-Systemen (in denen Hunderttausende von Persontagen stecken) ist oft nur sehr schwer einzuschätzen welche Konsequenzen Veränderungen am System nach sich ziehen)