Scrum-Teams verwenden ein Scrum Board für die Aufgabenerledigung während eines Sprints. Es verfügt über mehrere Rubriken, in die die Aufgaben entsprechend ihres jeweiligen Stands platziert werden. Vom Kanban Board unterscheidet es sich in erster Linie in der Handhabung.
Scrum-Teams verwenden ein Scrum Board für die Aufgabenerledigung während eines Sprints. Es verfügt über mehrere Rubriken, in die die Aufgaben entsprechend ihres jeweiligen Stands platziert werden. Vom Kanban Board unterscheidet es sich in erster Linie in der Handhabung.
Scrum-Teams verwenden ein Scrum Board, um den Stand der Bearbeitung ihrer Aufgaben während eines Sprints abzubilden. Dafür eigenen sich sowohl physische als auch virtuelle Boards, beide haben Vor- und Nachteile. Jedes Scrum Board verfügt über mehrere Spalten für die verschiedenen Rubriken. In der einfachsten Version verfügt ein Board über die drei Spalten "Offen" (oder englisch To-do), "In Bearbeitung" (Doing) und "Erledigt" (Done).
Nachdem die Entwickler:innen im Sprint Planning entschieden haben, wie viele Backlog Items sie in das Sprint Backlog aufnehmen (d.h. im aktuellen Sprint abarbeiten möchten) platzieren sie diese Items auf dem Board, meistens in der Spalte "Offen". Entsprechend des Pull-Prinzips ziehen sich die Entwickler:innen Items bzw. Aufgaben und hängen sie in die Spalte "In Bearbeitung". Nach der Erledigung der Aufgabe wandert diese auf dem Board weiter nach rechts in "Erledigt"; anschließend nimmt man sich die nächste Aufgabe vor und hängt diese "In Bearbeitung".
Befinden sich alle Items auf dem Board ganz rechts in der Spalte "Erledigt", ist das Sprint-Ziel in der Regel erreicht, denn das Sprint Backlog ist damit abgearbeitet. Ist dieser Zustand deutlich vor dem Ende der Kadenz, also der Dauer des Sprints, erreicht, war das Sprint-Ziel zu wenig ambitioniert. Sind dagegen am Ende der Kadenz noch viele Aufgaben offen, war das Sprint-Ziel wahrscheinlich überambitioniert. Allerdings ist es nicht unbedingt notwendig, dass alle Items umgesetzt werden, um das von der:dem Product Owner:in festgelegte Sprint-Ziel zu erreichen.
Im Sprint Planning legt das Scrum Team als Sprint-Ziel fest: "Online-stellen der neuen Administrationsoberfläche". Die Entwickler:innen entscheiden, sich zwölf User Storys zu ziehen, die das Ziel unterstützen können. Bei einer geht es z.B. auf eine UX-Anpassung, um die Nutzererfahrung zu verbessern. Diese Story wird aus Zeitgründen nicht umgesetzt. Im Sprint Review entscheidet das Team gemeinsam mit Key Usern, dass man mit der neuen Oberfläche bereits arbeiten kann und diese veröffentlicht werden kann. Das Sprint-Ziel ist also erreicht, obwohl nicht alle Storys abgearbeitet wurden.
Ein Anti-Pattern (also ein für den Erfolg ungünstiger Lösungsansatz) wäre das Ziel "alle Storys umsetzen". Es geht bei Scrum darum Kundennutzen zu schaffen, statt darum Dinge möglichst vollständig abzuarbeiten.
Items, die entgegen der Planung im laufenden Sprint nicht erledigt werden können, werden in vielen Unternehmen einfach für den darauffolgenden Sprint eingeplant. Sie können auch wieder in das Product BacklogProduct BacklogProduct Backlog ist bei Scrum die Liste aller Anforderungen für ein zu erstellendes Produkt. geschoben werden und der:die Product Owner:in entscheidet, was mit ihnen geschieht. POs können Aufgaben niedriger priorisieren oder ganz aus dem Backlog werfen. Meistens stimmen sie dies mit dem Scrum Team oder weiteren Stakeholdern ab.
Die obigen Ausführungen zeigen, dass das Scrum Board vom Aufbau her dem Kanban Board ähnelt. Auch einem Scrum-Team kann das Standard-Layout mit lediglich drei Spalten genügen. Einige Scrum Boards beginnen mit einer Spalte, in der die Storys gesammelt werden ("Storys"). Bei Software-Entwicklungsprojekten gibt es häufig auch die Spalte "Testen" (Testing) (siehe Bild 1).
Der größte Unterschied zwischen Scrum Board und Kanban Board liegt in der Handhabung, wie "der Agilosoph" herausstellt: Während das Kanban Board den kontinuierlichen Fluss der Arbeit abbildet, zeigt das Scrum Board an, welche Fortschritte das Team im aktuellen Sprint macht. Wie bereits erwähnt, wandern die Aufgaben im Laufe des Sprints immer weiter nach rechts, bis sie am Ende im Idealfall alle dort hängen. Dagegen bildet das Kanban Board die Arbeit in einem ständigen Fluss ab, der nie versiegt: Von links kommen immer wieder neue Aufgaben, die bearbeitet werden müssen.
Sebastian Schneider warnt in seinem Beitrag Kanban: "3 typische Fehler, 3 wichtige Tipps" davor ein Board mit Prozessschritten zu überfrachten. Als Beispiel führt er ein Board mit sieben Rubriken an. Ein anderes Beispiel für das Überfrachten ist das Einrichten von Swimelanes für die einzelnen Teammitglieder oder für bestimmte Zuständigkeiten. Dabei hat jedes Teammitglied sein eigenes Backlog, was bei Teams mit geringer Reife dazu führen kann, dass es kaum zu Zusammenarbeit kommt.
Das Wichtigste haben die zwei Boards gemeinsam: Beide visualisieren den Fortschritt der Arbeit und sorgen für Transparenz und fördern die Selbstorganisation.
Scrum-Teams verwenden ein Scrum Board, um den Stand der Bearbeitung ihrer Aufgaben während eines Sprints abzubilden.
Das Scrum Team platziert die Sprint Tasks ganz links auf dem Board. Teammitglieder ziehen selbst ausgewählte Aufgaben in die Spalte "In Bearbeitung". Anschließend wandert diese auf dem Board weiter nach rechts in "Erledigt". Das Sprintziel ist erreicht, wenn alle Aufgaben auf dem Board ganz rechts hängen.
Der größte Unterschied zwischen Scrum Board und Kanban Board liegt in der Handhabung: Während das Kanban Board den kontinuierlichen Fluss der Arbeit abbildet, zeigt das Scrum Board an, welche Fortschritte das Team im aktuellen Sprint macht.
