Richard Fichtner 02. März 2021

Metriken für agile Softwareentwicklungsteams

Metriken können bei einer Vielzahl von Anwendungsfällen hilfreich sein. © Adobe: Funtap / stock.adobe.com / 254048990 — © Adobe: Funtap

Bei agiler Softwareentwicklung nach dem Vorgehensmodell Scrum stehen die Anpassung an veränderte Bedingungen bzw. Anforderungen und die Optimierung des Prozesses im Mittelpunkt. Dabei gehen Anpassungen und Optimierungen von dem Entwicklungsteam selbst aus. Dieses reflektiert regelmäßig und passt seine Vorgehensweise und Planungen entsprechend an. Um den Verlauf einer Iteration begründet beurteilen zu können, kommen in der Regel Metriken zum Einsatz. Als Grundlage für diese Metriken benötigt das Scrumteam Daten zu Arbeitszeiten und Aufgaben der Teammitglieder im Betrachtungszeitraum. Die Metriken ermöglichen den Teammitgliedern einen besseren Zugang zu den Metadaten ihrer eigenen Arbeitsrealität. Damit soll das Team in die Lage versetzt werden, die eigene Arbeit besser zu verstehen und auf Basis der gewonnenen Informationen seine Prozesse sinnvoll anzupassen.

Softwareentwicklung ist ein anspruchsvolles Aufgabenfeld auf vielschichtigen Ebenen. Neben technischen und fachlichen Aspekten sind auch die Gestaltungsmöglichkeiten bei dem Prozess der Softwareentwicklung vielfältig. In den vergangenen Jahren haben sich agile Vorgehensmodelle etabliert und damit die geradlinigen Wasserfälle aufgewirbelt und in Wildwasserbahnen verwandelt. Damit wird der bekannte Entwicklungsprozess und alle damit verbundenen Gewohnheiten in Frage gestellt. Entwicklungsteams erhalten neue Frei- und Spielräume, um ihre Arbeitsabläufe zu gestalten. Durch eine optimale Anpassung an die jeweilige Realität des konkreten Projektes lassen sich Wettbewerbsvorteile schaffen. Kurze Iterationen und enge Zusammenarbeit mit Anwendern ermöglichen einen hohen Wirkungsgrad der knappen Ressource "Softwareentwickler".

Gleichzeitig bedeutet dies, dass Softwareentwicklungsteams in agilen Projekten stärker mit Entscheidungen rund um das eigene Vorgehensmodell konfrontiert werden. Die sprichwörtliche "Qual der Wahl" kommt als Preis der neuen Freiheiten. "Welche Veränderungen sind sinnvoll? Muss überhaupt etwas geändert werden? Wo haben wir Verbesserungspotenzial? Woher wissen wir, ob Änderungen den gewünschten Effekt erzielen?" Dies sind grundlegenden Fragen, die auch meine Kolleg:innen und mich in den letzten Jahren intensiv beschäftigt haben. Daher haben wir Metriken konzipiert, um die Metadaten zur eigenen Arbeit allen Teammitgliedern in visualisierter Form zugänglich zu machen. Im Spannungsfeld zwischen Datenschutz und Transparenz wollen wir die eigene Arbeit besser verstehen und auf Basis der gewonnenen Informationen unsere Prozesse sinnvoll anpassen.

Welchen Zweck erfüllen Metriken?

Metriken können bei einer Vielzahl von Anwendungsfällen hilfreich sein. In der Regel werden Metriken in der Vorbereitung von Entscheidungen eingesetzt. Dabei lassen sich Metriken drei grundlegende Aufgaben zuordnen [1]:

Metriken können helfen, besser zu verstehen, was tatsächlich passiert. Durch die Untersuchung der aktuellen Situation lässt sich eine Baseline herstellen, die es ermöglicht, Ziele für zukünftiges Verhalten zu definieren. In diesem Sinn werden Veränderungen an Eigenschaften von untersuchten Prozessen bzw. Produkten im Zusammenhang mit Maßnahmen besser sichtbar und verständlich.
Metriken erlauben es, zu kontrollieren, was passiert. Durch das gewonnene Verständnis über Beziehungen zwischen Maßnahmen und deren Auswirkungen können gezielt Maßnahmen durchgeführt werden, die mit hoher Wahrscheinlichkeit zur Erreichung der angestrebten Ziele führen. In diesem Bereich spielen Metriken eine wichtige Rolle beim Risikomanagement.
Metriken können zur Verbesserung von Prozessen und Produkten ermutigen. Metriken können Menschen motivieren, ihr Verhalten zu verändern. So kann mit Gamification auf Basis von Metriken eine Motivationssteigerung für Arbeiten erreicht werden, die ansonsten als wenig herausfordernd oder zu komplex empfunden werden [2]. Im Gegenzug können Metriken auch dazu führen, dass Demotivation einsetzt. Aus Angst vor negativen Auswirkungen, als Reaktion auf "schlechte Werte", werden die Basisdaten systematisch geschönt. Die Metrik wird somit unbrauchbar für den angestrebten Zweck [3].

Herleitung von Metriken

Metriken sind oft auch ein iterativer Prozess. Dies zeigt beispielsweise die Geschichte der Messung der Temperatur. In Tabelle 1 werden einige Meilensteine der Entwicklung der Temperaturmessung dargestellt [1].

Tabelle 1: Entwicklung der Temperaturmessung

Jahr	Messverfahren
2000 v. Chr.	Einordnung: "heißer als"
1600 n. Chr.	Das erste Thermometer misst "heißer als"
1720 n. Chr.	Fahrenheit-Skala
1742 n. Chr.	Celsius-Skala
1854 n. Chr.	Absolut Null, Kelvin-Skala

Wir können anfangen die Welt zu verstehen, indem wir intuitiv Beziehungen beschreiben, ohne dass wir diese reproduzierbar und absolut messen können. Nachdem einige Erfahrungen gesammelt wurden und ein Grundverständnis für den Gegenstand der Betrachtung entstanden ist, wird eine Möglichkeit benötigt, um eine genauere Messung durchzuführen. Dafür wiederum müssen meist spezielle Methoden oder Hilfsmittel herangezogen werden. Die anschließende Analyse der Ergebnisse führt oft zu neuen Erkenntnissen, höherer Messgenauigkeit und einem tieferen Verständnis [1]. Metriken müssen also erarbeitet werden.

Im Zusammenhang mit Scrum gibt es bereits einige Metriken und Visualisierungen, die weit verbreitet sind und in der Community diskutiert werden. Dazu zählen Metriken wie Velocity, die angibt, wie viel Storypoints ein Team in einem Sprint leistet, und Visualisierung wie das Burndown Chart. Über die gängigen Metriken lassen sich grundlegende Fragen zu agiler Softwareentwicklung beantworten. Wir brauchen für unsere Fragen jedoch andere Metriken.

Rahmenbedingungen und Annahmen

Für alle Metriken gelten folgende Rahmenbedingungen und Annahmen:

Basis für die Metriken sollen Daten aus bestehenden Systemen sein.
Die Metriken sollen für Scrumteams unabhängig vom Einsatz spezifischer Software-Tools anwendbar sein.
Als Betrachtungsrahmen soll ein Entwicklungsteam und dessen Aufgaben in einem bestimmten Zeitraum herangezogen werden. Der Zeitraum ist standardmäßig eine Iteration.
Die Visualisierungen der Metriken sollen sich durch Standard-Diagramm-Bibliotheken, in Webanwendungen implementieren lassen, um eine einfache Integration in bestehende Webanwendungen zu ermöglichen.
Es wird angenommen, dass bezüglich der Verarbeitung persönlicher Daten eine der im BDSG festgelegten Optionen erfüllt ist und die Verarbeitung daher zulässig ist.

Datenquellen – Woher kommen die Daten?

Auf die manuelle Erhebung von Daten verzichtet man i. d. R. aus zwei Gründen. Zum einen besteht bei der manuellen Erhebung von Daten mittels Formularen, egal ob analog oder digital, die Gefahr von absichtlicher und unabsichtlicher Verfälschung, Verweigerung und Verspätung. Zum anderen wirken sich zusätzliche bürokratische Maßnahmen negativ auf die Netto-Arbeitszeit des Entwicklungsteams aus. Daher soll ausschließlich auf bereits vorhandene bzw. bereits durch den Prozess oder die Verwendung von Tools entstehende Daten zurückgegriffen werden.

Softwareentwicklungsteams generieren über den gesamten Software-Lebenszyklus hinweg eine Menge Daten in verschiedenen Systemen:

Projekt Tracking System (Projekt-Tracking-System) / Issuetracker Informationen zu Aufgaben und Aufwänden.
Version / Source Control System (Version-Control-System) führt Buch über Änderungen an Dateien.
Continuous Integration (CI) Server prüfen stetig die Qualität der Software.

Durch den Einsatz der genannten Systeme existiert für die meisten Teams bereits eine breite Datenbasis als Grundlage für eine Vielzahl an Metriken, die mit Daten aus einem System hergeleitet werden können. Diese Metriken beschränken sich auf eine spezielle Sicht auf das Team. Interessant ist eine ganzheitlichere Sicht auf das Team, um Zusammenhänge über Grenzen der Dateninseln hinaus zu verstehen. Dafür müssen die Daten aus den einzelnen Systemen zusammengeführt werden. Die Herausforderung dabei ist es die jeweiligen Datenmengen sinnvoll zu integrieren.

Es müssen Verbindungspunkte zwischen den Datenmengen gefunden oder geschaffen werden, um die Daten aus mehreren Quellen sinnvoll zu verbinden. Als Verbindungspunkte können Daten dienen, die in jeweils zwei zu verbindenden Datenmengen vorliegen.

Ein universelles Konzept, das in vielen Datenmengen existiert, ist Zeit. Genauer ein Zeitpunkt, der einem Wert in einer Datenmenge zugeordnet ist. Über den Zeitpunkt können Datenmengen integriert werden. Anspruchsvoller wird die Integration von Datenpunkten, die sich nicht eindeutig zuordnen lassen. Unterschiedliche Datenstrukturen, welche dieselben Entitäten abbilden, können normalisiert werden. Ein prominentes Beispiel dafür sind Benutzer. In der Regel halten die Systeme eigene Schlüssel für ihre Benutzerdatensätze. Daher sind diese Schlüssel alleine in der Regel nicht ausreichend, um die Datensätze zusammenzuführen. Über ein eindeutiges Merkmal, wie die E-Mail-Adresse, können Benutzer auf eine einheitliche Basis konsolidiert werden. Kann kein durchgängig verwendetes Merkmal ausgemacht werden, kann auf eine externe Zuordnung der Datensätze (Mapping) ausgewichen werden. Diese Lösung ist nicht wartungsfrei (neue Benutzer müssen in der Zuordnungsregel eingetragen werden) und sollte daher nur als Workaround zum Einsatz kommen.

Metriken

In den folgenden Absätzen werden einige Metriken vorgestellt, die uns in der Vergangenheit geholfen haben.

Team Homogeneity (TH)

Beantwortete Frage(n)

Wie homogen ist das betrachtete Team? (Fachliche Segmentierung)
Handelt es sich um ein Team oder mehrere Teams?
Wer hat welche Aufgabentypen bearbeitet? (Technische Segmentierung)

Datenquellen

Projekt-Tracking-System
Version-Control-System

Homogenität

Das Team soll bezüglich seiner Arbeits- bzw. Aufgabenhomogenität untersucht werden. Dies lässt sich in zwei Dimensionen betrachten: technisch (horizontal) und fachlich (vertikal).

Bei der technischen Dimension wird zwischen den horizontalen Elementen eines Produkts unterschieden, z. B.: Frontend, Backend, Tests, Dokumentation, Framework A, Framework B, etc.
Bei der fachlichen Dimension wird zwischen den vertikalen Elementen eines Produkts unterschieden, z. B.: Feature A, Feature B, Module C, Module D, etc.

Für beide Dimensionen gilt, je gleichmäßiger die Aufgaben über das Team verteilt sind, um so homogener ist das Team. Wird jedes Element nur von eine:r Entwickler:in bearbeitet, ist das Team vollständig heterogen. Beide Extreme sind nicht erstrebenswert.

Vollständige Heterogenität bedeutet, dass spezifisches Wissen nur an einer Stelle im Team existiert (Single Point of Failure). Ist ein Teammitglied nicht verfügbar, fehlt dem Team ersatzlos das Wissen über einen Teil des Projekts. Die Gründe für Engpässe in der Verfügbarkeit von Teammitgliedern sind vielfältig: Urlaub, Elternzeit, Krankheit, Team- oder Arbeitgeberwechsel sind mögliche Faktoren. Um weiterarbeiten zu können, muss das Team das Wissen ohne den designierten Spezialisten erarbeiten oder warten, bis dieser wieder zur Verfügung steht. Somit bringt vollständige Heterogenität Risiken für die Planbarkeit neuer Features sowie für die Durchführung von Wartungsarbeiten.

Vollständige Homogenität bedeutet, dass jedes Teammitglied allumfassendes Wissen über die technischen bzw. fachlichen Gegebenheiten des Projekts besitzt (Total Knowledge Sharing). Ist ein Teammitglied nicht verfügbar, können dessen Aufgaben durch ein beliebiges anderes Teammitglied übernommen werden. Der hohe Grad der Redundanz bzw. die Kosten in Form von Zeit, um diese Redundanz herzustellen, stehen in Konkurrenz zum Ziel "Business Value" in Form von Features zu liefern. Somit birgt vollständige Homogenität das Risiko, dass dem Team wenig Zeit bleibt, um neue Features zu entwickeln.

Projekte haben unterschiedliche Anforderungen daran, wie viel Redundanz angestrebt wird bzw. wo sich das Team zwischen den Extremen positionieren möchte. Wir haben festgestellt, dass die Selbsteinschätzung von Teams über ihre aktuelle Position weit von dem abweicht, was wir gemessen haben. Es lohnt sich also einen Blick in die Zahlen zu werfen.

Anwendungsgebiet

In der Regel liegt die Teamhomogenität zwischen den Extremen. Folgende Motivationen können bestehen, um die Teamhomogenität zu messen, zu beobachten und in eine Richtung zu entwickeln.

Bei Scrum gibt das Product Backlog bzw. das Sprint Backlog die Priorität und damit die Reihenfolge der Aufgaben vor [4]. Im Idealfall kann ein Team im Sprint genau nach dieser Reihenfolge die Aufgaben bearbeiten. Umso höher die Heterogenität im Team ist, desto höher ist die Wahrscheinlichkeit, dass die Aufgaben nicht in der vorgegebenen Reihenfolge erledigt werden können. Es entstehen Knowledge Bottlenecks, die dazu führen, dass das Team Aufgaben überspringen oder warten muss. Somit wird das Team nicht dem Anspruch gerecht, die Features zu liefern, die am dringendsten benötigt werden.
Eine weitere Motivation ist der "Bus Factor" oder "Truck Number", eine Kennzahl die Coplien zur Abschätzung von Risiken in Software-Projekten vorschlägt. Der Wert gibt die Wahrscheinlichkeit des Scheiterns eines Projekts bei Ausfall eines Mitarbeiters an [5].

"How many or few would have to be hit by a truck (or quit) before the project is incapacitated?" [6]

Die Ermittlung dieses Faktors wird in der Regel aus dem Kopf durchgeführt. Frei nach der Überlegung: "Wer müsste ausfallen, damit wir ein Problem haben?". Dabei besteht das Risiko, dass man sich verschätzt und eine falsche Annahme trifft. Sicherer ist eine Herleitung des Faktors über die Teamhomogenität. Je nach Qualität der Datenbasis kann man auf diesem Weg sehr genaue Aussagen erhalten.

Weiterhin kann Teamhomogenität helfen, Sub-Teams – Teams im Team – zu identifizieren. Möglicherweise arbeiten zwei Untergruppen im Team stark disjunkt an fachlichen oder technischen Themen. Mit dieser Information kann man entweder erkennen, dass es sich tatsächlich um zwei Teams handelt und die Teams trennen oder man arbeitet daran, dass aus zwei Teams eins wird.

Variable	Beschreibung
k	Komponente: Was als Komponente angesehen wird, kann für das jeweilige Projekt definiert werden. Die erste Instanz ist eine Unterscheidung in technische bzw. fachliche Ebene. Anschließend können projektspezifische Komponentengrenzen definiert werden. Eine fachliche Komponente in einer E-Commerce-Anwendung könnte z. B. der Warenkorb sein.
t_k	Zeit, die für die Arbeit an der Komponente k vom Team aufgebracht wurde. Im Idealfall fließen hier die Zeiten aller Aufgaben und derer Prozessschritte ein, d.h. auch Spezifikation und Tests.
m_k	Anzahl der Teammitglieder, die an der Komponente k gearbeitet haben.
m_all	Anzahl der Teammitglieder (die dem Projektteam angehören)
h_k	Teamhomogenität für die Komponente k

Erster Ansatz für die Berechnung der Teamhomogenität:

h1_k := m_k / m_all

Diese Berechnung ist nicht nach Arbeitszeit bzw. Aufwand gewichtet. Dies bedeutet, dass ein Teammitglied nur eine Codezeile ändern muss, um mit dem gleichen Gewicht in die Berechnung einzugehen, wie ein anderes Teammitglied, das die Komponente seit Jahren betreut. Der Anteil der Teammitglieder wird im Folgenden mit der aufgewendeten Arbeitszeit gewichtet, um eine Abbildung näher an der Realität zu bekommen. Dabei steht die Annahme im Raum: "Arbeitszeit an einer Komponente und Kenntnis der Komponente sind direkt proportional zueinander."

TH_k := ∏m( 1+ t_m,k / t_k )

Diese Formel hat den Vorteil, dass sowohl die Arbeitszeit als Gewichtung einfließt und gleichzeitig die Werte beim Vergrößern des Teams stabil bleiben.

Der Definitionsbereich und Wertebereich der Metrik stellen sich wie folgt dar:

D_TH(m) = [2;∞]
W_TH = [u;o]
u = 2 Das Team ist vollständig heterogen
o = ( 1 + 1 / m_all ) ^m^_allDas Team ist vollständig homogen

Zur Vereinfachung der Darstellung kann der Wertebereich wie folgt auf W_TH = [0;1] korrigiert werden:

TH_k, korrigiert := TH_k-2 / o-2

Die Metrik ergibt somit einen Wert zwischen 0 und 1. Es wird eine Darstellung in Prozent empfohlen.

Datenquellen

Version-Control-System

Über das Version-Control-System lässt sich nachvollziehen, welches Teammitglied wann Änderungen an welchen Dateien vorgenommen hat. Dateien lassen sich auf Klassen abbilden. Klassen wiederum können Komponenten zugeordnet werden [7]. Abb. 1 zeigt den Datenpfad von einem User zu einer Komponente.

Abb. 1: Zusammenhang von Änderung der Codebasis und Komponenten. © Richard Fichtner

Diese Variante der Datengewinnung funktioniert gut in Projekten, deren Implementierung eine Zuordnung von Klassen zu Komponenten aus der Codebasis zulässt. Beispiele hierfür sind Java oder C#, die über eine Paket- bzw. Namespace-Struktur eine Hierarchie erzeugen, über welche üblicherweise Komponenten abgebildet werden.

Projekt-Tracking-System

Wenn eine Herleitung des Komponentenbezugs aus dem Version-Control-System nicht oder nicht zufriedenstellend möglich ist, können diese Informationen ggf. auch alternativ oder ergänzend aus dem Projekt-Tracking-System gewonnen werden. Viele Projekt-Tracking-System sehen in der Standardkonfiguration das Datenfeld "Komponente" vor. Dies ist die offensichtlichste Anlaufstelle. Über Metadaten wie Labels oder Tags kann auch ein Bezug zu Komponenten hergestellt werden. Manche Teams arbeiten auch mit Hashtags in Kommentaren. Durch die Analyse der Hashtags in Kommentaren lässt sich ebenfalls ein Komponentenbezug herstellen.

Die Qualität der Daten, die aus dem Projekt-Tracking-System gewonnen werden, ist dabei stark abhängig von der Disziplin des Teams, Labels und (Hash)tags überhaupt und zusätzlich korrekt zu setzen. Die Daten aus dem Projekt-Tracking-System können mit den Daten aus dem Version-Control-System kombiniert werden, um bessere Ergebnisse zu erzielen und ggf. Inkonsistenzen zu erkennen.

Visualisierung

Als Visualisierung für TH wird ein kombiniertes Diagramm bestehend aus einem gestapelten Säulendiagramm (100%) und einem Liniendiagramm vorgeschlagen. Über das Liniendiagramm wird der Verlauf von TH dargestellt.

Element	Beschreibung
X-Achse	Zeitlicher Verlauf
Y-Achse (links): Säulen	Arbeitsanteile der Teammitglieder in Prozent, die zum jeweiligen Zeitpunkt (gestapelt) als Grundlage für die Berechnung von TH stehen
Y-Achse (rechts): Linie	Teamhomogenität in Prozent

Abb. 2: Teamhomogenität Verlauf. © Richard Fichtner

In Abb. 2 wird beispielhaft die TH für ein Team bestehend aus Alice, Bob und Claire gezeigt. Über den Verlauf der Messpunkte wird die Veränderung der TH des Teams von vollständiger Heterogenität zur vollständigen Homogenität sichtbar. Im Beispiel wird die betrachtete Komponente zum Zeitpunkt der ersten Messung (t1) alleine von Alice betreut. Im Verlauf der Zeit beteiligen sich Bob und Claire zunehmend an den Arbeiten an der betrachteten Komponente. Zum Zeitpunkt der letzten Messung (t6) haben alle Teammitglieder schließlich gleiche Zeitanteile. Das Team ist damit für die betrachtete Komponente vollständig homogen.

Hinweise

Verlässt ein:e Mitarbeiter:in das Team, sollten dessen Arbeitsanteile nicht mehr in die Berechnung einfließen, da dessen Know-how dem Team nicht mehr zur Verfügung steht. Zugänge zum Team, die nicht an der betrachteten Komponente arbeiten, haben durch die Art der Berechnung keinen Einfluss auf das Ergebnis.

Sprint Profile (SP)

Beantwortete Frage(n)

In welche Typen von Aufgaben (Features, Bugs, Hotfixes, Meetings) hat das Team im Sprint wie viel Zeit investiert?

Beschreibung

Empirische Messung der eingebrachten Zeit des Entwicklungsteams nach Aufgabentyp

Wert

Rückblickend: Sprints werden in der Dimension "Aufgabentyp" vergleichbar
Vorausschauend: Als Basis für Voraussagen zu Kapazitäten je "Aufgabentyp"

Datenquellen

Projekt-Tracking-System
Kostenstellenzuordnung

Anwendungsgebiet

Agile Softwareentwicklung möchte Kundenzufriedenheit durch die schnelle Lieferung von funktionierender Software erreichen. Im Idealfall wird möglichst viel Arbeitszeit in die Entwicklung von Features gesteckt, da diese den Wert der Software steigern. Arbeitsaufwand, der in die Behebung von Bugs oder die Bearbeitung von Hotfixes fließt, vermindert die Zeit, die für Features zur Verfügung steht. Hinzu kommt die Zeit, die das Team in Meetings verbringt, hierzu zählen z. B. Daily Scrum, Sprint Retrospektive und Sprint Review [8]. Das Team soll die Möglichkeit erhalten, Sprints in Bezug auf den Aufgabentyp zu vergleichen und Schlussfolgerungen daraus zu ziehen.

Mit diesen Informationen kann das Team zukünftige Sprints besser planen, da Erfahrungswerte für die Zeitanteile je Aufgabentyp aus den letzten Sprints vorliegen [9]. Auch Überlegungen zum Thema Qualität können angestellt werden, zumal viele Bugfixes ein Indikator für mangelnde Qualität bzw. Qualitätssicherung sein können.

Berechnung

Variable	Beschreibung
t_m,b,p,a	Eingebrachte Arbeitszeit in Stunden des Teams (m) im Betrachtungszeitraum (b) für das zu untersuchende Projekt (p) für den Aufgabentyp (a)

Sprint Profile_a := ∑_m t_m,b,p,a

Der Wertebereich der Metrik stellt sich wie folgt dar:

W_SP = [u;o]
u = 0 Das Team hat keine Zeit für den Aufgabentyp eingebracht.
o = |m| * |b| Alle Teammitglieder haben ununterbrochen am Aufgabentyp gearbeitet.

Die Metrik ergibt einen Zeitwert. Als Einheit wird Stunden vorgeschlagen.

Datenquellen

Über die Kostenstellzuordnung kann die investierte Zeit des Teams für einen Sprint ermittelt werden. Diese Zeiten müssen mit den Daten aus dem Projekt-Tracking-System angereichert werden, um eine Zuordnung zum Aufgabentyp zu erhalten.

Abb. 3: Zuordnung von Zeiterfassung und Aufgabentyp. © Richard Fichtner

In Abb. 3 ist beispielhaft die Aufgabe "APOLLO-56" (blauer Knoten) aus dem "Sprint 1" (rosa Knoten) dargestellt. Zugeordnet sind die Zeiteinträge zweier Kolleg:innen, die an dieser Aufgabe gearbeitet haben (gelbe Knoten). Der Aufgabentyp ist wiederum mit der Aufgabe verknüpft. Somit lassen sich alle notwendigen Daten für SP ermitteln.

Visualisierung

Als Visualisierung wird ein Netzdiagramm vorgeschlagen, da sich damit mehrere Profile gut vergleichen lassen.

Element	Beschreibung
Achsen	Je Aufgabentyp wird eine Achse eingeführt. Auf der Achse werden die Stunden pro Aufgabentyp von innen nach außen angetragen.

Abb. 4: Vergleich Spint Profile (h). © Richard Fichtner

Abb. 4 zeigt zwei Sprint-Profile im Vergleich. Sprint 1 hat ein wünschenswertes Profil, es wurde viel Zeit in Features investiert und wenig Zeit in andere Aufgaben. Im Gegensatz dazu steht das Profil von Sprint 2, es wurde mehr Zeit in Bugs investiert als in Features. Dies deutet darauf hin, dass in Sprint 1 auf Kosten der Qualität das Sprintziel erreicht wurde. Je nachdem wie das Team mit Bugs umgeht bzw. wie diese in Sprints eingeplant werden, können diese Effekte auch erst in einem späteren Sprint sichtbar werden. Es lohnt sich, die Augen nach solchen Mustern offen zu halten und als Gesprächseinstieg zu nutzen.

Team Time Commitment (TTC)

Beantwortete Frage(n)

Wie viel Zeit wurde vom Entwicklungsteam eingebracht?

Wert

Rückblickend: zeigt auf, in welchem Maß das Team am Sprint arbeiten bzw. nicht arbeiten konnte. Kann helfen, Störungen des Teams zu erkennen.
Vorausschauend: Über die erhaltenen Datenpunkte lässt sich der Zeiteinsatz für folgende Sprints genauer abschätzen und somit die Sprint Kapazität besser planen.

Datenquellen

Projekt-Tracking-System, (ggf. Zeiterfassungssystem)

Anwendungsgebiet

Das Team verpflichtet sich bei Scrum auf ein Sprintziel. Wie genau diese Verpflichtung zu interpretieren ist, geht aus dem Scrum-Guide nicht hervor, es ist lediglich die Rede von "commitment". In der Scrum-Community gibt es verschiedene Interpretationen, die an dieser Stelle jedoch keine Rolle spielen. Interessant ist in der Regel, ob das Sprintziel erreicht werden konnte oder nicht. Das Sprintziel zu erreichen ist umso einfacher,

je genauer die Schätzungen sind,
je geschützter der Sprint ist und
je genauer die Sprintkapazität bekannt ist.

Die Genauigkeit von Schätzungen ist ein breites Thema, welches nicht in den Fokus dieses Artikels passt und daher besser separat behandelt werden sollte. TTC adressiert die letzten beiden Punkte. Der Schutz des Sprints wird oft nur aus Sicht der Aufgaben im Sprint betrachtet, es gibt jedoch einen zweiten Angriffspunkt, die Mitglieder im Team [10]. Würden Teammitglieder dauerhaft entfernt, dann würde das Team explizit darauf reagieren und sich möglicherweise neu organisieren. Unmerklicher sind kleine Veränderungen, z. B. wenn ein Entwickler einige Stunden bei einem anderen Projekt aushelfen soll, weil er dort vor Jahren die Grundlagen geschaffen hat oder einfach nur Expertise zu einer Technologie hat, die im anfordernden Projekt fehlt. Genauso ist aber auch ein Teamzuwachs möglich. Beispielweise könnte für eine Story stundenweise ein Kollegin aus dem Infrastrukturteam das Entwicklungsteam unterstützen. Hier grenzt sich Sprint-Schutz und Sprintkapazität ab. Waren die Änderungen am Team geplant, ist der Sprint geschützt und die Kapazität korrekt geplant. Bei der Planung der Sprintkapazität werden gut planbare Termine wie Feiertage und Urlaube berücksichtigt. Weniger gut planbare Termine wie Elternzeitbeginn oder Krankheitstage stellen eine Herausforderung dar.

Rückblickend können das geplante TTC mit dem tatsächlichen TTC verglichen werden. Abweichungen in beide Richtungen sind zu untersuchen. Wurde signifikant mehr Zeit eingebracht als geplant, könnte dies auf verdeckte technische oder fachliche Probleme hindeuten. Die Ursache kann auf Aufgabenebene gesucht werden. Wurde signifikant weniger eingebracht als geplant, deutet dies auf Störungen des Teams hin.

Vorausschauend kann TTC verwendet werden, um eine bessere Grundlage für die Planung der Sprintkapazität zu erhalten.

Abgrenzung von Velocity

Die Metrik Velocity beschäftigt sich mit der Leistung des Teams bezogen auf fertiggestellte Aufgaben im Sprintzeitraum [3]. Wir raten davon ab, die Produktivität eines Teams alleine anhand von Velocity zu messen.

Leistung= ∆ Arbeit / ∆ Zeit -> Velocity= Tasks Completed / Sprint Timeframe

TTC hingegen bezieht sich auf die vom Team eingebrachte Zeit. Diese Größe kommt bei der Berechnung der Velocity nicht zum Tragen.

Berechnung

t_m,b,p = Eingebrachte Arbeitszeit in Stunden eines Teammitglieds (m) im Betrachtungszeitraum (b) für das zu untersuchende Projekt (p)

Team Time Commitment := ∑_m t_m,b,p

Der Wertebereich der Metrik stellt sich wie folgt dar:

W_TTC = [u;o]
u = 0 Das Team hat keine Zeit eingebracht.
o = |m| * |b| Alle Teammitglieder haben ununterbrochen am Projekt gearbeitet.

Dieser Wert wird mit steigender Dauer von b zunehmend unwahrscheinlich, da wir Menschen und nicht Maschinen betrachten.

Die Metrik ergibt einen Zeitwert. Als Einheit wird Stunden vorgeschlagen.

Datenquellen

Über die Kostenstellzuordnung kann die investierte Zeit des Teams für den Betrachtungszeitraum ermittelt werden. Durch das Zusammenführen der Aufgaben aus dem Projekt-Tracking-System und den dazugehörigen Zeiten aus dem Zeiterfassungssystem lässt sich TTC berechnen.

Visualisierung

TTC lässt sich in einer Abwandlung des Burndown Charts darstellen, sodass das Team während des Sprints ein anschauliches Feedback bekommt. Burndown Chart ist eine weit verbreitete Visualisierung für agile Softwareentwicklung. Herkömmlich wird der verbleibende Aufwand in einem Projekt in Relation zur verbleibenden Zeit dargestellt. Ein Beispiel für ein Burndown Chart zeigt Abb. 5 [3].

Abb. 5: Burndown Chart (Completed Tasks). © Richard Fichtner

Element	Beschreibung
X-Achse	Zeitlicher Verlauf
Y-Achse	Verbleibender Aufwand im Betrachtungszeitraum. Der geschätzte Restaufwand zu jedem Zeitpunkt wird an dieser Achse gemessen.
Startpunkt	Am weitesten links liegender Punkt im Diagramm, der Beginn des Betrachtungszeitraums.
Endpunkt	Am weitesten rechts liegender Punkt im Diagramm, der das Ende des Betrachtungszeitraums markiert. Sein Abstand zum Startpunkt ergibt sich aus dem gesamten Aufwand im Betrachtungszeitraum geteilt durch die täglich leistbare Menge an Arbeit.
Ideal Tasks Remaining	Eine gerade Linie von Start- zu Endpunkt, die die idealisierte Annahme, der Aufwand im Projekt würde über die Zeit gleichmäßig geleistet werden, repräsentiert. Am Startpunkt zeigt die Ideallinie den geschätzten gesamten Aufwand im Betrachtungszeitraum. Am Endpunkt trifft sie die X-Achse, denn dann verbleibt kein Aufwand.
Actual Tasks Remaining	Diese Linie zeigt den tatsächlich verbleibenden Restaufwand. Zu Anfang und, bei Einhaltung des Endtermins auch am Ende, liegt diese Linie gleichauf mit der Ideallinie.

Wenn "Actual Tasks Remaining" oberhalb des "Ideal Tasks Remaining" liegt, ist noch mehr zu erledigen als geplant war, sodass das Projekt hinter dem Zeitplan liegt. Ist das Gegenteil der Fall, dann ist weniger Aufwand notwendig als geplant war. Damit liegt das Projekt vor dem Zeitplan.

Im Gegensatz zu dem herkömmlichen Burndown Chart mit der Darstellung der "Completed Tasks", wird beim Burndown Chart mit der Abbildung von TTC die geleistete Zeit des Teams in Stunden beschrieben. Damit werden zwei wesentliche Effekte erzielt:

Es wird sichtbar, was bzw. wie viel Zeit das Team geleistet hat.
Es wird sofort sichtbar wo das Team steht. Die Darstellung von "Completed Tasks" ist jedoch träge, da erst nach Abschluss eines Tasks eine Veränderung sichtbar wird.

Abb. 6 zeigt ein Beispiel dafür:

Abb. 6: Burndown Chart (Team Time Commitment). © Richard Fichtner

Das Burndown Chart für TTC ist analog zu dem oben beschrieben Burndown Chart zu interpretieren, mit folgenden Ausnahmen:

Element	Beschreibung
Ideal Invested Time	Eine gerade Linie von Start- zu Endpunkt, die die idealisierte Annahme, die investierte Zeit im Projekt würde über die Zeit gleichmäßig geleistet werden, repräsentiert. Am Startpunkt zeigt die Ideallinie die geplante Gesamtzeit im Betrachtungszeitraum.
Actual Invested Time	Diese Linie zeigt die tatsächlich investierte Zeit.

Abb. 7: Burndown Chart Vergleich "Completed Tasks" und "Team Time Commitment". © Richard Fichtner

Obwohl die Linie "ideal" genannt wird, muss es im konkreten Projekt nicht richtig sein, ihr im gesamten zeitlichen Verlauf möglichst genau zu folgen. Dennoch hilft die Ideallinie, den Projektfortschritt einzuschätzen. Im Beispiel liegt "Actual Invested Time" zum Ende des Betrachtungszeitraums unter "Ideal Invested Time". Das bedeutet, das Team hat mehr Zeit investiert als geplant.

In Abb. 7 werden die beiden Serien "Completed Tasks" und "Invested Time" in einem Burndown Chart gezeichnet. Im Vergleich lässt sich gut erkennen, wie unterschiedlich die Werte sind. "Completed Tasks" zeigt zwischen Tag 4 und Tag 7 keine Veränderung und vermittelt den Eindruck, dass das Team keine merklichen Fortschritte macht. "Invested Time" hingegen verändert sich täglich. Das Team scheint in diesem Beispiel am Tag 5 zu erkennen, dass es mehr Zeit einbringen muss, um das Sprintziel zu erreichen. Schwankungen während des Sprints sind normal: Bei schönem Wetter passiert in der Regel weniger, auch Sportereignisse wie der Super Bowl oder ein Champions-League-Spiel hinterlassen ihre Spuren im Diagramm. Zum Ende des Sprints hat das Team das Sprintziel erreicht, jedoch mit 30 Stunden mehr Einsatz als geplant. Wenn das Team regelmäßig mehr Zeit als geplant einbringt, um das Sprintziel zu erreichen, sollte das thematisiert werden.

Zusammenfassung und Ausblick

Mit der Idee, durch Introspektion an sich selbst zu arbeiten und neue Erkenntnisse zu erlangen, setzen sich bereits um 400 v. Chr. griechische Philosophen wie Sokrates und Platon auseinander.

Gnothi seauton (griechisch "Erkenne dich selbst!")

Als Grundlage dafür wurde die Erkenntnis um das eigene Unwissen vorausgesetzt. Erst anschließend könne man sich daran machen, sich selbst zu verstehen [12]. Durch die Arbeit an diesem Thema hat sich uns ein neuer Blickwinkel erschlossen. Die richtige Metrik, zur richtigen Zeit mit einer sinnvollen Visualisierung kann ein guter Einstiegspunkt für nachhaltige Veränderungen für ein Entwicklungsteam sein. Metriken können Softwareentwicklungsteams helfen, die Metaebene ihrer täglichen Arbeit besser zu verstehen.

Die Vorstellung der Metriken war oft der Anstoß für eine angeregte Diskussion, die tiefe Einblicke in die Arbeitsrealität des Teams erlaubte. Die persönlichen Meinungen zu verschiedenen Metriken gehen weit auseinander, es zeigte sich jedoch, dass alleine schon das Gespräch über Metriken sehr fruchtbar ist. Hier sehen wir den wahren Wert. Die Zahlen sind immer mit Annahmen versehen und bilden die Realität unzureichend ab. Die Gespräche, die durch die Zahlen angeregt wurden, haben jedoch viele Teams trotzdem weitergebracht. Daher kann ich nur ermutigen, über Metriken zu sprechen und getreu dem agilen Motto "inspect and adapt" zu erforschen, was daraus erwächst.

Quellen