Schneller Überblick über den Projektstatus Projekte agil planen mit dem Burn-up-Chart
Schneller Überblick über den Projektstatus Projekte agil planen mit dem Burn-up-Chart
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:
- Mit der Beschreibung der Projektphasen und Meilensteine erfolgt eine erste Strukturierung des Vorhabens.
- 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.
- 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.
- Der nächste Schritt bildet die Erstellung des Kostenplans, mit dem die Gesamtkosten des Projekts, basierend auf den Ergebnissen der vorangegangenen Arbeiten, ermittelt werden.
- 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.
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.
Sofort weiterlesen und testen
Erster Monat kostenlos,
dann 24,95 € pro Monat
-
Know-how von über 1.000 Profis
-
Methoden für alle Aufgaben
-
Websessions mit Top-Expert:innen
Wolfram Müller (Speed4Projects.Net)
26.06.2013
Peter Scheiwiller
27.06.2013
Steffen Thols
29.06.2013
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
29.06.2013
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
22.07.2013
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
29.07.2013
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
projektmagazin 1 Monat kostenlos testen!
Das projektmagazin - unverzichtbares Nachschlagewerk und Inspirationsquelle für alle, die in Projekten arbeiten.