Schneller Überblick über den Projektstatus

Projekte agil planen mit dem Burn-up-Chart

Teil 1:
Traditionelle und agile Planung
In Scrum als dem bekanntesten Vertreter von agilem Vorgehen wird die Projektplanung in einem Burn-down-Chart visualisiert. Im ersten Teil der Artikelserie stellt Ihnen Steffen Thols nach einer Gegenüberstellung klassischer und agiler Projektplanung eine alternative Darstellungsform agiler Projektplanung – den Burn-up-Chart – vor. Und er erklärt, in welchem Kontext sich dieser besser einsetzen lässt.
Schneller Überblick über den Projektstatus

Projekte agil planen mit dem Burn-up-Chart

Teil 1:
Traditionelle und agile Planung
In Scrum als dem bekanntesten Vertreter von agilem Vorgehen wird die Projektplanung in einem Burn-down-Chart visualisiert. Im ersten Teil der Artikelserie stellt Ihnen Steffen Thols nach einer Gegenüberstellung klassischer und agiler Projektplanung eine alternative Darstellungsform agiler Projektplanung – den Burn-up-Chart – vor. Und er erklärt, in welchem Kontext sich dieser besser einsetzen lässt.

Ein wichtiges Merkmal von agil durchgeführten Projekten ist die iterative Entwicklung. Diese bietet die Möglichkeit, auf Änderungen schnell zu reagieren und notwendige Anpassungen zu einem frühen Zeitpunkt vorzunehmen. So vorteilhaft dieses Vorgehen in dieser Hinsicht ist, so anspruchsvoll macht dies die Planung des Projekts oder der Releases. Da es keinen vorausberechneten Projektplan als Netzdiagramm oder Gantt-Chart gibt, kann auch kein Soll-Ist-Vergleich vorgenommen werden, ob das Projekt im Plan ist. Stattdessen wird der Projektfortschritt aus den erreichten Ergebnissen der abgelaufenen Iterationen abgeleitet.

In Scrum als dem bekanntesten Vertreter von agilem Vorgehen wird für die Planung ein Burn-down-Chart angeboten. In ersten Teil der Artikelserie lernen Sie eine alternative Darstellungsform – den Burn-up-Chart – kennen und in welchem Kontext diese besser geeignet ist als der allgemein gebräuchliche Burn-down-Chart. Im zweiten Teil der Artikelserie erhalten Sie eine Vorlage für einen Burn-up-Chart in Form eines Excel-Spreadsheet. Anhand einer detaillierten Beschreibung und eines konkreten Beispiels erfahren Sie auch, wie Sie diese Vorlage anwenden, um einen Burn-up-Chart zu erstellen, der Ihren Projektanforderungen entspricht.

Traditionelle Projektplanung

Die Planung sog. "traditioneller" Projekte erfolgt häufig nach diesem Muster: Zunächst werden die Projektziele definiert. Dann werden das Projektumfeld und die Stakeholder analysiert. Daran schließt sich eine erste Risikoeinschätzung an und es werden Maßnahmen zur Verringerung der Risiken abgeleitet.

Nachdem eine für das Unternehmen passende Projektorganisation ausgewählt wurde, kommt es nun zur Planung des Projekts (Bild 1), die z.B. folgendermaßen abläuft:

  1. Mit der Beschreibung der Projektphasen und Meilensteine erfolgt eine erste Strukturierung des Vorhabens.
  2. Daran schließt sich die Erstellung des Projektstrukturplanes (PSP) an, der mit den beinhalteten Arbeitspaketen das zentrale Ordnungs- und Kommunikationselement im Projekt darstellt. In der Arbeitspaketbeschreibung sind wiederum die Aufgaben inklusive der Schätzung, also der Dauer für die einzelnen Aufgaben, enthalten. Die Schätzungen werden dabei häufig als Expertenschätzungen durchgeführt, d.h. wenige erfahrene Entwickler und/oder Architekten schätzen die Dauer der Arbeitspakete.
  3. Mit Hilfe der Schätzung können nun die Einsatzmittel inklusive einem Ressourcenabgleich geplant werden. Mit den Einsatzmitteln sind hier u.a. diejenigen Menschen gemeint, die das Projekt tatsächlich durchführen werden.
  4. Der nächste Schritt bildet die Erstellung des Kostenplans, mit dem die Gesamtkosten des Projekts, basierend auf den Ergebnissen der vorangegangenen Arbeiten, ermittelt werden.
  5. Die genaue zeitliche Darstellung der zu erledigenden Arbeiten und vorhandene Abhängigkeiten fließen dann in einen Netzplan oder vernetzten Balkenplan ein. Erst jetzt bekommt der Projektleiter die genaue Information, wie das Projekt zeitlich gesehen abgewickelt werden kann und ob dies im Einklang mit der groben Strukturierung im Phasen-/Meilensteinplan steht. Auch die Ermittlung des kritischen Pfades und die Pufferzeiten ergeben sich aus der Berechnung des Netzplans.

Bild 1: Traditionelle sequentielle Projektplanung.

Der Vorteil eines derartigen Vorgehens liegt darin, dass es das Projekt stark strukturiert und ungeübte Projektmitarbeiter ziemlich genaue Anweisungen haben, wie sie vorgehen sollten.

Ein Nachteil liegt darin, dass der Auftraggeber bei perfekter Durchführung des Plans genau das bekommen wird, was zu Beginn des Projektes vereinbart wurde, und nicht das, was er mittlerweile tatsächlich benötigt. Mittlerweile deshalb, weil gerade bei langlaufenden Projekten neue Erkenntnisse im Projektverlauf zu neuen Anforderungen führen können. Eine Änderung an Anforderungen kann hier aber nur durch Change Requests dargestellt werden, was zur Folge hat, dass alle damit zusammenhängenden Pläne angepasst werden müssen.

Des Weiteren führen meiner Erfahrung nach häufig nicht diejenigen Mitarbeiter die Planung durch, die später an der Umsetzung beteiligt sind. Die Folge davon kann sein, dass die Festlegungen, die erfahrene Entwickler und/oder Architekten vorgenommen haben, nicht eingehalten werden können, da die Umsetzung durch weniger erfahrene Entwickler erfolgt.

Die Tätigkeiten im Rahmen der Planung verteilen sich auf einen großen Arbeitsaufwand vor bzw. zu Beginn des Projekts. Im laufenden Projekt ist der Projektleiter dann hauptsächlich damit beschäftigt, den Fertigstellungsgrad (Ist-Zustand) abzufragen, mit dem geplanten Fortschritt (Soll-Zustand) zu vergleichen und ggf. Maßnahmen einzuleiten, falls die Budget- und Terminhochrechnungen, z.B. mit Hilfe einer Earned-Value-Analyse, eine Abweichung vom Plan ergeben.

Projektplanung mit einem Burn-down-Chart

Bei Scrum, dem bekanntesten Vertreter agiler Vorgehensweisen, erfolgt kein derartiges "Big Planning Upfront". Auch wenn Scrum dies nicht explizit vorschreibt, sollten natürlich die ersten Schritte einer Projektinitiierung, also die Definition der Projektziele, eine erste Umfeld- und Stakeholder-Analyse sowie eine Risikoeinschätzung inklusive Maßnahmen zur Verringerung der Risiken ebenso vorgenommen werden.

Die weitere Planung erstreckt sich jedoch nicht im Vorfeld für das gesamte Vorhaben, sondern stützt sich auf die realen Ergebnisse, die im Verlauf des Projekts erzielt werden, und leitet davon eine Hochrechnung für den weiteren Projektverlauf ab.

Bewertungen und Kommentare

(nur angemeldete Benutzer)

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
Gesamt
Bewertungen 9
Kommentare 6

Fortsetzungen des Fachartikels

Teil 2:
So geht's
Mit dem Burn-up-Chart hat Ihnen Steffen Thols im ersten Artikelteil eine alternative Darstellungsform für agile Projektplanung präsentiert. Im zweiten und abschließenden Artikelteil gibt er Ihnen eine Excel-Vorlage an die Hand, mit deren Hilfe Sie …

Alle Kommentare

Wolfram
Müller
Erst mal Danke auch für den Artikel - ich finde es gut, dass immer mehr darüber nachdenken, wie man die Vorteile von agilen Methoden mit den Anforderungen nach Projekten in Übereinstimmung bringt. Was mir fehlt und warum ich auch etwas verdutz bin ist, das der Planungsaspekt im Artikel untergeht. Das Werkzeug, das sie darstellen, schafft Transparenz im laufenden Projekt - fein, sehr gut. Das wird auch dazu führen, dass schneller über die richtigen Sachen gesprochen wird - auch sehr gut. Was mir fehlt ist das fixieren des richtigen Endtermins - wie finde ich diesen, wie verhandle ich diesen ohne die Agilität zu gefährden und trotz dem zuverlässig zu sein. Was ich nur verstärken kann ist, dass diese Art der Darstellung vor allem dem Product Owner hilft sein Entscheidungen bzgl. Backlog besser zu fällen.
Peter
Scheiwiller
Das eigentliche Thema verpasst. Die story points habe ich ja schon. Der Artikel zeigt lediglich auf, dass das Thema Potential hat weil nicht ganz verstanden.
Steffen
Thols
Hallo Hr. Müller,
die in dem Artikel beschriebene Darstellungsform stellt eine Alternative zu den Charts vor, die lt. ScrumAlliance für Projekte nach Scrum vorgeshehen sind.
Die Darstellung mit einem Burnup-Chart kann m.E. ein besseres Verständnis über den Projektverlauf bringen.
Im Regelfall gibt es eine Vielzahl von Abhängigkeiten und Einflüssen in einem Projekt oder innerhalb einer Produktentwicklung die immer wieder aktuell eingeplant und priorisiert werden müssen.
Wichtig ist an dieser Stelle, dass die Tätigkeit des Planens nie auhfört, da man sich ständig an neue Gegegenheiten anpassen muss. Deswegen auch die Nutzung empirischer Prozesse wie Scrum die in einem komplexen Umfeld notwendig sind.
Die Herausforderung ist ja eher, ob die Features, die innerhalb eines vorgegebenen Zeitraums entwickelt werden die richtigen sind.
Vielleicht können Sie genauer darlegen, was Sie in diesem Kontext mit dem richtigen Endtermin meinen?
Viele Grüße
Steffen Thols
Steffen
Thols
Hallo Hr. Scheiwiller,
können Sie noch genauer darlegen, inwiefern das eigentliche Thema verpasst sei? Der Artikel beschreibt eine alternative Darstellung des Projetkfortschrittes in agilen Projekten (bzw. Produktentwicklungen). Die Nutzung von Story Points ist hier auch kein Muss. Auch die Verwendung von Personentagen ist prinzipiell möglich, wenn sich alle Beteiligten über die Konsequenzen deren Nutzung bewusst sind. Die Darstellung als Burnup-Chart macht da keine Vorgaben.
Viele Grüße
Steffen Thols
Daniel
Faensen
Ein erstmal interessanter Ansatz, aber so wirklich neu ist er nicht. Was hier als Burn-up-Chart bezeichnet wird, heißt anderswo Cumulative Flow.

Ich muss auch sagen, dass ich Probleme habe mit der Annahme, dass das Produkt fertiggestellt ist, wenn das Product Backlog abgearbeitet ist. Hier habe ich ein anderes Verständnis von Scrum. Das Product Backlog kann jede Menge Anforderungen enthalten, die nur eine geringe Priorität haben und unter Umständen niemals umgesetzt werden, durchaus gewollt in agilen Projekten. Der Schnittpunkt des Trends mit der Gesamtsumme der Story Points ist in diesem Fall (meines Erachtens der Regelfall) bedeutungslos.
Steffen
Thols
Hallo Hr. Faensen,

Sie haben Recht, tatsächlich ist dieser Ansatz nicht neu und sollte es auch nicht sein. Die in dem Artikel beschriebene Darstellung ist eine alternative Darstellung des bekannteren Burndown-Charts. In meinen Projekten verwende ich gerne diese Art der Darstellung, da eine Änderung der Anforderungen und die Konsequenzen daraus besser ablesbar sind.

Widersprechen muss ich Ihnen allerdings, dass es sich bei dem Burnup-Chart um ein Cumulative Flow Diagramm handelt! Aus einem Cumulative Flow Diagramm können pro Statuswert die Zeitdauern von Workitems abgelesen werden. (Bsp.: Wie lange sind User Stories im Status „in Arbeit“?) Bei dem Burnup-Chart gibt es lediglich den Statuswert „offen“ und „fertig“ pro Backlog Item.

Anzumerken ist auch, dass das in dem Artikel beschriebene Chart lediglich ein Werkzeug ist! Wir müssen bei der Verwendung hier immer den jeweiligen Kontext unterscheiden. Häufig sind in der Durchführung von Projekten oder Weiterentwicklung von Produkten die Termine festgelegt. D.h. für den Product Owner, dass er natürlich bei der Priorisierung der umzusetzenden Backlog Items darauf achtet, dass die für das Unternehmen sinnvollsten Backlog Items umgesetzt werden. Sinnvoll heißt hier beispielsweise der anzunehmende größte „Return on Invest“ oder auch notwendige Refactoring-Maßnahmen, damit das System zukünftig gut wartbar bleibt. Das in dem Artikel beschriebene Chart liefert dabei Hilfestellung um zu erkennen und zu entscheiden, wie viele Backlog Items zu einem vorgegebenen Termin fertig werden können.

Das sich die Backlog Items auf der Strecke noch ändern können ist in agil durchgeführten Projekten/Produktentwicklungen natürlich gegeben und wir durch das Burnup-Chart planerisch unterstützt.

Wenn der Funktionsumfang festgelegt ist stellt sich natürlich die spannende Frage, wie und v.a. wie genau dieser zu Beginn des Projektes definiert wird. Stichwort: Vermeidung von Big Design Upfront. Auch hier kann das beschriebene Chart wertvolle Unterstützung darin bieten, dass nach Erstellung eines initialen Product Backlog und dem Ablauf der ersten Sprints anhand der Velocity abgelesen werden kann, wie lange die Entwicklung voraussichtlich dauern wird. Hier hat dann der Product Owner u.a. durch die Priorisierung der Backlog Items die Möglichkeit, die wichtigsten Funktionen so früh als möglich umsetzen zu lassen um ein entsprechendes Risikomanagement durchzuführen.

Zitat aus dem Artikel: „Während in herkömmlichen Projekten ein festgelegter Plan verfolgt wird und inhaltliche Änderungen nur mit einem Change Request durchgeführt werden können, steht in agilen Projekten das Planen, also das regelmäßige Austauschen über den Projektstand und ggf. Ableiten von Maßnahmen zur Erreichung der Bedürfnisse des Auftraggebers im Vordergrund.“

Bei dem Verständnis von Scrum sind wir hier m.E. beieinander. Es liegt nur in der Nutzung dieses Werkzeugs. So kann der Product Owner beispielsweise alle für ihn wichtigen Backlog Items mit einem Flag versehen und durch Excel derartig auswerten lassen dass er die prognostizierte Fertigstellung dieser Items aus der Grafik ablesen kann. D.h. der Schnittpunkt des Trends wäre in diesem Falle nicht die Gesamtsumme der Story Points des Backlogs sondern die Gesamtsumme der Story Points der am höchsten priorisierten Storys. Etwas Excel-Kenntnisse vorausgesetzt sind der Phantasie zur Anpassung dieser Vorlage natürlich keine Grenzen gesetzt!

Viele Grüße
Steffen Thols
Alle anzeigen