Kolumne: A² - alles Agile

Scrum vs. Kanban – Teil 1: Scrum
Kommentare

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 zu können, wird das Burn-Down-Chart herangezogen. Es gibt tagesgenau Auskunft über die noch zu leistende Arbeit. Die x-Achse des Burn-Down-Charts bildet hierbei die Tage ab, die y-Achse die noch zu leistende Arbeit in Tagen oder Mannstunden. Hierfür schätzt jedes Teammitglied täglich den Restaufwand seiner noch abzuarbeitenden Tasks. Burn-Down-Charts liefern von Tag zu Tag genauere Aussagen über die Restaufwände der Stories. Das Team kann hierdurch Risiken besser erkennen und zielgerichteter planen.

PHP Magazin

Entwickler MagazinDieser Artikel ist im PHP Magazin erschienen. Das PHP Magazin deckt ein breites Spektrum an Themen ab, die für die erfolgreiche Webentwicklung unerlässlich sind.

Natürlich können Sie das PHP Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Dadurch, dass das Team seinen Fortschritt eigenverantwortlich misst und sich durch das eigene Commitment gebunden fühlt, organisiert es selbstständig die Einhaltung der Planung. Durch diese Eigenplanung und der nicht von außen aufoktroyierten Projekt-/Sprint-Planung, ist die zuverlässige Lieferung der stabilen Product Increment erheblich gestiegen.

Das Entwicklungsteam wird sich nie auf den Standpunkt einer unrealistischen Planung zurückziehen können, da es selbst geplant hat. Für den Product Owner hat das den Vorteil, dass er sich auf die Aussage des Teams verlassen kann und die Product Increments zuverlässig geliefert werden. Das Team, der Product Owner und die Stakeholder vertrauen ihren Aussagen und Versprechen von Sprint zu Sprint mehr, was die Langzeitmotivation erheblich steigert und stabilisiert.

Burn-Down-Charts können wie in Abbildung 1 und 2 dargestellt aussehen. In Abbildung 1 ist ein Under Commitment zu sehen: Das heißt, das Team wird weit schneller mit den Aufgaben fertig als gedacht bzw. als der Sprint dauert. Für zukünftige Sprints kann das bedeuteten, dass Schritt für Schritt die Commitments erhöht werden. Abbildung 2 bildet den entgegengesetzten Fall ab: Hier ist ersichtlich, dass das Team seinem Versprechen nicht gerecht werden wird. Also muss das entsprechend in der Retrospektive beleuchtet werden, um für folgende Sprints entsprechende Gegenmaßnahmen ableiten zu können. Abbildung 2 verdeutlicht ebenfalls eine unzureichende Anfangsbewertung der User Stories hinsichtlich der Story Points, siehe Tag zwei und Tag sechs.

 

Scrum: Team Velocity

Für eine zuverlässige Releaseplanung muss man bewerten können, welche Entwicklungsgeschwindigkeit das Team pro Sprint hat. Um die Team Velocity vergleichen zu können, ist es unerlässlich, die Einflussparameter, wie Teamgröße oder Sprintlänge, nicht zu verändern. In der Praxis ist das aber leider nicht immer möglich. Für diesen Bericht werden jene User Stories und deren Story Points herangezogen, die abgeschlossen und geliefert wurden. Die Abnahme des Product Owners darf ebenfalls nicht fehlen.

Am Ende eines jeden Sprints werden die Story Points auf der y-Achse des Team-Velocity-Diagramms abgetragen; die x-Achse zeigt die einzelnen Sprints auf. Treten in diesem Diagramm große Abweichungen auf, bietet die Retrospektive eine gute Möglichkeit, Gründe hierfür zu beleuchten und Gegenmaßnahmen zu ergreifen.

Durch eine konsequente Erfassung der Entwicklungsgeschwindigkeit kann das Team am Anfang eines Sprints zusammen mit dem Product Owner und den bereits geschätzten Story Points zur Umsetzung der gewünschten User Stories eine verlässliche Aussage treffen, ob diese im Sprint geliefert werden können. Das Entwicklungsteam hat auf Grund dieser Erfahrungswerte eine gute Argumentationsgrundlage gegenüber dem Product Owner. Der Product Owner kann so mit Sicherheit abschätzen, welche User Stories er wie zu priorisieren hat, um sie definitiv im nächsten Product Increment geliefert zu bekommen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -