Kanban und Scrum

Kindernothilfe e. V.
Referat Organisation und Datenmanagement
14 Scrum schreibt Schätzen und Geschwindigkeit vor
In Scrum wird von Teams erwartet, die relative Größe (= Arbeitsaufwand) für jedes Arbeitspaket, zu dessen
Abarbeitung sie sich verpflichten, zu schätzen. Indem wir die Größe jedes am Ende eines Sprints fertig
gestellten Arbeitspakets addieren, bekommen wir die Geschwindigkeit. Geschwindigkeit ist ein Maß für die
Kapazität – wie viel Dinge wir pro Sprint liefern können. Hier ein Beispiel eines Teams mit einer
Durchschnittsgeschwindigkeit von 8.
Zu wissen, dass die Durchschnittsgeschwindigkeit 8 ist, ist nett, denn dann können wir realistische
Vorhersagen darüber machen, welche Arbeitspakete wir in den kommenden Sprints fertig stellen können,
und können so realistische Auslieferungspläne machen.
In Kanban ist Schätzen nicht vorgeschrieben. Wenn Sie also Verpflichtungen eingehen müssen, müssen Sie
entscheiden, wie Vorhersagbarkeit sicherzustellen ist.
Einige Teams entscheiden sich dafür, Geschwindigkeit zu schätzen und zu messen, genau wie in Scrum.
Andere Teams ziehen vor, das Schätzen wegzulassen, aber versuchen, jedes Arbeitspaket in etwa gleich
große Teile zu zerlegen – dann können sie die Geschwindigkeit dahingehend messen, wieviele
Arbeitspakete pro Zeiteinheit fertig gestellt waren (zum Beispiel Features pro Woche). Einige Teams
gruppieren ihre Arbeitspakete in marktreifen Komponenten (Minimum Marketable Features – MMFs),
messen die durchschnittliche Durchlaufzeit pro MMF und nutzen das, um den Leistungsvertrag (Service-
Level-Agreements – SLAs) festzulegen – zum Beispiel „wenn wir uns einem MMF verpflichten, wird das
immer innerhalb von 15 Tagen geliefert“.
Es gibt alle Arten interessanter Techniken für Auslieferungsplanung und Verpflichtungsmanagement im
Kanbanstil – aber keine bestimmte Technik ist vorgeschrieben, also los und weg mit Google und versuchen
Sie andere Techniken, bis Sie die eine gefunden haben, die am besten zu Ihrem Kontext passt. Wir werden
wahrscheinlich in der nächsten Zeit einige „Best Practices“ auftauchen sehen.
15 Beide erlauben, an mehreren Produkten gleichzeitig zu arbeiten
In Scrum ist das Produktbacklog ein eher unglücklich gewählter Name, da er impliziert, dass alle
Arbeitspakete zum selben Produkt gehören müssen. Hier sind zwei Produkte, grün und gelb, jedes mit
seinem eigenen Produktbacklog und seinem eigenen Team:
- 26 -