Zusammenfassung: Scrum-Metriken sind konkrete Datenpunkte, die Scrum-Teams verfolgen und nutzen, um die Effizienz und Effektivität zu verbessern. Scrum-Teams setzen diese Metriken ein, um Entscheidungen zu treffen, die Effizienz bei der Planung und Ausführung zu steigern sowie Ziele und Pläne für Verbesserungen festzulegen.
"Was man nicht messen kann, kann man auch nicht verbessern", sagte der bekannte Management-Vordenker Peter Drucker. Diese Aussage gilt zwar nicht für alle Facetten des Lebens, lässt sich aber durchaus auf Teams anwenden, die Agile Scrum praktizieren. Mithilfe bestimmter Metriken können Scrum-Teams die Effektivität des Teams anpassen, lenken und optimieren.
Was ist Scrum?
Scrum ist ein agiles Framework und eine agile Arbeitsweise, die Teams dabei unterstützt, komplexe Probleme anzugehen und auf iterative Weise Lösungen rund um ein bestimmtes Ziel zu entwickeln. Im Mittelpunkt der Scrum-Arbeitsweise stehen Sprints – festgelegte Zeiträume, in denen ein Scrum-Team jeweils ein bestimmtes Arbeitskontingent erledigt.
Dank der hohen Anpassungsfähigkeit haben sich agile Frameworks wie Scrum über technologieorientierte Teams hinaus verbreitet und werden nun auch in Bereichen wie Support, Design oder Marketing genutzt. Vor diesem Hintergrund werden Scrum-Metriken immer wichtiger, um die Leistung und Effektivität eines Teams zu messen.
Was sind Scrum-Metriken?
Scrum-Metriken sind konkrete Datenpunkte, die Scrum-Teams verfolgen und nutzen, um die Effizienz und Effektivität zu verbessern. Wenn sie richtig definiert, verstanden und implementiert werden, können Scrum-Metriken Erkenntnisse liefern, die den Weg eines Teams zu Agile lenken und verbessern.
Scrum-Teams verwenden Metriken, um Entscheidungen zu treffen und die Effizienz bei der Planung und Ausführung zu steigern. Die Metriken können auch dazu dienen, eine Baseline für den Status quo festzulegen und Ziele und Pläne für Verbesserungen vorzugeben. Es gibt allerdings keine Richtwerte, die für die gesamte Branche herangezogen werden könnten. Datenpunkte ohne Kontext zu vergleichen, ist wie der sprichwörtliche Vergleich zwischen Äpfeln und Birnen. Jedes Team ist einzigartig. Die Unterschiede liegen beispielsweise in der Größe, den verwendeten Technologien oder der Art ihrer Aufgaben.
Daher muss sich jedes Team selbst darauf einigen, welche Metriken verfolgt und wie sie genutzt werden sollen. Dies ist keine Aufgabe für Einzelpersonen und nichts, das die Unternehmensführung oder das Management für die Teams definieren und durchsetzen kann.
Warum sind Scrum-Metriken wichtig?
Scrum-Metriken können Teams dabei helfen, Benchmarks festzulegen und die Ausrichtung ihrer Arbeit zu lenken. Aus diesem Grund sind Scrum-Metriken sowohl für schon länger bestehende als auch für neue Teams hilfreich.
Die Verfolgung von Scrum-Metriken trägt auch dazu bei, verschiedene Dimensionen der Effektivität eines Teams sichtbar zu machen, beispielsweise die Velocity, Kapazität, Vorhersagbarkeit der Lieferungen oder Qualität des Produkts. Die richtigen Metriken können das Bewusstsein für die Leistung des Teams steigern und Maßnahmen zur Veränderung und Verbesserung anregen. Außerdem können sie dazu beitragen, die Zufriedenheit des Teams im Laufe der Zeit zu messen.
Agile Teams neigen oft dazu, sich beim Einschätzen ihrer Leistung auf ihr Bauchgefühl oder ihre Intuition zu verlassen. Diese Gewohnheit kann zwar viele praktische Gründe haben, aber das Team verpasst damit eine wichtige Chance.
Können Scrum-Metriken als KPIs dienen?
Ja und nein. Scrum-Metriken können verwendet werden, um Key Performance Indicators (KPIs) einzurichten. Dies hängt jedoch von der Art und dem Umfang der Arbeit ab. Mit Scrum-Metriken allein lässt sich der Wert für die Kunden nicht messen, und sie zeigen auch nicht, ob das Team überhaupt das Richtige geliefert hat. In einem agilen Team sollten KPIs letztlich zeigen, wie gut das Team die Unternehmensprioritäten unterstützt.
Beim Messen der Leistung eines Scrum-Teams sollten auch andere Metriken außerhalb von Scrum berücksichtigt werden. Beispiele:
- Return on Investment (ROI) für ein Unternehmen: Unternehmen messen den ROI je nach ihren Zielen unterschiedlich. Relevant können zum Beispiel das Umsatzwachstum oder die monatlich aktiven Benutzer (Monthly Active Users, MAU) sein.
- Kundenzufriedenheit: Umfragemetriken wie der Net Promoter Score (NPS) und der Customer Satisfaction Score (Kundenzufriedenheit, CSAT) können dir helfen, den Erfolg eines Projekts zu verfolgen. Konsistente Metriken zur Kundenzufriedenheit für jedes Release sind wichtig, um den Wert eines Scrum-Teams für die Kunden aufzuzeigen.
- Teamzufriedenheit: Wenn du deine Teammitglieder nach ihrer Motivation in Bezug auf das Projekt und nach der Interaktion im Team fragst, liefert dir dies bereits wertvolle Hinweise auf mögliche Probleme wie eine hohe Fluktuation, Ermüdung und unzufriedene Entwickler.
Wichtige Scrum-Ereignisse und die zugehörigen Metriken
Bei agilem Scrum gibt es vorgegebene wiederkehrende Ereignisse (Sprints, Sprintplanung, Daily Scrum, Sprint-Review und Sprint-Retrospektive), die an sich noch keine Garantie für Fortschritt oder Erfolg sind. Jedes dieser Ereignisse bietet den Teammitgliedern jedoch Gelegenheit, ihre Arbeitsweise zu überprüfen und anzupassen.
Sprint-Planung
Zu Beginn eines Sprints findet ein Sprintplanungsmeeting statt, bei dem das Team Story-Beschreibungen in detaillierte Tasks aufschlüsselt. So kann es die während eines Sprints zu erledigende Arbeit besser abschätzen. Bestimmte Datenpunkte können die Effizienz der Sprintplanung erhöhen. Hierzu zählen Sprintziele, die aktuelle Team-Velocity, die Teamkapazität und die Art der Aufgaben. Wir verwenden eine Vorlage für das Sprintplanungsmeeting, um unsere Sprintplanung in die richtigen Bahnen zu lenken.
Sprint-Ziele
Sprintziele helfen Teams bei der Entscheidung, was in einem Sprint erreicht werden soll, bringen die einzelnen Elemente in einen Zusammenhang und geben Prioritäten vor. Oft tragen Sprintziele zum Erreichen eines größeren Ziels bei, das am Ende einer ganzen Reihe von Sprints steht. Die Priorität der Sprintziele sollte sich nach ihrem Beitrag zu diesem Ergebnis richten. Wirklich effektive Teams überprüfen ihre Ziele und Prioritäten regelmäßig, um Strategien für die Abfolge und Aufteilung der technischen Arbeiten zu entwickeln.
Team-Velocity
Wie viel Arbeit ein Team in einem Sprint übernehmen kann, hängt im Wesentlichen von der Velocity ab, d. h. vom Umfang der Arbeit, die es in einer bestimmten Zeit leisten kann, bzw. von der Kapazität. Ein Velocity-Chart, wie wir es in Jira verwenden, verdeutlicht, wie viel Mehrwert in einem Sprint geliefert wird. Auf diese Weise können wir besser vorhersagen, wie viel Arbeit ein Team in zukünftigen Sprints übernehmen kann. Die Velocity eines Teams lässt sich erst ermitteln, wenn das Team bereits einige Sprints durchlaufen hat. Im Laufe der Zeit stabilisiert sich die Velocity durch die Zusammenarbeit im Team. Zum einen werden die Teammitglieder vertrauter mit der verwendeten Technologie, zum anderen lernen sie sich und ihre Kompetenzen untereinander besser kennen und sammeln Erfahrung mit der Zusammenarbeit.
Unten siehst du ein Beispiel für ein Velocity-Chart mit (1) einer Schätzstatistik basierend auf Story Points, (2) der Verpflichtung, bei der es sich um eine Schätzung aller Vorgänge im Sprint handelt, (3) den abgeschlossenen Schätzungen und (4) den abgeschlossenen Sprints.
Team Capacity
Es versteht sich von selbst, dass der Arbeitsaufwand, den ein Team in einem Sprint erledigen kann, von seiner Kapazität und Verfügbarkeit abhängt. Eine stabile Velocity nützt nichts, wenn die Hälfte des Teams gerade Urlaub hat. Eine Möglichkeit zur Kapazitätsplanung besteht darin, die Verfügbarkeit jedes Teammitglieds für die kommenden Sprints zu ermitteln und die Summe zu berechnen, um einen Prozentsatz der Gesamtkapazität zu erhalten. Da Änderungen in letzter Minute oder Notfälle jederzeit auftreten können, ist es darüber hinaus empfehlenswert, beim geplanten Gesamtaufwand des Sprints einen Puffer von zehn Prozent freizulassen, damit ihr euch nicht zu viel vornehmt.
Art der Aufgaben
Wenn dein Sprint-Backlog eine wachsende Mischung aus Feature-Arbeit, Bugfixes und technischen Schulden ist, wird es schwierig zu sehen, wo genau dein Team seine Zeit im Sprint einsetzt. Bugs oder technische Schulden können sich leicht in den Sprint einschleichen, insbesondere wenn das Entwicklerteam Wert auf Qualität legt. Wenn das Team nicht aufpasst, fragt es sich nach dem Sprint vielleicht, warum es nicht den gesamten geplanten Mehrwert für Kunden ausgeliefert hat.
Wähle bewusst aus, welche Aufgaben dein Team übernimmt, indem du bei der Sprintplanung auf die Aufteilung der verschiedenen Aufgabenarten achtest. Selbst wenn das Backlog sehr viele technische Schulden und qualitätsrelevante Aufgaben enthalten sollte, kannst du dies strategisch lösen, indem du einen Sprint speziell für technische Schulden oder QS-Maßnahmen planst.
Stand-ups (oder Daily Scrum)
Stand-ups oder Daily Scrums sind kurze tägliche Meetings, bei denen sich die Teammitglieder gegenseitig über ihre Arbeit informieren. Wenn ein Scrum-Team effektiv sein soll, genügt es nicht, dass jedes Teammitglied nur seine anstehenden Aufgaben auflistet. Der Daily Scrum bietet Gelegenheit, den Sprintfortschritt des Teams zu überprüfen und Prioritäten neu auszurichten, um kleine oder große tägliche Entscheidungen zu treffen, die einen erheblichen Einfluss auf das Ergebnis eines Sprints haben können.
Dabei können sich folgende Daten und Metriken als nützlich erweisen:
Fortschritt auf dem Weg zu Sprintzielen
Auch wenn die Teammitglieder im Optimalfall den Status und den Fortschritt ihrer eigenen Arbeit kennen, verlieren sie den Gesamtfortschritt auf dem Weg zu den kollektiven Sprintzielen leicht aus dem Blick. Aus diesem Grund ist es wichtig, beim Stand-up eine Liste mit den Sprintzielen zu präsentieren und im Team zu besprechen.
Betrachte dies als Gelegenheit, um festzustellen, ob das Team noch auf dem richtigen Weg ist. Wenn nicht: Warum ist das so, und was könnt ihr dagegen unternehmen? Falls ihr die erkannten Probleme nicht lösen könnt, solltet ihr dies unbedingt den wichtigsten Stakeholdern mitteilen, damit alle auf demselben Stand sind.
Sprint Burndown
Um den Fortschritt im Team besser einschätzen zu können, sollte das Team den Sprint mit einem Sprint-Burndown-Chart kurz prüfen. In einem Sprint-Burndown-Chart könnt ihr den Abschluss von Aufgaben während eines Sprints verfolgen. Dabei werden die Zeit und der Umfang der zu erledigenden Arbeit (gemessen in Story Points oder Stunden) miteinander abgeglichen. Diese Methode hilft euch, zu beurteilen, ob ihr die Arbeit in der vorgesehenen Zeit erledigen könnt. Außerdem wird "Scope Creep", also eine schleichende Vergrößerung des Projektumfangs, so leichter erkennbar. Wenn ein Burndown-Chart einen starken Ausschlag nach unten aufweist, könnte dies mit einer ungenauen Schätzung des Arbeitsaufwands zusammenhängen.
Unten siehst du ein Sprint-Burndown-Chart in Jira mit (1) der Schätzstatistik, (2) den verbleibenden Werten, die die Gesamtmenge der im Sprint verbleibenden Arbeit darstellen, und (3) einer angenäherten Richtlinie für den vorgesehenen Stand deines Teams.
Verteilung der Arbeitslast
Ein Punkt, den das Team nicht aus den Augen verlieren sollte, ist der Arbeitsaufwand der einzelnen Teammitglieder. Vor allem bei Remote-Arbeit ist es schwierig, den Überblick über die Aufgaben jedes Teammitglieds zu behalten. Wenn du nicht nachvollziehen kannst, wer wie viel zu tun hat, entgeht dir möglicherweise auch, dass einige Teammitglieder bereits überlastet sind. Beim Stand-up können sich die Teammitglieder gegenseitig um Unterstützung und Hilfe bitten. Es bietet auch die Möglichkeit, die Arbeitsbelastung aller anzupassen, um die Sprintziele besser erreichen zu können.
Vorsicht, wenn du diese Metrik im Team verwendest: Sie darf nicht als Druckmittel eingesetzt werden. Wenn du versuchst, mit dieser Metrik die Produktivität der einzelnen Teammitglieder zu messen, demotivierst du unter Umständen dein Team. Schaffe stattdessen eine sichere Umgebung, in der alle offen darüber sprechen können, wie viel Arbeit sie annehmen und wo sie Hilfe benötigen.
Kontextbasierte Einblicke
Wenn die Abfolge der Scrum-Ereignisse feststeht, ist es wichtig, mithilfe von Metriken kontinuierlich die Leistung zu optimieren. Insight ist ein nützliches Tool, mit dem Teams bei Bedarf auf wichtige Metriken zugreifen können – bei der Planung von Sprints, während des täglichen Stand-ups oder beim Optimieren der Auslieferung. Du findest Insight oben rechts in der Board-, Backlog- und Deployment-Ansicht von Jira.
Sprint-Retrospektive
Selbst die besten Teams können von Sprint-Retrospektiven profitieren. Bei dieser Gelegenheit lässt du mit deinem Team den Sprint Revue passieren. Ihr feiert, was gut gelaufen ist, und besprecht, was verbessert werden muss und warum. Dies ist auch der perfekte Moment, um die wichtigsten Sprintmetriken wie den Abschluss der Sprintziele und die Zufriedenheit mit dem Sprint zu überprüfen.
Es folgt ein Beispiel für die Retrospektive meines Teams, skizziert auf einer Confluence-Seite:
Abschluss der Sprintziele
Hat dein Team die bei der Sprintplanung gesetzten Ziele erreicht? Wenn dein Team alles erledigt hat: großartig! Wenn nicht: Was hätte besser laufen können? Beim Bewerten des Teamerfolgs können die Scrum-Metriken, die wir bereits besprochen haben, nützlich sein. Jede Verbesserung des Workflows im Team ist es wert, gefeiert zu werden. Vielleicht ist dein Team schneller vorangekommen, weil es keinen "Scope Creep" gab. Für Teams, die DevOps praktizieren, kann dies auch eine Gelegenheit sein, um wichtige DevOps-Metriken wie die Durchlaufzeit oder die Deployment-Häufigkeit zu überprüfen und um Verbesserungen im Veröffentlichungsprozess zu besprechen, die die Wahrscheinlichkeit erhöhen können, die Sprintziele zu erreichen. Dies hilft deinem Team, Probleme anzugehen und einen klareren Aktionsplan zu erstellen.
Zufriedenheit mit dem Sprint
Hier fragst du dein Team einfach nach seiner Zufriedenheit mit dem Sprint. Manche Teams nutzen dafür eine Zahlenskala, anekdotische Rückmeldungen oder auch Emojis/GIFs. Dein Team kann sich Gedanken über die Teamziele machen und überlegen, ob die Art der Arbeit mit den Teamzielen übereingestimmt hat. Wurde übermäßig viel Zeit für technische Schulden statt für die Fertigstellung eines Features aufgewendet?
Ermutige die Teammitglieder bei der Retrospektive, sich zu äußern. Bei Bedarf kannst du sie auch gezielt aufrufen. Die besten Retrospektiven zeichnen sich durch vielfältige Perspektiven und eine Vielzahl von Meinungen aus. Wichtig ist, dass sich das Team am Ende des Meetings weitgehend auf die wichtigsten Probleme, die Zuständigkeiten und einen Plan zur Nachverfolgung wichtiger Themen geeinigt hat.
Fazit
Scrum soll die Arbeitsweise von Teams verbessern. Scrum-Metriken tragen dazu bei, sicherzustellen, dass Scrum dem Team tatsächlich Vorteile einbringt. Das Team sollte sich durch die Anwendung von Scrum-Metriken nicht unter Druck gesetzt, sondern inspiriert fühlen. Du musst nicht alle in diesem Artikel genannten Metriken verfolgen. Beginne mit einer oder zwei Metriken, um herauszufinden, ob sie im Team Verbesserungen bewirken. Vielleicht nutzt dein Scrum-Team auch schon sehr ausgereifte Scrum-Verfahren, die sich durch Scrum-Metriken nicht mehr nennenswert verbessern lassen. Das ist sehr gut! Ihr dürft nur nicht vergessen, welche vorteilhaften Vorgehensweisen ihr mithilfe dieser Metriken erreicht habt. Betrachte die Metriken gelegentlich erneut, damit Scrum bei euch weiterhin optimal läuft.
