Was ist ein Scrum Board?

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).

Wie arbeitet man mit einem Scrum Board?

Nachdem die Entwickler:innen im Sprint PlanningSprint PlanningIm Sprint Planning plant das Scrum Team zu Beginn eines Sprints das Sprint-Ziel sowie das angestrebte Produktinkrement und legt das Sprint Backlog fest. Darauf aufbauend erstellt das Entwicklungsteam den Ablaufplan für den Sprint. 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 nach 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 DauerDauerDauer ist die Zeitdifferenz zwischen Endzeitpunkt und Anfangszeitpunkt einer Aktivität (z.B. Aufgabe, Vorgang, Projekt). Dauern können in kalendarischen Zeiteinheiten oder in Einheiten der Arbeitszeit angegeben sein. des Sprints, erreicht, war das Sprintziel zu wenig ambitioniert. Sind dagegen am Ende der Kadenz noch viele Aufgaben offen, war das Sprintziel 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.  

Beispiel für ein erreichtes Sprint-Ziel trotz Item im Sprint Backlog

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 ReviewSprint ReviewIm Sprint Review prüft das Scrum Team – ggf. mit weiteren, vom Product Owner eingeladenen, Stakeholdern – am Ende eines Sprints den erzielten Fortschritt und erarbeitet die Grundlagen für das folgende Sprint Planning . Der Scrum Guide betont, dass das Sprint Review informellen Charakter hat und nicht der Berichterstattung über den Projektstatus dient. entscheidet das Team gemeinsam mit Key Usern, dass man mit der neuen Oberfläche bereits arbeiten kann und diese veröffentlicht werden kann. Das Sprintziel 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 Stories umsetzen". Es geht bei Scrum darum KundennutzenKundennutzenDer Kundennutzen ist die Gegenleistung für den vom Kunden bezahlten Preis. Jedes Produkt und jede Dienstleistung muss deshalb danach beurteilt werden, welchen Nutzen es bei seinen potentiellen Kunden realisiert. Beispielsweise erbringt ein PKW für sich genommen noch keinen Kundennutzen. Ohne die entsprechende Infrastruktur (Straßen, Tankstellen usw.) ist er wertlos. 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.

Worin unterscheidet sich das Scrum Board vom Kanban Board?

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).

Scrum Board mit fünf Rubriken
Bild 1: Scrum Boards mit Spalten für Storys und Testen findet man häufig bei Entwickler-Teams  
© bakhtiarzein - stock.adobe.com

 

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.

Um das gesamte Potenzial eines Kanban Boards auszuschöpfen, sollte ein Team die sechs Kanban Kernpraktiken konsequent umsetzen. Andreas Ulrich erklärt, wie das in der Praxis funktioniert.

Boards werden unterschätzt, sagt Andreas Ulrich.

Kommentar

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.

Können Sie Kanban? Sebastian Schneider zeigt Ihnen drei typischer Fehler auf und gibt Ihnen nützliche Tipps an die Hand, um diese künftig zu vermeiden.

Sebastian Schneider liebt das Arbeiten mit Boards. Hier teilt er seine Best Practises.

 

Bewertungen

Gesamt
Bewertungen 1
Kommentare 0

Das könnte Sie auch interessieren

Was ist ein Scrum Board?

Scrum-Teams verwenden ein Scrum Board, um den Stand der Bearbeitung ihrer Aufgaben während eines Sprints abzubilden. 

Weitere Informationen

Wie arbeitet man mit einem Scrum Board?

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.

Weitere Informationen

Worin unterscheidet sich das Scrum Board vom Kanban Board?

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. 

Weitere Informationen