KPIs im Scrum – warum das doch zusammenpasst
KPIs im Scrum – wie soll das bitte zusammenpassen? Der Scrum-Guide gibt immerhin auch keinen Aufschluss darüber, welche KPIs für Product Owner relevant sind. Damit grenzt sich das Agile-Konzept ganz bewusst von klassischen Management-Dogmen ab. Aber heißt das, dass KPIs wirklich agile-feindlich sind?
Nein. Es kommt nur darauf an, wie sie integriert werden. Traditionellerweise gibt der Projektmanager die gewünschten Zahlen quasi „von oben“ vor – und das Team hat sie umzusetzen. Anschließend erfolgt das Reporting anhand der vorher definierten KPIs. Sind diese nicht erreicht worden, kommt das Team in die Rechtfertigungs-Bredouille – und der Projektmanager muss sich eine Lösung überlegen.
Scrum will diese Lösung nicht, und zwar völlig zurecht. KPIs als strikte und von außen definierte Zahlen sorgen vor allem für größeren Druck auf das Team. Dieser wiederum bringt insbesondere eins hervor: Reporting-Stress. Das Erreichen der vorgegebenen Kennzahlen auf Biegen und Brechen wird zum obersten Ziel, während das eigentliche Produkt oder Projekt leidet. Letztlich geht es dann darum, im nächsten Meeting bloß die richtigen Zahlen zu liefern – egal, ob das Projekt wirklich auf einem erfolgreichen Weg ist oder nicht. Fazit: Das Produkt wird unter Hochdruck irgendwie fertiggestellt, dass es halbwegs passt. Qualität adé.
Wollen Sie das? Vermutlich nicht, sonst hätten Sie sich nicht für Agile als Arbeitsphilosophie entschieden. Aber heißt das nun, dass alle Entwickler*innen, Texter*innen, Marketer in Ihrem Team fröhlich vor sich hin basteln und einfach mal frei schauen, wo das Ganze sich so hinentwickelt? – Natürlich nicht.
Warum sind KPIs so sinnvoll?
- Sie geben eine Richtlinie vor, an der sich alle Team-Mitglieder orientieren können. Ohne KPIs gibt es nur das große Ganze: das Projektziel nach Sprint X. Auf dem Weg dahin können sich gerade bei großen Projekten aber auch die besten Teams leicht verirren, wenn es keine Etappenziele gibt. KPIs bilden deshalb ein wertvolles Reporting-Tool, um uns auf dem Weg zum Ziel zu zeigen, ob wir richtig geschätzt haben oder etwas verbessern müssen.
- Sie sind ein tragfähiges Tool, um die Wirtschaftlichkeit eines Projekts zu gewährleisten. Nur, wenn wir wissen, was wie viel kostet, sind wir in der Lage, effiziente Maßnahmen von nicht-effizienten zu unterscheiden – notwendige Bedingung für jedes erfolgreiche Unternehmen.
KPIs sind also sinnvoll, nützlich und auch notwendig im agilen Projektentwickeln. Die Frage ist nur: Wie sollen sie umgesetzt werden?
Wie Product Owner KPIs sinnvoll nutzen
Wichtig bei der Integration von KPIs im agilen Arbeitsumfeld ist zunächst das Mindset. Betrachten die Manager*innen KPIs als unumstößliches Gesetz der Chefetage, wird das im agilen Team wenig Akzeptanz suggerieren. Werden KPIs aber als gemeinsam definierte Orientierungshilfen verstanden, können sie das leisten, was sie sollen: die Arbeit des Teams unterstützen und erstklassige Projekte hervorbringen.
Dabei können folgende Grundsätze gelten:
- Auch KPIs sind flexibel:
Natürlich sollten nicht bei jeder kleinen Abweichung vom Plan alle KPIs überdacht werden. Aber – im Scrum spielen die tatsächlichen Abläufe im Team immer eine größere Rolle als das theoretische Konstrukt dahinter. Dahinter steckt ein bedeutender Scrum-Grundsatz, der agiles Arbeiten von klassischer Projektsteuerung unterscheidet. Während KPIs bei dieser vielmehr als unbewegliche Pfosten in der Projektlandschaft verankert sind, sind sie in der agilen Entwicklung eher Wegschilder. Wenn sich auf dem Weg allerdings herausstellt, dass es eine bessere Route gibt, sind auch KPIs durchaus verrückbar. - KPIs sind Etappenziele, nie Hauptziele:
Einer der größten Fehler in der klassischen Projektsteuerung ist, das Erreichen von KPIs zum wichtigsten Ziel überhaupt zu erheben. KPIs dürfen niemals Selbstzweck sein. Das Ziel ist und bleibt immer die erfolgreiche Umsetzung des Projekts entsprechend der User Story. KPIs müssen diesem Zweck dienen. Tun sie das nicht, müssen sie neu überdacht werden. Es ist auch nicht zielführend, von Anfang an jede Kleinigkeit als KPI zu definieren. Definieren Sie lieber die wichtigsten Eckpfeiler und bringen Sie andere KPIs gegebenenfalls ein, wenn Projekt X gestartet ist und Sie diese viel realistischer einschätzen können. - KPIs werden im Team definiert:
Scrum bedeutet Kooperation auf Augenhöhe. KPIs im klassischen Sinne stärken aber allzu oft bestehende Hierarchien, weil sie von de*r Manager*in erdacht und dem Team quasi „übergestülpt“ werden. Deshalb ist es im Scrum dringend notwendig, dass Kennzahlen im Team entwickelt werden, das diese auch umsetzt. Dadurch sind sie erstens realistischer und werden zweitens viel eher als nützlich und gut anerkannt. Wie die Kennzahlen gemessen werden, sollte auch in den Händen des Teams liegen. Product Owner, Scrum Master und alle wichtigen Außenstehenden sollten dabei natürlich ebenfalls zu Wort kommen. Retrospektiven bilden dafür einen guten Rahmen. - Nicht alles kann in KPIs gemessen werden:
Es gibt klassische Elemente im Projekt wie die Velocity (siehe unten), die man ganz einfach in Zahlen ausdrücken kann. Dann gibt es allerdings auch Faktoren, die schwieriger zu definieren sind wie die Happiness (also die Zufriedenheit der Teammitglieder mit dem Projekt). Im Scrum sollten Sie diesen Faktoren Raum geben, abstrakt zu bleiben. Vielleicht finden Sie mit Ihrem Team eine andere oder sogar völlig neue Methode, wie sich solche Paramater messen lassen.
10 KPIs für POs
Product Owner sorgen unter anderem dafür, dass der Wert eines Produkts sich erhöht. Sie sind dafür da, sicherzustellen, dass ein Projekt wirtschaftlich und für Stakeholder gewinnbringend ist. Ohne KPIs wird diese Aufgabe jedoch sehr schwer umzusetzen sein.
Das „Wie“ der Einführung von KPIs im Scrum haben wir also geklärt, kommen wir zum „Was“. Da wird die Sache etwas schwieriger, denn jedes Team und jedes Projekt hat seine eigenen Bedingungen, Hürden und Besonderheiten. Nicht jeder klassische KPI passt zu jedem Team. In unserer Arbeit gibt es aber einige Kennzahlen, die fast immer zum Einsatz kommen. Diese bewegen sich über den Rahmen der reinen Projektentwicklung hinaus – schließlich sollte ein PO nicht nur über den Projektfortgang, sondern auch über die Qualität der Ergebnisse Bescheid wissen.
- Velocity:
Mit diesem KPI misst ein Team die Arbeitsgeschwindigkeit. Diese wird in Story Points pro Sprint gemessen. Diese Story Points werden vorher gemeinsam definiert, je nach Schwierigkeitsgrad der Aufgabe. Zu Beginn jedes Sprints nimmt sich das Team User Storys vor, die es innerhalb dieses Sprints bearbeiten will. Jede Story hat dabei eine unterschiedliche Anzahl an Story Points.
Beispiel:
User Story 1 hat 5 Story Points.
User Story 2 hat 10 Story Points.
User Story 3 hat 15 Story Points.
Am Ende des Sprints wird überprüft, welche Storys das Team geschafft haben. Hat es zum Beispiel Story 1 und 2 geschafft, aber Story 3 nur zur Hälfte bearbeitet, werden nur die ersten beiden Storys in die Velocity miteinberechnet. Sie beträgt also zu diesem Zeitpunkt 15. Dies kann sich natürlich im nächsten Sprint abhängig von Rahmenbedingungen leicht ändern, bietet aber bereits nach dem ersten Sprint einen nützlichen Anhaltspunkt zur Arbeitsgeschwindigkeit. - Kosten:
Kein wirklicher KPI, aber ein Faktor, der bei jeder unternehmerischen Aktion eine große Rolle spielt. Kostenkalkulationen sind in der agilen Projektsteuerung sicher eine Herausforderung, denn zu Anfang eines Sprints können wir noch nicht genau sagen, was er kosten wird. Dennoch – mit jedem Sprint wird die Kostenrechnung genauer, weil wir auf realistische Erfahrungswerte statt auf vorher „erratene“ Kosten gucken. - ROI:
Der Return on Investment ist ein KPI, den Product Owner nicht vernachlässigen sollten. Die einfachste Formel zur Return on Investment Ermittlung lautet:
Gewinn : Kapital
Im Scrum ist auch eine Variante gängig, die sich von der rein monetären Ermittlung des Return on Investment wegbewegt, nämlich:
Nutzen : durch erbrachten Aufwand - Current Value:
Dieser KPI dreht sich nicht mehr um das Arbeiten im Team, sondern um das Ergebnis: das Produkt. Der Current Value misst, wie das Produkt auf dem Markt angenommen wird. Dabei spielen erstens die Kundenzufriedenheit und zweitens die Nutzungsfrequenz eines Features eine Rolle. Also: Wie zufrieden sind Nutzer*innen im Verhältnis zur Häufigkeit der Nutzung von Produkt Y? Dieser KPI lässt sich durch Befragungen der User einerseits und Tracking andererseits ermitteln. - Time-to-Market:
Der Time-to-Market-Indikator errechnet die Zeitspanne zwischen dem ersten Definieren einer Anforderung bis zu deren Verfügbarkeit auf dem Markt. Soll heißen: Wie lange dauert es nach Anforderungsdefinition X, bis diese umgesetzt und live verfügbar ist? Er gibt neben der Velocity einen guten Überblick über die generell Arbeitsgeschwindigkeit im Team. - Unrealized Value:
Bei der Ermittlung von KPIs durch Product Owner lohnt sich auch ein Blick auf das, was wir noch nicht erreicht haben. Hier geht es darum, noch nicht ausgeschöpftes Potenzial in einem Markt zu entdecken. Die wichtigsten Fragen dabei lauten: Wie groß ist unser derzeitiger Marktanteil mit X? Welche Erwartungen stellen Kunden an Produkte aus unseren Bereich, die wir noch nicht erfüllen? Kennzahlen wie der Unrealized Value dienen also nicht nur Reporting-, sondern auch Strategiezwecken. - Ability to Innovate:
Die Ability to Innovate ist einer der wichtigsten strategischen KPIs in agilen Unternehmen. Er ermittelt, wie groß das Innovationspotenzial ist, sprich wie viel prozentualer Arbeitsaufwand in die eigentliche Entwicklung neuer Features fließt. Eine wichtige Kennzahl ist dabei der prozentuale Aufwand für die Entwicklung gegenüber laufenden Tätigkeiten wie Maintenance. Auch die Arbeitszeit, die in die Neuentwicklung fließt, im Vergleich zur Arbeitszeit für andere Aufgaben spielt hier eine Rolle. - Defect Detection Percentage:
Der DDP bezeichnet den Durschnitt der gefundenen Fehler vor dem Produkt-Release im Verhältnis zu allen gefundenen Fehlern vor und nach dem Produkt-Release. Er gibt also Aufschluss darüber, wie gut ein Team darin ist, eigene Fehler zu erkennen. Für die Qualitätssicherung ist dieser KPI also enorm wichtig. Mit folgender Formel können Sie ihn errechnen:
(Anzahl der gefundenen Fehler bis zum Produkt-Release : Anzahl aller gefundenen Fehler vor und nach dem Produkt-Release) * 100 - Net Present Value:
Der Net Present Value ist unverzichtbar, wenn es darum geht, die Wirtschaftlichkeit eines Projekts zu ermitteln. Dieser KPI bezieht sowohl frühe als auch spätere Umsätze mit in die Berechnung ein. Ist er positiv, lohnt sich eine Investition. Ist er negativ, wird sie zum Verlustgeschäft. Oft wird dieser Wert vor allem im Business-Intelligence-Team besprochen. Er ist aber für Product Owner genauso wichtig, um kluge Entscheidungen bei der Projektsteuerung zu treffen. - Charts – mindestens so wichtig wie KPIs:
Egal, welche KPIs Sie in Ihrem Team verwenden, Dokumentation und Visualisierung sind die halbe Miete. Das wichtigste Diagramm ist dabei das Burn Up Chart. Auf diesem werden die erledigten Story Points innerhalb eines Sprints festgehalten. Es zeigt übersichtlich für alle an, wieviel im laufenden Projekt schon geschafft ist. Neben der Velocity enthält es auch eine Scope-Zeile (Projektumfang), die anzeigt, wann Arbeit hinzugefügt oder entfernt wurde.
Hierin liegt der Unterschied zum Burn Down Chart, das ohne Scope-Zeile auskommt. Dieses Chart ist also nur ausreichend, wenn der Scope von Anfang an festdefiniert wurde. Das kann zum Beispiel in einzelnen Sprints der Fall sein. Für ein komplettes Projekt mit all seinen agilen Variablen empfiehlt sich meistens das flexible Burn Up Chart.
Sie nutzen andere Charts? Wunderbar! Wichtig ist, dass Ihr Chart zu Ihrem Projekt, Team und Produkt passt und dass es für alle Teammitglieder gut sichtbar ist.
"Bevor wir ans Setzen von irgendwelchen KPIs gehen, machen wir uns die Mühe, das umzusetzende Projekt aus allen Winkeln zu betrachten und alle Startbedingungen zu analysieren."
KPIs für Product Owner – immer eine individuelle Sache
Die oben genannten KPIs gehören bei uns zur agilen Projektsteuerung dazu. Allerdings arbeiten auch wir sie natürlich nicht strikt nach einem Muster ab. Vielmehr versuchen wir, jedes neue Projekt individuell zu betrachten.
Bevor wir ans Setzen von irgendwelchen KPIs gehen, machen wir uns die Mühe, das umzusetzende Projekt aus allen Winkeln zu betrachten und alle Startbedingungen zu analysieren. Vor allem definieren wir als Erstes eine Vision des bestmöglichen Produktes. Denn darin liegt der Kern des Scrum: Es geht nicht um das Festhalten an starren Regeln und Zahlen, sondern um den größtmöglichen Nutzen für Nutzer*innen. In diesem Sinne nutzen wir KPIS so, wie es wirklich sinnvoll ist und haben uns längst von Reporting im Sinne der klassischen Projektsteuerung verabschiedet.
Haben Sie Fragen zu den KPIs für Product Owner? Möchten Sie allgemein mehr über Scrum oder unsere spezielle Arbeitsweise erfahren? Oder wünschen Sie sich aktive Unterstützung bei Ihrem agilen Projekt? Dann kontaktieren Sie uns. Wir beraten Sie jederzeit gerne – kostenlos und unverbindlich.
