Nachfolgend werden verschiedene Kennzahlen vorgestellt, mit deren Hilfe die agile Performance über die verschiedenen Dimensionen hinweg gemessen werden kann.
3.2.1 Geschwindigkeit
Schnelles Reaktions- und Handlungsvermögen gefragt
Geschwindigkeit stellt eine gute Messgröße dar, um das schnellere Reaktions- und Handlungsvermögen des agilen gegenüber dem traditionellen Projektmanagement aufzuzeigen. Dabei beschreibt die Geschwindigkeit im Grunde das Verhältnis zwischen der erledigten Arbeit des Teams und der genutzten Zeit. Da im agilen Umfeld in Sprints gearbeitet wird, lässt sich die Formel für die Geschwindigkeit folgendermaßen darstellen:
Geschwindigkeit = Geleistete Arbeit/Sprint
Diese Kennzahl lässt sich unabhängig von der Größe des agilen Teams nutzen. Um die geleistete Arbeit eines Teams messbar zu machen, können bspw. die geleisteten Arbeitsstunden herangezogen werden. Wird die Geschwindigkeit über mehrere Sprints mit vergleichbaren Aufgabenpaketen gemessen, lässt sich eine gute Prognose über zukünftige Abläufe treffen. Die regelmäßige Messung nach jedem Sprint ermöglicht es, potenzielle Hindernisse und Erfolgsfaktoren frühzeitig zu erkennen. Auf diese Weise kann rechtzeitig reagiert und in nachfolgenden Sprints nachjustiert und so der Arbeitsablauf optimiert werden.
Für die Nutzung der Messgröße "Geschwindigkeit" sollten folgende Hinweise berücksichtigt werden: Wird über mehrere Sprints hinweg eine Inkonsistenz der Geschwindigkeit erkannt, sollte zeitnah nachgesteuert werden, indem interne und externe Einflussfaktoren analysiert und bewertet werden. Wichtig ist auch, dass bei der Messung der Geschwindigkeit Ereignisse wie das Wechseln eines Teammitglieds berücksichtigt werden. Bei jeder wesentlichen Veränderung der Rahmenbedingungen sollte die Kennzahl neu bewertet oder die Berechnung sogar neu gestartet werden.
3.2.2 Backlog-Posten
Störgrößen aufdecken
Aufgrund der Arbeit in iterativen Zyklen eignen sich jene Kennzahlen besonders, die die Erfolge eines Sprints und entsprechende Effizienzen aufzeigen. Daher sind die Backlog-Posten als Messgröße besonders interessant.
Der Backlog-Posten setzt die innerhalb eines Sprints zu erledigenden Arbeitspakete mit den kurz vor Sprintende verbliebenen Aufgaben in Beziehung.
Das errechnete Verhältnis erlaubt bspw. eine Aussage darüber, inwieweit Störgrößen die Bearbeitung der geplanten Arbeitspakete behindert haben. Über eine längere Beobachtung mehrerer Sprints kann sich ein Muster abzeichnen, welche Aufgabenmenge innerhalb des Beobachtungszeitraums erledigt werden kann. Auf dieser Grundlage lassen sich die notwendigen Ressourcen abschätzen und es können Aussagen über die Struktur von Arbeitspaketen getroffen werden, was wiederum den erfolgreichen Ablauf zukünftiger Sprints unterstützt.
3.2.3 Cycle Time
Abweichungen vom Plan ermitteln
Die "Cycle Time" misst die Performance innerhalb eines Sprints, indem jeder Aufgabe innerhalb eines Sprints eine geschätzte Dauer zugeordnet wird. Im Anschluss wird gemessen, wieviel Zeit ein Mitarbeiter für eine bestimmte Aufgabe benötigt hat. Ein Vorteil dieser Messung liegt darin, dass sie sehr konkrete Aussagen über die Team-Performance erlaubt, die dann wiederum die Schätzung zukünftiger Sprints optimieren.
Gemessen wird die Cycle Time in sog. Cycle Time Charts (s. Abb. 3), in denen alle Aufgaben (Issues) oder Arbeitspakete (Cluster of Issues) mit ihrer tatsächlichen Dauer (Elapsed Time) eingetragen werden. In einer Übersicht lässt sich dann ableiten, dass einige Arbeitspakete im Verlauf des Betrachtungszeitraums länger, einige kürzer gedauert haben. Ein Median oder eine Kontrolllinie (Average) zeigt an, welche durchschnittliche Bearbeitungszeit als akzeptabel angestrebt wird und vergleicht diese mit der tatsächlich aufgewendeten durchschnittlichen Bearbeitungszeit (Rolling Average). Alle Arbeitspakete, die über dieser Linie liegen, können dann näher auf Gemeinsamkeiten und Muster analysiert werden, um Gründe für Fehleinschätzungen abzuleiten.
Abb. 3: Cycle Time Chart
Die Messung der Cycle Time über einen längeren Zeitraum ermöglicht es, häufige Fehlerquellen oder Blocker frühzeitig zu erkennen. Auf dieser Grundlage können die agilen Teams ihre Arbeitsweise optimieren und so die Bearbeitungsdauer der Arbeitspakete reduzieren.
Vorsicht ist bei einer eindimensionalen Betrachtung dieser Kennzahl geboten, i. S. v. "je kürzer, desto besser". Zwar stimmt es, dass eine kürzere Cycle Time eine bessere Performance bedeutet, da Aufgabenpakete in kürzerer Zeit erledigt wurden; dies lässt jedoch keine Rückschlüsse auf den Optimierungsgrad der Auslastung zu.
Die Praxis zeigt, dass das Management solche Teams als stärker einschätzt, die eine konstante Cycle Time liefern, da dies Rückschlüsse auf die schnelle Bearbeitung einer entsprechenden Anzahl an Arbeitspaketen zulässt. Diese Einschätzung beruht auf der Annahme, dass eine zu geringe Cycle Time darauf hindeutet, dass die Anzahl und/oder die Größe der Pakete nicht ausreichend waren. Im Cycle Time Chart ist dies durch eine möglichst geringe Distanz zwischen "Rol...
Dieser Inhalt ist unter anderem im Haufe Finance Office Premium enthalten. Sie wollen mehr?
Jetzt kostenlos 4 Wochen testen