© saicle/Shutterstock.com
Kolumne: A² - alles Agile

Kolumne: A² - alles Agile


Sowohl Scrum als auch Kanban zielen unter anderem darauf ab, die Kommunikation im Projekt in den Vordergrund zu stellen. Das erklärte Ziel dabei ist die Nutzung derselben, um das Produkt und den Prozess zu verbessern. Zielgerichtete Kommunikation und ein festgelegter Prozess allein können diese Anforderung nicht erfüllen. Hierzu muss das Entwicklungsteam wissen, an welchen Prozessschritten es Verbesserungen und Optimierungen durchführen kann oder muss. Um dem Team das zu ermöglichen, bieten Scrum und Kanban verschiedene Metriken an, die den Prozess bzw. einzelne Prozessschritte entsprechend verschiedener Messgrößen abbilden. Erst diese Metriken befähigen die Teams, ihre Arbeit und ihre Arbeitsqualität zu bewerten bzw. zu visualisieren. Mithilfe dieser Visualisierung können Verbesserungen gezielt herausgearbeitet und angewendet werden.

Neben der Grundlage für Verbesserungen dienen diese Metriken auch als wichtige Erfahrungsgrundlage für Sprint- oder Releaseplanungen. Ist ein Scrum- oder Kanban-Prozess erst wenige Wochen (in Ausnahmen wenige Monate) im Team etabliert, werden Sprint- oder Releaseschätzungen noch sehr ungenau sein. Im Lauf der Zeit sammelt das Team mittels der Metriken und deren Kennzahlen wichtige Erkenntnisse, um Sprints immer zuverlässiger abschätzen zu können. Zum Beispiel wird das Team im Lauf der Zeit eine sehr genaue Anzahl an Story Points kennen, die zuverlässig in einem Sprint abgearbeitet werden können. Hierfür ist es allerdings unabdingbar, dass die Sprintlänge gleich bleibt und nicht schwankt.

In Scrum hervorzuhebende Metriken sind das Burn-Down-Chart und die Team Velocity. Kanban ohne das Cumulative-Flow-Diagramm und die Erfassung der Durchlaufzeit zu nutzen, ist nicht ratsam und sollte vermieden werden. Neben diesen vier hier erwähnten Metriken bieten Scrum und Kanban weitere Metriken an, die erhoben werden können. Zu nennen sind etwa die Failure Load und die Blockadenanalyse in Kanban.

Scrum: Burn-Down-Chart

In Scrum gibt das Team am Anfang des Sprints ein Versprechen ab, bestimmte Features/Stories im Laufe des Sprints in der priorisierten Reihenfolge abzuarbeiten und in einem fehlerfreien Product Increment zu liefern. Gegen Ende des Sprints kann es sein, dass das Team zu der Erkenntnis kommt, dass nicht alle Features (fehlerfrei) geliefert werden können. In einem solchen Fall muss das Team für sich und folgende Sprints festhalten, dass das Commitment zu groß war.

Um den Fortschritt während des Sprints angemessen analysieren ...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang