2 Agiles Projektmanagement in der Softwareentwicklung

Transkript

1 2 Agiles Projektmanagement in der Softwareentwicklung Im folgenden Kapitel werden einleitend die zentralen Aspekte des agilen Projektmanagements erläutert (siehe Abschnitt 2.1). Ferner wird der fokussierte agile Ansatz Scrum (siehe Abschnitt 2.2) beschrieben, um ein theoretisches Fundament zu schaffen. 2.1 Einleitung Um den Begriff des Projektmanagements herleiten zu können, gilt es zunächst, den Begriff Projekt zu definieren. Das Project Management Institute (PMI) (PMI 2008, S. 5) definiert ein Projekt als ein zeitliches Unterfangen, um ein einzigartiges Produkt, eine individuelle Dienstleistung oder ein Ergebnis zu entwickeln. Der Begriff Projektmanagement ist dem traditionellen Projektmanagementverständnis des PMI (2008, S. 6) zufolge die Anwendung von Wissen, Können, Werkzeugen und Techniken auf Projektaktivitäten, um Projektanforderungen zu erfüllen. Um eine Abgrenzung zum agilen Projektmanagement vorzunehmen, gilt es zunächst, den Begriff der Agilität und eines agilen Projektes zu definieren. Agilität ist die Fähigkeit, auf Veränderungen in einer turbulenten Umwelt, in der sich Unternehmen befinden, zu reagieren (Highsmith 2002, S. XXIII). Ferner dient sie dazu, einen Nutzen aus diesem Vorsprung zu ziehen und den Konkurrenten durch das Auslösen von Veränderungen stets einen Schritt voraus zu sein (ebd.). Ursprünglich wurde statt agil auch der Begriff leichtgewichtig (engl.: lightweight ) verwendet. Ein agiles Projekt ist dabei ein Vorhaben, das durch seine Agilität in der zuvor erwähnten turbulenten Umwelt den Anforderungen gerecht wird, bspw. durch regelmäßiges Feedback (Cockburn 2006, S. 274). Dabei werden agile Projekte nach den Grundsätzen des Agilen Manifests geplant und durchgeführt. Das Agile Manifest 6 wurde 2001 von den Autoren verschiedener Ansätze der agilen Softwareentwicklung unterzeichnet, um eine allgemeine Definition der Agilität zu bestimmen (Highsmith 2002, S. xvii). Es beruht auf vier Werten, auf die sich alle Unterzeichner geeinigt haben (Beedle et al. 2001) sowie auf zwölf 6 Beedle et al. (2001). J. Brandstäter, Agile IT-Projekte erfolgreich gestalten, DOI / _2, Springer Fachmedien Wiesbaden 2013

2 10 2 Agiles Projektmanagement in der Softwareentwicklung Prinzipien, die zusammengenommen als Leitsatz für agile Arbeit gelten. Zur Vertiefung der agilen Werte und Prinzipien wird auf weiterführende Literatur von COCKBURN (2006a, S ) verwiesen. Ferner existieren agile Prozesse bzw. Vorgehensweisen, nach denen agile Projekte ablaufen. Dabei lassen sich Prozesse allgemein unterscheiden in empirische und theoretische bzw. definierte (Highsmith 2002, S. 293). Agile Prozesse sind empirisch, d. h., sie genügen von vornherein nicht dem Anspruch, gut verstanden zu sein, um automatisiert durchgeführt zu werden. Empirische Prozesse, wie agile Prozesse es sind, benötigen Kontrolle und Intervention (ebd.). Prozessmodelle bzw. Vorgehensmodelle definieren, welche Aktivitäten in welcher Reihenfolge von welchen Personen erledigt werden und welche Ergebnisse (auch Artefakte genannt) dabei entstehen (Balzert 2001, S. 54). Ein Prozess beschreibt, wie verschiedene Aktivitäten verbunden sind, wobei eine Aktivität darlegt, wie etwas ausgeführt werden sollte (Highsmith 2002, S. 151). Als Beispiel für eine Aktivität werden hierfür planen, programmieren und testen genannt (ebd.). Ferner lassen sich agile Techniken nennen. Diese sind definiert als spezifische Prozeduren, die Personen nutzen, um eine Aufgabe zu erledigen (ebd.). Als Beispiel für agile Prozesse sind Crystal, extreme Programming (XP) und Scrum zu nennen. 2.2 Scrum Im Folgenden wird das Scrum-Framework auf Basis von SCHWABER (1995), SCHWABER UND BEEDLE (2002), SCHWABER (2007) und SUTHERLAND UND SCHWABER (2011) detailliert betrachtet. Ziel ist es, ein Fundament für die spätere Analyse des Risikomanagements im Scrum-Framework zu schaffen. Dazu werden nach einer kurzen Einleitung (Teil 2.2.1) die drei Scrum-Prinzipien (Sichtbarkeit, Inspektion und Anpassung) in Abschnitt erläutert, gefolgt von den fünf Scrum-Werten (Verpflichtung, Fokus, Offenheit, Respekt und Mut) in Abschnitt Ferner werden in Abschnitt die drei Scrum-Rollen (Product- Owner, Scrum-Master und Scrum-Team) und deren Verantwortlichkeiten definiert. Im Abschluss wird in Abschnitt das gesamte Framework im Detail erläutert Einleitung Die Ursprünge von Scrum sind auf die japanische Konsumgüterbranche zurückzuführen. Dort wurde Scrum 1986 von TAKEUCHI UND NONAKA (1986) als eine neue Methode zur Produktentwicklung vorgestellt (Takeuchi und Nonaka 1986;

3 2.2 Scrum 11 Schwaber und Beedle 2002, S. 1). Aus der Prozesssteuerung leitet SCHWABER (1995) das heutige Scrum für die Systementwicklung her. In seiner derzeitigen Form fand Scrum 1995 erstmals Erwähnung im Rahmen eines Papers ( Scrum development process ) für die OOPSLA-Konferenz 7 von SCHWABER (1995). Scrum ist laut einer Studie von 2011 mit 52 % der am weitesten verbreitete agile Prozess (Versionone 2011, S. 4). Dieser stellt ein Framework zur nachhaltigen Entwicklung komplexer Produkte dar, mit dem Schwerpunkt Projektmanagement (Highsmith 2002, S. 242). Das Framework bietet ein universelles Projektmanagementsystem, das ein Produkt ausliefert, während es mit den Veränderungen wächst und sich an unvorhersehbare Ereignisse anpasst (Schwaber und Beedle 2002, Vorwort IX). Trotz der Branchenunabhängigkeit wird es häufig der Softwareentwicklung zugeschrieben (Highsmith 2002, S. 242), weshalb es auch als agiler Softwareentwicklungsprozess bekannt ist (bspw. Fitsilis 2008, S. 380). Scrum repräsentiert einen neuen Weg der Softwareentwicklung. Durch den Freiraum, den das Entwicklerteam innerhalb einer Entwicklungsiteration bekommt, entsteht ein neuer Weg, mit dem Management und dem Aufsichtsrat zusammenzuarbeiten (Schwaber und Beedle 2002, S. 82). Es bietet dem Team genug Freiraum, selbstständig und adaptiv auf Veränderungen in der Umwelt zu reagieren (Schwaber 1995, S. 8). Innerhalb dieses Frameworks sind verschiedene Prozesse und Techniken einsetzbar (Sutherland und Schwaber 2011, S. 3) Scrum-Prinzipien Scrum stellt einen empirischen Prozess dar, angelehnt an die industrielle Prozesssteuerung. Diese kann entweder theoretisch bzw. definiert oder empirisch sein (Schwaber 1995, S. 1-2). Dabei besteht jede Implementierung einer empirischen Prozesssteuerung aus drei Säulen: Sichtbarkeit (engl.: transparancy ), Inspektion (engl.: inspection ) und Anpassung (engl.: adaption ), was auch als Fundament für den gesamten Entwicklungsprozess verstanden wird (Schwaber 2007, S. 3). Die erste Säule bezieht sich auf die Sichtbarkeit eines Prozesses für denjenigen, der den Prozess überwacht. Zur Transparenz und Überprüfbarkeit der Arbeit existieren Scrum-Artefakte, die ein Arbeitsergebnis darstellen (Sutherland und Schwaber 2011, S. 12). Als Beispiel ist das Product-Backlog (PB) oder das Produktinkrement zu nennen. Ein PB beschreibt eine Liste mit Anforderungen, die es innerhalb eines fixen Zeitraums zu erbringen gilt, an deren Ende ein Produkt- 7 Konferenz für Object Oriented Programming, Systems, Languages and Applications (OOPSLA).

4 12 2 Agiles Projektmanagement in der Softwareentwicklung inkrement steht (Schwaber 2007, S. 6). Ein Produktinkrement beschreibt dabei die Summe aller fertiggestellten Product-Backlog-Einträge. Fertiggestellt, bzw. done beschreibt den Zustand eines auslieferbaren Produktinkrements, das den Eigenschaften der vom Team definierten Definition of Done entspricht (Schwaber 2007, S. 3-4; Sutherland und Schwaber 2011, S. 15). Die zweite Säule bezieht sich auf inakzeptable Abweichungen im Prozess, die aufgedeckt werden müssen. Dieses findet auf täglicher Basis statt. Während der Daily Scrum-Meetings inspiziert und misst das Management zusammen mit dem Team den Prozess, um festzustellen, ob der Fortschritt und das Ergebnis den Anforderungen entsprechen (Schwaber 2007, S. 4; Schwaber und Beedle 2002, S. 102). Befindet sich ein Aspekt der Entwicklung außerhalb einer nicht mehr tolerierbaren Grenze, wird der Prozess angepasst. Die Anpassung wird durch die dritte Säule beschrieben (Schwaber 2007, S. 4) Scrum-Werte Neben den drei elementaren Säulen beruht Scrum auf einer Reihe von fundamentalen Werten, auf denen die Scrum-Praktiken aufbauen und denen die Projektbeteiligten folgen sollen (Schwaber und Beedle 2002, S ). Dazu zählt Verpflichtung (engl.: commitment ), Fokus, (engl.: focus ), Offenheit (engl.: openness ), Respekt (engl.: respect ) und Mut (engl.: courage ). Als essenziell wird der Wille genannt, sich selbst zu etwas zu verpflichten, um ein Ziel zu erreichen. Scrum hat dazu einige Praktiken wie bspw. die Selbstorganisation, eingeführt. Dabei kann das Team selbst entscheiden, wie es die Arbeit, die es angenommen und der es zugestimmt hat, erledigt und so das Ziel erreicht (ebd., S ). Als zweiter Wert wird angeführt, den Fokus seiner Mühe und Fähigkeiten auf die Arbeit zu legen, zu der sich der Projektbeteiligte verpflichtet hat. Nur so können die Arbeiten und Probleme effektiv gelöst werden (ebd., S ). Offenheit wird als weiterer wichtiger Wert von Scrum angeführt. Dabei geht es um Transparenz. Es wird gefordert, all das offenzulegen, was in Verbindung mit dem Projekt steht (ebd., S. 151). Als Beispiel ist das Daily Scrum-Meeting anzuführen. Dieses Meeting ist ein kontinuierlich stattfindendes Treffen innerhalb der Entwicklung, an dem das gesamte Entwicklerteam teilnimmt, um den Fortschritt der Entwicklung zu diskutieren (ebd., S. 9). Der vierte Wert erkennt die Individualität jeder Person an und respektiert die Stärken und Schwächen. Sollte es in Scrum dazu kommen, dass das Ziel wegen fehlender Fähigkeiten eines Individuums nicht erreicht wird, so bietet Scrum die

5 2.2 Scrum 13 Möglichkeit, diese Aufgaben zu priorisieren und offenzulegen, was getan werden muss, um geeignete Maßnahmen zu entwickeln (ebd., S ). Scrum erhebt den Anspruch, dass jeder den Mut haben soll, zu etwas zuzustimmen, offen zu sein und Respekt zu erwarten. Mut zeichnet sich dabei auf zwei Arten aus: zum einen, indem die Umgebung alle Scrum-Werte unterstützt, und zum anderen indem zugelassen wird, dass die Meinung eines Einzelnen von Bedeutung ist (ebd., S ) Scrum-Rollen In Scrum existieren drei Rollen: der Product-Owner (PO), das Entwicklerteam und der Scrum-Master (SM). Dies bedeutet auch, dass alle Managementverantwortlichkeiten in einem Projekt zwischen diesen drei Rollen aufgeteilt werden (Schwaber 2007, S. 7). Somit entfällt die klassische Rolle des Projektmanagers. Der Product-Owner ist verantwortlich für die Maximierung des Wertbeitrags des Produktes und die Arbeit des Entwicklerteams. Er ist als einzige Person für den Einsatz des Product-Backlog verantwortlich und hat sicherzustellen, dass nützliche Funktionen hoch priorisiert werden und ständig aktualisiert werden. Für den Erfolg von Scrum ist es essenziell, dass die Entscheidungen des PO von der gesamten Organisation respektiert werden (Sutherland und Schwaber 2011, S. 5-6; Schwaber 2007, S. 7). Der Scrum-Master ist dafür verantwortlich, dass Scrum erfolgreich angewendet wird, indem die Scrum-Werte, die gültigen Scrum-Praktiken und Regeln verstanden und angewendet werden (Sutherland und Schwaber 2011, S. 6; Schwaber und Beedle 2002, S. 31). Damit das Entwicklerteam das bestmögliche Ergebnis erzielt, gehört neben dem Vermitteln von Scrum-Inhalten zu den Aufgaben des Scrum-Masters, die verschiedenen Meetings zu moderieren und Hindernisse im Entwicklungsprozess zu beseitigen (Schwaber 2007, S. 7; Schwaber und Beedle 2002, S ). Zu den weiteren Verantwortlichkeiten des SM zählt die Repräsentation des Entwicklerteams nach außen. Der SM stellt die treibende Kraft in Scrum dar (Schwaber und Beedle 2002, S. 31). Für die Entwicklung von Funktionalitäten zeichnet sich das Entwicklerteam, auch Scrum-Team genannt, verantwortlich (Schwaber 2007, S. 7). Ziel ist die Erstellung eines auslieferbaren Produktinkrements zum Ende eines Sprints (Sutherland und Schwaber 2011, S. 6). Ein Sprint stellt einen fixen Zeitraum dar, in dem das Team die Entwicklung fokussiert (Schwaber und Beedle 2002, S. 50). Das Entwicklerteam ist ein möglichst interdisziplinäres, aus Experten zusammengesetztes Team (Schwaber und Beedle 2002, S. 37; Sutherland und Schwaber 2011, S. 6). Es besteht im Idealfall aus drei bis neun Mitgliedern und ist

6 14 2 Agiles Projektmanagement in der Softwareentwicklung damit gerade groß genug, um die Wechselwirkungen zu nutzen, und klein genug, um den Koordinationsaufwand gering zu halten (Sutherland und Schwaber 2011, S. 6). Die Gruppe ist dazu ermächtigt, die Arbeit selbst zu verwalten, wobei sich keine teamexterne Person einmischen darf (Schwaber und Beedle 2002, S. 37). Daraus ergeben sich Synergieeffekte, wie bspw. gesteigerte Effizienz und Effektivität des gesamten Teams (Sutherland und Schwaber 2011, S. 6) Scrum-Framework Das Scrum-Framework beschreibt den Rahmen bzw. den Kern von Scrum und besteht aus mehreren Rollen (siehe Abschnitt 2.2.4), Artefakten und Regeln (Sutherland und Schwaber 2011, S. 3). Bild 2.1 stellt das Framework schematisch dar. Als Artefakte werden Arbeitsergebnisse bezeichnet, die der Überprüfbarkeit der Arbeit dienen (ebd., S. 12). Der untere Kreis repräsentiert die Sprints. Diese Sprints finden nacheinander, d. h. iterativ statt und haben als Ergebnis ein Produktinkrement (ebd., S. 15). Jeder Sprint basiert dabei auf dem Sprint- Backlog (SB), der eine Teilmenge des Product-Backlogs darstellt (Schwaber 2007, S. 6). Der obere Zyklus beschreibt die tägliche Inspektion, während der sich das Team trifft, um den Fortschritt zu besprechen. Dieses Treffen wird auch Stand-up-Meeting oder Daily Scrum-Meeting genannt (Schwaber und Beedle 2002, S. 40). Daily Scrum- Meeting Sprint-Review & - Retrospektive Product-Backlog Sprint- Backlog 2-4 Wochen Sprint 1-n Potenziell auslieferbares Produktinkrement Task Sprint- Planung Bild 2.1: Scrum-Prozess (Quelle: in Anlehnung an Cohn (2005)) Bild 2.2 zeigt das gesamte Framework. Zu erkennen sind drei Phasen: Pre-Game, Game und Post-Game (Schwaber 1995, S. 11). Diese Phasen sind auch als Pre-

7 2.2 Scrum 15 Sprint, Sprint und Post-Sprint bekannt (Highsmith 2002, S. 243) und werden im Folgenden detailliert vorgestellt. Pre-Game-Phase Game-Entwicklungsphase Post-Game-Phase Vision Product- Backlog Daily Scrum- Meeting Sprint- Backlog Sprint Review & -Retrospektive Potenziell auslieferbares Produktinkrement Planungsprozess High-Level- Entwurf/Architektur 2-4 Wochen Sprint 1-n Finales Produkt Bild 2.2: Scrum-Prozess (Quelle: in Anlehnung an ABRAHAMSSON ET AL. (2002, S. 28)) Ein Scrum-Projekt, und damit die Pre-Game-Phase beginnt mit der Definition der Vision (Schwaber 2007, S. 8; Pichler 2010, S ). Eine Vision hilft dabei, das Produkt zu verstehen. Es beschreibt das Erzeugnis auf einer abstrakten, grobkörnigen Ebene. Dabei werden eine Reihe von Analysen durchgeführt, um das Produkt zu verstehen, bspw. Marktpotenzial- und Wettbewerbsanalysen (Pichler 2010, S ). Diese Vision sollten alle Teammitglieder, das Management, der Kunde und weitere Stakeholder verinnerlichen (Pichler 2010, S ). Aus der Vision ergibt sich der Planungsprozess. Dabei werden eine Konzeptualisierung und Analyse bzw. Definition neuer Releases beschrieben (Schwaber 1995, S. 12). Ferner gilt es, in einer Architekturphase Anpassungen der Systemarchitektur sowie einen groben Entwurf (engl.: high level design ) vorzustellen (ebd.). Nachdem auf abstrakter Ebene das Ziel des Produktes definiert wurde, gilt es, das PB mit allen nicht-funktionalen und funktionalen Anforderungen aufzustellen (Schwaber 1995, S. 13; Schwaber und Beedle 2002, S. 7; Schwaber und Beedle 2002, S. 32). Das PB stellt das Ergebnis der Pre-Game-Phase dar. In Tabelle 2.1 wird beispielhaft ein PB gezeigt. Allgemein enthält es Anforderungen, die sich für das gesamte Produkt identifizieren lassen (Schwaber und Beedle 2002, S. 72). Diese Tabelle enthält beispielhaft eine priorisierte Liste mit Anfor-

8 16 2 Agiles Projektmanagement in der Softwareentwicklung derungen und entsprechenden Berechtigungen für eine Kalenderapplikation. Der Ablauf der Anforderungserhebung stellt einen sich kontinuierlich anpassenden Prozess dar, dessen Ergebnis im Product-Backlog festgehalten wird (Schwaber und Beedle 2002, S. 33; Pichler 2010, S. 51). Der PO ist dabei für diese Liste verantwortlich und muss die Anforderungen entsprechend priorisieren (siehe 2.2.4), wenngleich diese von allen, d. h. auch vom Entwicklerteam, Scrum- Master, Product-Owner und den Stakeholdern, befüllt werden darf (Pichler 2010, S. 47; Schwaber und Beedle 2002, S ; Highsmith 2002, S. 244). Tabelle 2.1: Beispielhafter Product-Backlog (Quelle: in Anlehnung an PICHLER (2008, S. 29)) Priorität Thema Beschreibung Akzeptanzkriterien Aufwand 1 Kalender Als Basisanwender möchte Teste das Eingeben 1 ich eine Besprechung anlegen. ungültiger Werte, z. B. Endzeit liegt vor Startzeit. 2 Kalender Als Basisanwender möchte Teste, dass dieselbe 3 ich eine Besprechung stornieren. Besprechung nicht zweimal gelöscht werden kann. 3 Kalender Als Basisanwender möchte ich eine Besprechung ändern. Teste, ob die Änderungen persistiert wurden. Aus dem Product-Backlog ergeben sich zwei weitere Listen, der Release Backlog und der Sprint-Backlog (Schwaber und Beedle 2002, S. 71; Highsmith 2002, S. 244). Nachdem die Anforderungen des Produktes bestimmt worden sind, ist dasselbe auf Release-Ebene im Release-Backlog erforderlich. Darin wird definiert, welche Anforderungen aus dem Product-Backlog in welchem Release veröffentlich werden. Das Release-Backlog gilt es analog zum Product-Backlog zu priorisieren (Schwaber und Beedle 2002, S. 71; Pichler 2010, S. 88). Nachdem die Anforderungen definiert sind, folgt die Entwicklung. Diese Phase wird auch als Game oder Sprint bezeichnet. Die Sprint-Phase ist ein empirischer Prozess, der eine Reihe von unkontrollierten und nicht gesteuerten Prozessen enthält (Schwaber 1995, S. 10). Dazu zählt eine zu Beginn stattfindende Sprint-Planung, die täglichen Daily Scrum-Meetings und die zum Sprint- Abschluss stattfindenden Meetings, der Sprint-Review und die Sprint- 2

9 2.2 Scrum 17 Retrospektive (Schwaber und Beedle 2002, S. 7-10; Fitsilis 2008, S. 380). Ein Sprint stellt ein Zeitfenster dar, in dem das Team für einen fixen Zeitraum (engl.: time-boxed ) Entwicklungsaktivitäten durchführt (Schwaber 1995, S. 14; Schwaber und Beedle 2002, S. 50; Schwaber 2007, S. 8). Die Sprint-Länge sollte maximal 30 Tage dauern und am Ende ein fertiges, funktionsfähiges Produktinkrement als Resultat haben (Sutherland und Schwaber 2011, S. 8). Die Sprint- bzw. Game-Phase beginnt mit einer Sprint-Planungssitzung. Diese besteht aus zwei Meetings (Sutherland und Schwaber 2011, S. 9-10). Zunächst definieren Nutzer, PO und Entwicklerteam, welche Funktionen aus dem Product- Backlog im kommenden Sprint entwickelt werden sollen (Schwaber und Beedle 2002, S. 71; Sutherland und Schwaber 2011, S. 9). Das Entwicklerteam schätzt im Anschluss an das erste Meeting, welche Arbeit erledigt werden muss, und legt fest, was es bereit ist zu erledigen, um das Sprint-Ziel zu erreichen (Schwaber und Beedle 2002, S. 47; Sutherland und Schwaber 2011 S. 9; Highsmith 2002, S. 244). Daraus ergibt sich der Sprint-Backlog. Der Sprint-Backlog zeigt eine Liste mit Aufgaben, die notwendig sind, um den Product-Backlog in funktionsfähige Software umzusetzen (Schwaber und Beedle 2002, S. 49). Zeitlich ist das Meeting bei einem 30-Tage-Sprint auf 8 Stunden beschränkt und wird bei kürzeren Sprints proportional angepasst (Sutherland und Schwaber 2011, S. 9). Nachdem das Product-Backlog definiert, die Features beschrieben und im Rahmen der Sprint-Planung der PB für das SB verfeinert wurden, beginnt die eigentliche Entwicklung. Dieser Entwicklungs- Sprint wird als Mikrozyklus bezeichnet (Pichler 2008, S. 122; Oestereich 2008, S. 20) und stellt die elementaren Entwicklungsaktivitäten dar. Bild 2.3 skizziert einen solchen Mikrozyklus. Dieser wird je Zyklus einmal durchlaufen und besteht bspw. aus der Definition der Anforderungen, der Konzeption der Lösung, dem Testen und der Implementierung (Oestereich 2008, S. 20). Dies entspricht dem traditionellen Vorgehen und wird innerhalb einer einzigen Iteration abgedeckt (Sliger und Broderick 2008, S. 29). Während des Entwicklungszyklus findet täglich ein Daily Scrum-Meeting statt. Dieses dient dazu, den Fortschritt des Teams aufzuzeigen und das weitere Vorgehen sowie identifizierte Hindernisse (engl.: impediments ) anzusprechen (Schwaber und Beedle 2002, S. 9; Schwaber und Beedle 2002, S. 40; Pichler 2010, S. 100). Für die Beseitigung dieser Hürden ist der SM verantwortlich (Schwaber und Beedle 2002, S. 32).

10 18 2 Agiles Projektmanagement in der Softwareentwicklung Bild 2.3: Entwicklungsmikrozyklus im Sprint (Quelle: in Anlehnung an OESTEREICH (2008, S. 20)) Zur Fortschrittskontrolle existiert ein Burndown-Diagramm. Dies zeigt den offenen Arbeitsaufwand über einen definierten Zeitraum in Korrelation mit dem Fortschritt des Projektteams (Schwaber 2007, S. 12). Bild 2.4 illustriert ein solches Diagramm. Es ist zu erwähnen, dass verschiedene Varianten des Burndown- Diagramms existieren. Andere Darstellungen stellen bspw. die abgearbeiteten Backlog-Einträge im Verlauf eines Sprints dar. In Bild 2.4 ist zu erkennen, dass die ursprüngliche Arbeit im Laufe der Zeit abgearbeitet wird. Im Idealfall stellt sich ein linearer Verlauf dar (idealtypischer Verlauf), der tatsächliche, typische Verlauf ist daneben skizziert. Zur Überprüfung der bereits geleisteten Arbeit bietet sich hingegen ein Backlog-Graph an (Schwaber und Beedle 2002, S. 74), bzw. auf Sprint-Ebene Sprint-Backlog-Graph genannt (Schwaber 2007, S. 72). Beide Diagramme verdeutlichen den Fortschritt im Sprint-Verlauf und zeigen an, wie viel Arbeit verbleibt. Der entstandene Verlauf gleicht einem Muster, das die Sprint-Signatur des Entwicklerteams beschreibt (Schwaber und Beedle 2002, S. 78). In diesem Zusammenhang ist das Velocity als weitere Maßzahl zu nennen. Damit wird die Entwicklungsgeschwindigkeit eines Teams bezeichnet (ebd., S. 32), d. h. der Arbeitsaufwand, den ein Team während eines Sprints abarbeiten kann.

11