Metriken für agile Projekte Jörg Brüggenkamp, Peter Preuss, Tobias Renk Für eilige Leser | Mithilfe der richtigen Steuerungsgrößen kann man nicht nur den Fortschritt agiler Projekte messen, sondern auch das Projektteam bei der Risikominimierung und der Identifizierung möglicher Verbesserungspotenziale effektiv unterstützen. In diesem Beitrag wird gezeigt, welche Metriken sich hierfür besonders eignen und wie man diese aussagekräftig auf einem Management-Dashboard visualisieren kann. Schlagwörter | Agiles Projektmanagement, Fortschrittskontrolle, agile Metriken, kombinierte Metriken Vorspann In einer perfekten agilen Umgebung wird ein Produkt von einem oder mehreren kleinen Teams für eine klar definierte Kundengruppe erstellt, die agilen Kontroll- und Steuermechanismen greifen, jeder Sprint liefert einen nachprüfbaren Wert und es genügen wenige Diagramme mit einfachen Steuerungsgrößen, um den Projektfortschritt zu messen. In großen Organisationen sieht es aber leider oft anders aus. Dort werden komplexe, aus vielen Komponenten bestehende Produkte von großen Projektteams entwickelt, die über mehrere Länder verteilt sind und mit unterschiedlichen externen Lieferanten zusammenarbeiten. Kunden sind in den meisten Fällen mehrere unternehmensinterne Abteilungen mit konkurrierenden Anforderungen und Prioritätsvorstellungen. Der agile Reifegrad ist in solchen Unternehmen eher gering. Daher fehlt es oft an einer einheitlichen Vision und der entsprechenden Strategie. Die Projektteams arbeiten in „Silos“ mit verteilten Product Backlogs und die Fortschrittsmessung basiert höchstens auf wenig aussagekräftigen Standard-Metriken wie einem simplen Sprint-Burndown-Chart. In komplexen Projekten kann man aus einem solchen Diagramm aber in den seltensten Fällen den wirklichen Projektfortschritt ablesen oder einen Handlungsbedarf ableiten. Risiken können dann nicht frühzeitig erkannt und geeignete Gegenmaßnahmen erst spät eingeleitet werden. Metriken werden häufig in wertlosen „Show- oder Ego-Dashboards“ visualisiert, die nicht an den Zielgruppen ausgerichtet sind. Dabei gibt es aufgrund der iterativen Vorgehensweise in agilen Projekten hilfreiche Metriken, die mit relativ geringem Aufwand so auf Dashboards dargestellt werden können, dass sie einen wesentlichen Beitrag zur Fortschrittsmessung und zur Risikoanalyse leisten. Grundlagen zu Metriken im agilen Umfeld Relevante Zielgruppen und deren Ziele identifizieren Metriken sollten niemals um ihrer selbst willen erstellt werden. Stattdessen müssen sie immer an den Zielgruppen und deren Informationsbedürfnis ausgerichtet sein, damit daraus Maßnahmen abgeleitet werden können, die dem Team bei der Ausführung ihrer Arbeit helfen und damit letztendlich zur Wertsteigerung des Produkts beitragen. Nachdem die relevanten Stakeholder identifiziert wurden, kann man z. B. in kurzen Interviews ermitteln, welche Ziele diese mit dem Projekt verfolgen und welche Fragestellungen während des Projektverlaufs anhand der Metriken beantwortet werden sollen. Bei größeren inhaltlichen Überschneidungen kann für verschiedene Zielgruppen ein gemeinsames Dashboard verwendet werden. Zielformulierungen wie „ Es sollen mehr User-Stories pro Sprint geliefert werden “ mit dem Unterziel „ Vergleich der Anzahl von geplanten und gelieferten User-Stories in einem Sprint “ sind nicht sinnvoll. Insgesamt ist die Frage nach der Anzahl der gelieferten User-Stories in einem Sprint an sich fragwürdig, sie kann je nach Aufwand oder Abhängigkeiten von Sprint zu Sprint sehr stark variieren. Bei dieser Formulierung bleibt auch unklar, welche Maßnahmen bei Zielabweichungen zu ergreifen sind. Eine bessere Zielbeschreibung könnte sich z. B. an einer sehr vereinfachten Form des Goal-Question-Metric-Modells Wissen Metriken für agile Projekte DOI 10.2357/ PM-2020-0072 31. Jahrgang · 04/ 2020 53 PROJEKTMANAGEMENT AKTUELL · 31. Jahrgang · 04/ 2020 DOI 10.2357/ PM-2020-0072 14_renk_brueggenkamp_preuss.indd 53 14_renk_brueggenkamp_preuss.indd 53 14.08.2020 16: 26: 25 14.08.2020 16: 26: 25 (GQM) anlehnen. Die Ziele werden hierbei aus folgenden Fragestellungen abgeleitet: Was (z. B. Prozess, Produkt, Modul) ist zu welchem Zweck (z. B. Optimierung, Überwachung, Planung) mit welchem Fokus (z. B. Performance, Skalierbarkeit, Qualität, Time-to-Market) aus welcher Sicht (z. B. Product Owner, Entwickler, Management) und in welchem Kontext (z. B. Projekt, Team, Lieferant) zu analysieren? Nachdem die Ziele formuliert wurden, müssen die Metriken so ausgewählt werden, dass sie bei der Überprüfung der Ziele helfen und aus ihnen Korrekturmaßnahmen abgeleitet werden können. Die Auswahl der Metriken sollte zudem am agilen Reifegrad des Projektteams ausgerichtet sein. Ist der Grad noch niedrig, ist es besser, mit ausgewählten, weniger komplizierten Metriken zu starten. Grundsätzlich ist zu empfehlen, bei den Metriken anstelle von festen Zielwerten Erwartungsbereiche für die Messwerte zu definieren. Anhand dieser Bereiche kann anschließend eine einfache Statusermittlung, z. B. in Form einer Ampel-Darstellung, erstellt werden. Es ist wichtig, dass die den Metriken zugrundeliegenden Messwerte über den Betrachtungszeitraum hinweg vergleichbar bleiben und keine singulären Ereignisse beinhalten. Zu beachten ist weiterhin, dass die Werte nicht zur Leistungskontrolle bzw. Leistungsbewertung verwendet werden. Es gilt das „Goodharts-Gesetz“: „Wenn eine Messgröße zum Ziel wird, hört sie auf, eine gute Messgröße zu sein“. Teams werden automatisch versuchen, die Kennzahlen zu ihrem Vorteil zu manipulieren. Grundsätzlich darf es bei Zielwerten also nicht um Leistungsziele im weiteren Sinn gehen, sondern ausschließlich darum, unterstützende Maßnahmen für die Projektteams zu identifizieren. Standard-Metriken Es gibt eine Reihe von Standard-Metriken, die in den meisten agilen Projekten eingesetzt werden. Für die Ermittlung dieser Metriken werden der Arbeitsfortschritt von User Stories und Story Points, die vom Entwicklerteam investierten Arbeitsstunden, der in den Sprints geschaffene Business Value und unterschiedliche Zeitangaben gesammelt. Diese Messwerte werden anschließend mit unterschiedlichen Funktionen (Anzahl, Mittelwert, Differenz etc.) ausgewertet und in Diagrammen dargestellt. Eine typische Standard-Metrik ist die Sprint Velocity, mit der gemessen wird, wie viele Elemente eines Messwerts ein Scrum Team gegenüber vorgegebenen Planwerten in einem Sprint abarbeitet (siehe Abbildung 1). Sie beantwortet also die Frage, wie gut die Planung erfüllt wurde und ob es Auffälligkeiten in der Kontinuität der verschiedenen Sprintergebnisse gab, wie z. B. Hinweise auf einen abnehmenden Erfüllungsgrad. Als Messgröße für die Velocity wird in der Regel die Anzahl der bearbeiteten Story Points verwendet. Oft wird versucht, Abbildung 1: Sprint Velocity Abbildung 2: Cumulative Flow Diagram Wissen | Metriken für agile Projekte 54 PROJEKTMANAGEMENT AKTUELL · 31. Jahrgang · 04/ 2020 DOI 10.2357/ PM-2020-0072 14_renk_brueggenkamp_preuss.indd 54 14_renk_brueggenkamp_preuss.indd 54 14.08.2020 16: 26: 25 14.08.2020 16: 26: 25 die Teamgeschwindigkeit aus den Story Points abzuleiten, was zur Verbesserung der Planungssicherheit führen soll. Anhand gelieferter Story Points aus vorherigen Sprints werden Erwartungswerte für zukünftige Sprints abgeleitet. Bei dieser simplen Darstellung ist allerdings nicht erkennbar, warum es mehr oder weniger Story Points pro Sprint gab und welche Verbesserungsmaßnahmen gegebenenfalls eingeleitet werden müssen. Das in Abbildung 2 dargestellte Cumulative Flow Diagram wird häufig verwendet, um den „Arbeitsfluss“ bei der Abarbeitung von User Stories für ein festgelegtes Zeitintervall zu visualisieren. Man sieht anhand des Diagramms für jeden Zeitpunkt innerhalb dieses Intervalls, wie viele User Stories noch im Product Backlog, in Bearbeitung oder bereits abgeschlossen sind. Wird die Differenz zwischen den User Stories im Product Backlog und den erledigten User Stories zunehmend größer, könnte dies auf ein Problem hindeuten. Zumindest wird offensichtlich, dass mehr User Stories neu hinzugefügt als erledigt werden. Man kann den Arbeitsfluss in einem Cumulative Flow Diagram auch auf der Basis von Story Points oder dem geschaffenen Business Value darstellen. Noch aussagekräftiger ist eine Kombination dieser beiden Werte. Anhand des bereits gelieferten Business Value und des verbleibenden Aufwands in Story Points kann jederzeit geprüft werden, ob das Projekt beendet werden sollte. Es kann beispielsweise sinnvoll sein, das Projekt unter Kosten-Nutzen-Gesichtspunkten nicht mehr fortzuführen, wenn bereits 80 % des gelieferten Business Value, aber nur 50 % der Story Points erledigt sind. Das Sprint Burndown Diagram wird gerne genutzt, um den Fortschritt eines einzelnen Sprints darzustellen. Hierbei wird oft die noch zu erledigende Arbeit in Form von User Stories auf der senkrechten Achse dargestellt und die Sprintdauer auf der waagrechten Achse. Eine Idealline zeigt darin den gewünschten Verlauf an. Zusätzlich kann die für den Sprint zur Verfügung stehende Team-Kapazität ergänzt werden (siehe Abbildung 3). Mit diesem Diagramm möchte man antizipieren, wann die Arbeit eines Sprints vollständig erledigt ist bzw. ob das bis zum Sprintende erreicht wird. In der Realität gilt das aber nicht immer. Wenn User Stories unterschiedliche Story-Point-Werte haben, könnte man zu Beginn schon allein deswegen einen sehr guten Arbeitsfortschritt haben, weil Stories mit geringer Komplexität, also mit wenigen Story Points, zuerst bearbeitet wurden. Es ist daher sinnvoller, Story Points als Kenngröße für das Sprint Burndown Diagram zu verwenden. Somit kann man ggf. besser erkennen, ob es Probleme mit der Zielerreichung gibt. Aber selbst dann ist es Abbildung 3: Sprint Burndown Diagram Abbildung 4: Lead-Time-Analyse Wissen | Metriken für agile Projekte 55 PROJEKTMANAGEMENT AKTUELL · 31. Jahrgang · 04/ 2020 DOI 10.2357/ PM-2020-0072 14_renk_brueggenkamp_preuss.indd 55 14_renk_brueggenkamp_preuss.indd 55 14.08.2020 16: 26: 25 14.08.2020 16: 26: 25 schwierig, Vorhersagen über den weiteren Sprintverlauf zu treffen. Die Lead Time beschreibt, wie lange eine User Story von der Erfassung im Product Backlog bis zur Fertigstellung benötigt. Für die Analyse der Lead Time werden üblicherweise Diagramme wie in Abbildung 4 verwendet. Die blauen Punkte in der Grafik repräsentieren abgeschlossene User Stories. Je größer die blauen Punkte sind, desto mehr Story Points liegen einer User Story zugrunde. Auf der senkrechten Achse wird die Bearbeitungsdauer der User Stories gezeigt. Die schwarze Trendlinie zeigt den gleitenden Durchschnittswert der Bearbeitungsdauer an und das graue Band um diese Trendlinie die korrespondierende Standardabweichung. Die häufigste Aussage, die aus der Lead Time abgeleitet wird, ist, dass ein Entwicklerteam durchschnittlich zwischen y1 und y2 Tagen von der Erstellung bis zum Abschluss einer User Story benötigt und daher davon ausgegangen werden kann, dass sich die Bearbeitungsdauer zukünftiger User Stories ebenfalls in diesem Zeitkorridor bewegen wird. Diese Annahme gilt aber nur bedingt. Zu Beginn eines Projekts werden häufig sehr viele User Stories angelegt, für die der Lead-Time- Zähler ab diesem Zeitpunkt startet. User Stories, die in den ersten Sprints abgearbeitet werden, haben somit eine sehr kurze Lead Time, weil sie ja zeitnah erledigt werden und die Trendlinie des Lead-Time-Diagramms zeigt nach unten (positiv) bzw. verläuft auf einem sehr niedrigen Level. Irgendwann werden aber auch die User Stories abgearbeitet, die schon länger im Product Backlog sind. Obwohl es positiv ist, dass diese sogenannten Outliner auch erledigt werden, geht die Lead Time und damit auch die Trendlinie nach oben (negativ). Wenn sich das Projekt dem Ende neigt, werden weniger neue User Stories im Product Backlog angelegt. Das führt dazu, dass diese Stories zeitnah abgearbeitet werden können und die Lead Time wieder abnimmt. Die Cycle Time ist eine weitere Metrik zur Messung der Durchlaufzeit. Bei der Berechnung dieser Kenngröße spielt es keine Rolle, wie lange eine User Story bereits im Product Backlog ist, da der Cycle-Time-Zähler erst startet, wenn mit der Bearbeitung der Story begonnen wird. Im Idealfall ist die Cycle Time einer User Story immer kleiner als eine Sprintdauer. Wenn die Cycle Time bei sehr vielen User Stories die Sprintdauer überschreitet, ist das ein Indiz dafür, dass die User Stories zu umfangreich sind. Die mittlere Cycle Time ist auch aussagekräftiger, wenn die Anzahl der User Stories, die unterbzw. oberhalb von diesem Wert liegen, ungefähr gleich ist. Kombinierte Metriken im agilen Umfeld Ein Grundproblem der zuvor beschriebenen Standard-Metriken besteht darin, dass die eindimensionale Kennzahlenbetrachtung (z. B. Anzahl Story Points pro Sprint) nicht ausreicht, um Projektrisiken wirklich erkennen und die notwendigen Korrekturmaßnahmen einleiten zu können. Es ist daher besser, in einer Metrik im Durchschnitt zwei bis fünf zueinander in Bezug stehende Messwerte zu kombinieren. Die Herausforderung besteht dabei darin, eine gut darstellbare Gesamtmetrik zu schaffen. Im Folgenden werden einige kombinierte Metriken vorgestellt und ihre Anwendung bei Optimierungsmaßnahmen in agilen Projekten diskutiert. Backlog Health Nachdem das initiale Product Backlog erstellt wurde, muss es kontinuierlich gepflegt werden. Sind zu viele User Stories im Backlog, geraten die unteren Elemente häufig in Vergessenheit. Es kommt auch häufiger vor, dass ältere User Stories, aufgrund aktueller Erkenntnisse, nicht mehr benötigt werden und aus dem Backlog entfernt werden können. Bei der Entscheidung über die Entfernung von Altlasten sollte der Inhalt anhand des Business Values, der Priorität und der Komplexität (gemessen in Story Points) geprüft werden. Sind die alten User Stories weiterhin relevant, ist es sinnvoll, diese zeitnah in einen Sprint einzuplanen. Wenn hingegen zu wenige Elemente im Product Backlog sind, können die fehlenden Auswahlmöglichkeiten eine gute Sprint-Planung behindern. Im Backlog sollten sich demnach immer genügend „Ready“-Elemente befinden. In der Praxis hat sich ein Wert für ca. 1,5 bis 3 Sprints als gute Größe herausgestellt. Abbildung 5 Abbildung 5: Dashboard-Grafiken zur Bewertung der Backlog Health Wissen | Metriken für agile Projekte 56 PROJEKTMANAGEMENT AKTUELL · 31. Jahrgang · 04/ 2020 DOI 10.2357/ PM-2020-0072 14_renk_brueggenkamp_preuss.indd 56 14_renk_brueggenkamp_preuss.indd 56 14.08.2020 16: 26: 25 14.08.2020 16: 26: 25 Eine angemessene Anzahl an User Stories ist nicht das alleinige Qualitätskriterium für die Beurteilung eines Product Backlogs. Ein gutes Backlog zeichnet sich vor allem dadurch aus, dass die darin enthaltenen User Stories gut beschrieben sind. Sie benötigen Story Points für die Komplexitätsmessung, einen Prioritätswert, einen Business Value und eine Risikobewertung. Um die Qualität des Backlogs zu messen, kann beispielsweise eine kombinierte Metrik mit folgenden Kenngrößen verwendet werden: • Anzahl der User Stories im Backlog verglichen mit einem festgelegten Zielwert. • Verweildauer der User Stories im Backlog bzw. Dauer zwischen Erstellung und Übergang in den Status „Ready“. • Gruppierung der User Stories nach Priorität, Anzahl Story Points, Business Value bzw. Risikobewertung und Vergleich mit festgelegten Zielwerten. Die linke Grafik in Abbildung 5 zeigt die Variante einer kombinierten Metrik, mit der die Qualität des Product Backlogs überwacht werden kann. In diesem Beispiel sind 30 User Stories im Product Backlog (Zielwert 50). Diese haben eine Komplexität von 1.600 Story Points (Zielwert 2.000) und einen Business Value von 1.050 (Zielwert 1.500). Je Kategorie wird zusätzlich die Verteilung auf Prioritäten von eins bis vier gezeigt. Aufgrund der Abweichungen gegenüber den Zielwerten ergibt sich ein gemittelter Gesamterfüllungsgrad von 70 %. In der rechten Grafik sieht man einen Vergleich mit einer Vorperiode in Form einer Ampeldarstellung. Kapazität und Auslastung Direkt im Anschluss an die initiale Befüllung des Product Backlogs starten viele Projektteams mit der Planung des ersten Sprints. Eine wichtige Größe bei jeder Sprintplanung ist die verfügbare Teamkapazität in Stunden. Die Sprintplanung sollte daher immer mit der Abfrage der Kapazitäten der einzelnen Teammitglieder beginnen. Für jedes Mitglied werden die verfügbaren Kapazitäten pro Tag in Stunden und die geplanten Abwesenheiten während der Sprintdauer erfasst. Summiert man die Kapazitäten der Teammitglieder auf, ergibt sich die Teamkapazität. Häufig wird anhand der Erfahrungswerte aus vorherigen Sprints ermittelt, wie viele Story Points pro Sprint abgearbeitet werden können. In der Praxis hat sich aber gezeigt, dass diese Methode in größeren Projekten ohne die Berücksichtigung der jeweiligen Teamkapazität zu ungenau ist. Insbesondere bei Projektprodukten, die aus mehreren Modulen bestehen, sollten die Kapazitäten auf Modulebene ermittelt werden. Dann wird erkennbar, welche Module den höchsten Entwicklungsaufwand haben und ob einzelne Experten, die an einem bestimmten Modul arbeiten, überlastet sind. Auf der linken Seite in Abbildung 6 wird die Sprintkapazität auf Komponentenebene analysiert. Es ist beispielsweise erkennbar, dass die geplante Team-Kapazität für Komponente A (35 %) voraussichtlich nicht genügen wird, um den geschätzten Zeitbedarf (45 %) abzudecken. Für die Komponente C ergibt sich ein gegenteiliges Bild: Hierfür stehen 25 % der Gesamtkapazität zur Verfügung, laut Planung werden aber nur 10 % benötigt. Zusätzlich sollten die geplante Teamkapazität und der geschätzte Zeitaufwand immer mit den tatsächlichen Werten des vorherigen Sprints verglichen werden, um Trendaussagen treffen zu können und, falls notwendig, Korrekturmaßnahmen einzuleiten. Eine solche Trendanalyse wird in der rechten Grafik von Abbildung 6 gezeigt, in der der geschätzte Zeitbedarf für Tasks (Auslastung) als Kenngröße für den Ampelstatus (hier in gelb) verwendet wird. Fortschrittskontrolle Während eines Sprints stellt sich immer die Frage, ob das Sprintziel erreicht wird und wie realistisch die Zielerreichung ist. Zur Fortschrittskontrolle wird in der Regel das eingangs beschriebene Burndown Diagram verwendet. Es kann aber leicht zu Fehleinschätzungen führen, wenn nur die geschätzten Story Points (oder der Aufwand in Stunden) mit den bereits geleisteten Story Points (oder der geleisteten Arbeit in Stunden) verglichen werden. Der Zielerreichungsgrad ist nicht allein von der Anzahl der gelieferten Story Points abhängig, sondern immer auch von dem zu schaffenden Wert (Business Value). Es gibt darüber hinaus weitere Einflussfaktoren, wie die Qualität der Anforderungen, die Abhängigkeiten zwischen den verschiedenen Anforderungen, die Güte der teamüber- Abbildung 6 Abbildung 7: Dashboard-Grafiken zur Kapazitätsauswertung Wissen | Metriken für agile Projekte 57 PROJEKTMANAGEMENT AKTUELL · 31. Jahrgang · 04/ 2020 DOI 10.2357/ PM-2020-0072 14_renk_brueggenkamp_preuss.indd 57 14_renk_brueggenkamp_preuss.indd 57 14.08.2020 16: 26: 26 14.08.2020 16: 26: 26 greifenden Zusammenarbeit oder die Teamzufriedenheit, die einen signifikanten Einfluss auf die Zielerreichung haben. Daher ist es auch bei der Messung des Sprintfortschritts sinnvoll, mehrere Kriterien in der Metrik zu verwenden. In Abbildung 7 wird der Fertigstellungsgrad (Average Fulfillment) anhand der bearbeiteten Story Points (65 %) und des geschaffenen Business Values (50 %) gemessen. Hieraus ergibt sich ein gemittelter Erfüllungsgrad von 58 %. Für beide Größen beträgt der Sollwert zum aktuellen Zeitpunkt 70 %. Auffällig an diesem Beispiel ist, dass es zwar einen hohen Erfüllungsgrad bei den Story Points gibt, sich aber ein Problem beim zu schaffenden Business Value andeutet. Daher müsste geprüft werden, warum keine User Stories mit höherem Business Value bearbeitet wurden und ob man die ausstehenden Arbeiten eventuell anders priorisieren sollte. Sprint Performance Am Ende eines jeden Sprints sollte die Sprint Performance bewertet werden. Gibt es über einen bestimmten Zeitraum hinweg signifikant negative Abweichungen gegenüber den üblichen Ergebnissen, müssen notwendige Korrekturmaßnahmen eingeleitet werden. Für die Bewertung der Sprint Abbildung 7 : Dashboard-Grafik zur Messung der Fortschrittskontrolle Abbildung 8 Abbildung 8: Dashboard-Grafiken zur Messung der Sprint Performance Performance werden häufig Messgrößen verwendet, die auch beim Sprint Burndown Diagramm oder der Velocity-Messung anzutreffen sind. Dazu gehören die Anzahl der abgearbeiteten User Stories, die Summe der erreichten Story Points und der im Sprint geschaffene Business Value. Hinzu kommen Werte wie die Anzahl der geblockten Elemente, die Verweildauer von User Stories je Status oder die Anzahl der Bugs. Hilfreich sind aber auch Messwerte, mit denen die Zufriedenheit des Teams mit dem Sprint und die Qualität der einzelnen Anforderungen bewertet werden. Die Anforderungsqualität kann beispielsweise beurteilt werden, indem die Teammitglieder für jede User Story eine Schulnote geben. Anhand dieser Ergebnisse ist beispielsweise erkennbar, für welche Produktkomponente besonders schlechte Noten verteilt wurden und wie diese mit der Sprint Performance korrelieren. Anschließend können Ursachen und mögliche Gegenmaßnahmen in der Retrospektive diskutiert werden. Grundsätzlich gilt auch bei der Analyse der Sprint Performance, dass mehrere Kriterien in einer Metrik kombiniert werden sollten, um zu einem aussagekräftigen Ergebnis zu gelangen. Abbildung 8 zeigt solch eine kombinierte Metrik. In diesem Beispiel wird die Performance anhand der drei Kriterien Anzahl User Stories, Summe der Story Points und geschaffener Business Value gemessen. Zusätzlich wird anhand der Darstellung noch ersichtlich, wie hoch der Anteil der abgeschlossenen, offenen und geblockten Elemente bei diesen drei Kategorien ist. Insgesamt ergibt sich so eine Sprint Performance von 56 %. In der rechten Grafik wird dieser Perfomance-Wert mit dem der Vorperiode verglichen. Resümee Aufgrund der immer weiteren Verbreitung agiler Methoden hegen die Führungskräfte großer Unternehmen häufig den Wunsch, die Arbeitsgeschwindigkeit ihrer agilen Projektteams anhand von Steuerungsgrößen messen und die Teams miteinander vergleichen zu können. Das führt dann allerdings dazu, dass diese agilen Metriken von den Teams manipuliert und so ihres eigentlichen Sinns beraubt werden. Die Metriken sollten die Teams stattdessen dabei unterstützen, die empirische Prozesskontrolle, die auf den drei Säulen Transparenz, Wissen | Metriken für agile Projekte 58 PROJEKTMANAGEMENT AKTUELL · 31. Jahrgang · 04/ 2020 DOI 10.2357/ PM-2020-0072 Project Office ist Enterprise-Software für beeindruckende Projekte wie den Gotthard-Basistunnel. Agiles Teamwork und hohe Prozesssicherheit verbinden sich dabei zu konsequent hybridem Projektmanagement. Mit agilen Elementen wie Task Boards, Issues und Activities machen Sie Ihre Teams schneller und produktiver. Bewährte Elemente wie die Planung der Ecktermine liefern zuverlässige Leitplanken. energizing great minds Erfolgreiche Projekte durch verlässliche Prozesse und bessere Teamarbeit Engineering success - the agile way WEBCAST Agil, klassisch, hybrid: Die maßgeschneiderte Lösung für Ihr Projekt 10. November, 10: 00 Uhr https: / / bit.ly/ 2WNLAXT 14_renk_brueggenkamp_preuss.indd 58 14_renk_brueggenkamp_preuss.indd 58 14.08.2020 16: 26: 39 14.08.2020 16: 26: 39 Dipl. Inf. Jörg Brüggenkamp Dipl. Inf. Jörg Brüggenkamp ist geschäftsführender Gesellschafter der PMC ProjektManagement und Controlling GmbH in der Schweiz. Er ist als Spezialist mit über 20 Jahren Erfahrung in den Bereichen Turnaround-/ Interims-Management im klassischen und agilen Umfeld tätig. Anschrift: PMC ProjektManagement & Controlling GmbH, Artherstrasse 28a, 6300 Zug (CH), eMail: joerg.brueggenkamp@promanage.ch Prof. Dr. Peter Preuss Prof. Dr. Peter Preuss lehrt Wirtschaftsinformatik an der FOM Hochschule für Oekonomie & Management in Stuttgart. Er ist zertifizierter Project Management Professional (PMP) nach PMI und Professional Scrum Master. Parallel zu seiner Lehrtätigkeit ist Peter Preuss geschäftsführender Gesellschafter der Unternehmensberatung People Consolidated GmbH. Anschrift: FOM Hochschule für Oekonomie und Management, Fachbereich Wirtschaftsinformatik, Rotebühlstraße 121, 70 178 Stuttgart, eMail: peter.preuss@fom.de Dr. Tobias Renk Dr. Tobias Renk ist Global Service Owner für den Bereich B2C Pricing der BP Europa SE. Er ist als Experte und Keynote Speaker zu den Themen Innovation, kultureller Wandel und digitale Transformation unterwegs. Außerdem ist er als Dozent für Unternehmensführung an der Dualen Hochschule Baden-Württemberg in Stuttgart tätig. Anschrift: BP Europa SE, Wittener Str. 45, 44 789 Bochum, eMail: tobias.renk@de.bp.com Überprüfung und Anpassung basiert, umzusetzen. Nur so können die Teams Verbesserungspotentiale identifizieren und sich von Sprint zu Sprint verbessern. Weiterführende Literaturhinweise Davies, Christopher W. H.: Agile Metrics in Action: How to Measure and Improve Team Performance, MANNING, 2015. Pichler, Roman: Agiles Produktmanagement mit Scrum- - Erfolgreich als Product Owner arbeiten, dpunkt.verlag, 2. korrigierte Auflage, 2014. Sutherland, Jeff: Die Scrum-Revolution-- Management mit der bahnbrechenden Methode der erfolgreichsten Unternehmen, Campus Verlag GmbH, 2015. van Solingen, Rini und Berghout, Egon: The Goal / Question / Metric Method: A Practical Guide for Quality Improvement of Software Development, in: https: / / www. researchgate.net / publication / 243 765 439_The_GoalQuestionMetric_Method_A_Practical_Guide_for_Quality_Improvement_of_Software_Development, Stand: 24. 5. 2020. Eingangsabbildung: © lesslemon / stock.adobe.com Wissen | Metriken für agile Projekte 59 PROJEKTMANAGEMENT AKTUELL · 31. Jahrgang · 04/ 2020 DOI 10.2357/ PM-2020-0072 Project Office ist Enterprise-Software für beeindruckende Projekte wie den Gotthard-Basistunnel. Agiles Teamwork und hohe Prozesssicherheit verbinden sich dabei zu konsequent hybridem Projektmanagement. Mit agilen Elementen wie Task Boards, Issues und Activities machen Sie Ihre Teams schneller und produktiver. Bewährte Elemente wie die Planung der Ecktermine liefern zuverlässige Leitplanken. energizing great minds Erfolgreiche Projekte durch verlässliche Prozesse und bessere Teamarbeit Engineering success - the agile way WEBCAST Agil, klassisch, hybrid: Die maßgeschneiderte Lösung für Ihr Projekt 10. November, 10: 00 Uhr https: / / bit.ly/ 2WNLAXT Anzeige 14_renk_brueggenkamp_preuss.indd 59 14_renk_brueggenkamp_preuss.indd 59 14.08.2020 16: 26: 41 14.08.2020 16: 26: 41