In einem der letzten Artikel habe ich das Kanban-Board als Mittel zur Prozessvisualisierung vorgestellt. Ein Taskboard ist auch in einem Vorgehen nach Scrum häufig ein fester Bestandteil.
Wenn wir uns fragen, worin sich ein Scrum-Taskboard von einer Kanban-Tafel unterscheidet, lohnt es sich nochmal kurz die unterschiedliche Vorgehensweise bewusst zu machen.
Prozessorientierung gegenüber Produktorientierung
In Kanban wird Arbeit eher als ein kontinuierlicher Fluss verstanden: Arbeit kommt rein, wird verarbeitet und verlässt das Team wieder. Das Kanban-Board ist dabei eine dauerhafte Einrichtung, die regelmäßig an die Bedürfnisse des Teams angepasst und verbessert wird. Die Arbeit hat da in der Regel keinen produkthaften Charakter sondern spiegelt eben die Gesamtheit dessen wieder, was das Team tatsächlich macht.
Bei Scrum wird in sogenannten Sprints gearbeitet und das Taskboard soll nur die für den aktuellen Sprint ausgewählten Aufgaben wiederspiegeln: das Sprint Backlog. Für das Sprint Backlog wird im Rahmen des Sprint-Plannings aus dem Product Backlog geschöpft. Das Team wählt in diesem Rahmen die Aufgaben aus, die vom Product Owner am höchsten priorisiert wurden und von denen das Team glaubt, dass sie in den aktuellen Sprint passen könnten.
Man könnte sagen: beim Kanban-Board liegt der Fokus eher auf dem dauerhaften Gesamtprozess, in Scrum dagegen auf dem aktuellen Sprint-Ziel und der dafür umzusetzenden Produktanforderungen.
Wie Arbeit auf einem Scrum-Board organisiert wird
Betrachten wir ein typisches Scrum-Taskboard werden wir zunächst einmal erkennen, dass es einem Kanban-Board durchaus ähnelt.
So gibt es Spalten für die offenen ToDos, für Prozessschritte und für erledigte Arbeiten. Da es bei Scrum häufig um Entwicklungsarbeit geht, ist es wahrscheinlich, dass wir Spalten wie die Folgenden auf einem Scrum-Board finden:
- Offen
- In Bearbeitung
- Review / Überprüfen
- Erledigt
Darüber hinaus gibt es eine weitere Spalte, nämlich für das Product Backlog Item, um das es geht und das häufig als User Story dargestellt wird.
Nun spiegelt ein zuvor ausgewähltes Product Backlog Item ja in der Regel eine Produktanforderung und nicht unbedingt alle dafür erforderlichen Arbeiten wieder. Die Idee ist es, die Arbeit an der jeweiligen Anforderung in einzelne Aufgaben zu teilen, die dann an der Tafel neben der zugehörigen Anforderung aufgehängt und von Spalte zu Spalte weitergezogen werden, während die Karte mit der Anforderung oder User Story an Ort und Stelle verbleibt. Eine Story gilt dann als erledigt, wenn alle zugehörigen Karten erledigt sind.
Diese Task-Karten können von den Teammitgliedern im Verlauf eines Sprints beliebig erweitert oder ausgetauscht werden, wenn sie neue Erkenntnisse zur Erfüllung einer Anforderung erlangen. Die Aufgaben müssen aber für die Umsetzung einer Anforderung notwendig sein. Das ist eine wichtige Einschränkung, denn der eigentliche Scope eines Sprints wird zu Beginn festgelegt und darf dann nicht mehr verändert werden. Dafür ist ein Sprint ja in der Regel recht kurz.
So ermöglicht das Scrum- oder Sprint-Board eine Fokussierung auf das Wesentliche: das Sprintziel.
Den zweiten Schritt gehen