Scrum Board
Was ist ein Scrum Board (aka Scrum Task Board)?
Auf dem Scrum Board oder Scrum Task Board werden die Tätigkeiten/Tasks für den Sprint organisiert. Für viele Entwickler reicht ein Sprint Backlog aus Sprint Ziel und ausgewählten Backlog-Items alleine nicht aus, im gemeinsam die Verantwortung für den Sprint zu übernehmen.
Deswegen brechen sie die Arbeit im Scrum Board in Tätigkeiten/Tasks zu Sprint Ziel und Backlog-Items runter und organisieren sie so, dass sie sich gemeinsam effektiv zu den Sprintvorhaben abstimmen können.
Klicken Sie auf den unteren Button, um den Inhalt von Spotify zu laden.
Bei der Einführung von Scrum herrscht in Organisation nicht selten die Meinung, Scrum könne so viel anders nicht sein: “Unsere Arbeit ist doch die gleiche, wie früher”. Oft ist man sich zu diesem Zeitpunkt noch nicht bewusst, dass Scrum den Teams in ihrer engen Zusammenarbeit sehr viel mehr Verantwortung auferlegt. Dies bringt neue Herausforderungen mit sich. Zugleich entstehen neue Möglichkeiten, sich als Team zu koordinieren und auszutauschen und dadurch signifikant andere Ergebnisse zu erzielen, als dies zuvor der Fall war. Das Task Board stellt eine Möglichkeit dar, wie sich Teams in ihrer eigenverantwortlichen Zusammenarbeit im Sprint organisieren können, um den neuen Anforderung gerecht zu werden.
In meiner Podcast-Folge “Task Board” erkläre ich, wie das Scrum Board im Sprint helfen kann, dieses neue Level an Verantwortung zu übernehmen und zu einer neuen Arbeitsweise zu kommen. Darüber hinaus gebe ich Tipps für eine effektivere Nutzung des Task Boards im Alltag.
Scrum – ein neuer Anspruch an die Entwickler
Der neue Anspruch an das Team liegt im Kern in der Eigenverantwortlichkeit des Arbeitens. Das Entwicklungsteam besteht aus Personen, die gemeinsam alle Fähigkeiten besitzen, um in enger Zusammenarbeit eigenverantwortlich zu agieren und Ergebnisse zu schaffen – und das Sprint für Sprint. Ziele werden nicht von Vorgesetzten oder dem Product Owner (PO) vorgelegt, sondern gemeinsam definiert. Ein Ziel wird demnach auch nicht von einer Person allein getragen, sondern gemeinsam von allen Teammitgliedern. Der Forecast an Arbeit soll sich für alle dementsprechend gut anfühlen, sodass jeder “commited” ist, sein Bestes zu geben. Das Verhältnis zwischen Team und Product Owner lässt sich als eine Art “Deal” beschreiben, den beide Parteien miteinander eingehen. Konkret bedeutet das für das Team, den Product Owner stets in die Arbeit einzubinden. Dazu gehört, dass es sich bei Fragen oder relevante Änderungen rechtzeitig und proaktiv an ihn wendet, sodass es keine Überraschungen für den Product Owner selbst oder gar für die Stakeholder gibt. Ein Mikromanagement seitens des Product Owner sollte demnach nicht notwendig sein. Dies ist für beide Parteien vorteilhaft: Der Product Owner trägt die Product Ownership und konzentriert sich auf das Stakeholdermanagement und das Product Backlog. Das Team wurde so gewählt, dass eigenverantwortliche Entscheidungen gefällt werden können und auch müssen, denn das Team weiß am besten über die eigene Arbeit Bescheid.
Vom Sprint Backlog zum Scrum Board
Das Sprint Backlog kann als Ergebnis dieses Deals bezeichnet werden. Das Sprint Backlog ist laut Scrum Guide ein ausreichend detaillierter Plan, den die Entwickler im Blick hat und Schritt für Schritt zur Erreichung des Sprint-Ziels ausgestaltet, um den Fortschritt innerhalb des Sprints (im Daily) erkennen zu können. Es wird während des Sprints vom Team angepasst und entwickelt sich daher mit fortschreitender Arbeit weiter. Dabei ist es die Verantwortung des Teams, zu jeder Zeit im Sprint einen Überblick über die Aufgaben und die Erreichung des Sprint-Ziels zu haben. Darüber hinaus muss das Team im Blick haben, ob es Hilfe vom PO benötigt oder, ob Nachjustierungen vorzunehmen sind. Aus dieser Verantwortung heraus entsteht in vielen Teams die Notwendigkeit und auch der Wunsch, sich neben dem Sprint Backlog eine detailliertere Möglichkeit der Arbeitskoordination zu schaffen.
Ein Task Board ist in Scrum nicht zwingend notwendig, jedoch macht es in den meisten Fällen Sinn, da die Übersichtlichkeit und Transparenz anhand der Backlog Items alleine nicht immer gegeben ist. Ob ein Task Board benötigt wird oder nicht, kann man als Scrum Master oder Agile Coach mit folgenden fünf einfachen Fragen mit den Entwicklern reflektieren.
- Ist jedem klar, was in diesen Sprint gehört und was nicht?
- Ist jedem klar, woran als nächstes gearbeitet werden soll?
- Ist jedem klar, woran die anderen Teammitglieder arbeiten?
- Ist jedem klar, wo es Blockaden in der Arbeit gibt?
- Kann das Sprint-Ziel erreicht werden oder müssen Gegenmaßnahmen ergriffen werden?
Sollte jedes Teammitglied auf alle fünf Fragen ohne große Mühe mit Ja antworten können, ist ein Task Board nicht unbedingt notwendig. Sind diese Fragen nicht für alle Teammitglieder einfach zu beantworten, so ist ein Task Board zu Unterstützung der Übersichtlichkeit und Transparenz sinnvoll.
Das Scrum Board aka Scrum Task Board
Das Task Board hilft, genau auf diese fünf Fragen eine Antwort zu finden – schnell und unkompliziert. Es enthält neben den priorisierten Backlog Items eine weitere Ebene an Tätigkeiten, die mit einem einfachen Status gekennzeichnet sind: “to do”, “in Arbeit” oder “done”. Das Team hat damit die Möglichkeit, diese weitere Ebene an Tasks jederzeit zu überblicken.
Ein Scrum Board schafft die notwendige Übersicht, die das Team während des Sprints benötigt. Ich erachte es nicht als sinnvoll, anstelle des Task Boards lediglich Backlog Items weiter herunterzubrechen, da das meiner Erfahrung nach nicht für eine bessere Übersicht sorgt, sondern das Ganze aufgrund der Anzahl an Items eher komplexer werden lässt. Eine sinnvolle Anzahl von fünf bis zehn Backlog Items, die dann wiederum im Task Board in einzelne Tätigkeiten aufgebrochen werden, halte ich für eine bessere Option. Dieses Vorgehen wahrt den Überblick und hilft zu koordinieren, wie die Backlog Items weiter angegangen werden sollen.
Neben der Übersichtlichkeit bietet das Task Board den weiteren Vorteil, die Arbeit für das gesamte Team transparent zu machen. Dies ist zum einen für die Koordination sehr hilfreich, zum anderen fördert es die Zusammenarbeit und ermöglicht es dem Team, sich gegenseitig Hilfe anzubieten.
Definition der Tasks
Tasks sind die Tätigkeiten, die das Team angehen soll, um ein Backlog Item zu finalisieren. Diese werden am Anfang des Sprints festgelegt. Es geht nicht darum, alle Tasks von Anfang an vollständig zu erfassen, sondern vielmehr, sie soweit zu erfassen, dass das Team beginnen kann. Sie können aber auch im Nachhinein noch hinzugefügt werden, falls im Verlauf der Arbeit auffällt, dass etwas vergessen wurde. Dies ist nicht selten der Fall. Es kommt auch vor, dass Teams das Gefühl haben, Items nicht ohne weiteres in Tasks herunterbrechen zu können. “Wir können nicht in Tasks herunterbrechen, weil wir zuvor noch Inhalte aufarbeiten müssen”. Diese aufzuarbeitenden Inhalte sind aber keine Show-Stopper, sondern können ebenfalls als Task betrachtet und mit aufgenommen werden – denn genau so erfolgt die Definition der Tasks.
Sind alle Tasks erledigt und mit dem Status “Done” gekennzeichnet, so kann auch an dieser Stelle noch einmal hinterfragt werden, ob alles bedacht wurde. Nicht selten führt ein solches Gespräch dazu, dass die Definition of Done angepasst wird.
Zuordnung von Tasks sorgt für Transparenz
Das Task Board bringt viele Vorteile: Neben der Übersichtlichkeit und der Transparenz in der Koordination von Arbeit kann es dem Team auch helfen, sich gegenseitig zu unterstützen. Dadurch, dass die einzelnen Tasks mit Namen versehen werden, ist schnell erkenntlich, wer sich um was kümmert. Hilfe kann so gezielt angeboten werden. Ich rate ich jedoch dazu, nicht allzu früh mit der Zuordnung zu beginnen, denn Namen auf Taks können sich auch negativ auf die Team-Dynamik auswirken. Ebenso schnell wie wir durch die Zuordnung von Namen erkennen, wo Hilfe benötigt wird, so können Namen auf Tasks auch dazu führen, dass Teammitglieder die Tätigkeiten wieder isoliert betrachten und nicht mehr als Team. Mein Tipp ist an dieser Stelle, die Namen nicht allzu früh zuzuordnen, da sich sonst evtl. die Teammitglieder sich zu spät “helfen”. Ich würde dazu raten, Namen erst auf die Tasks zu schreiben, wenn ein Task in Bearbeitung ist. So kann dieser isolierten Betrachtung vorgebeugt und ein offenes Aushelfen zu forciert werden.
Nutzung des Scrum Boards
Bei der Definition der Inhalte eines Scrum Boards geht um die Beantwortung folgender Sinnfrage: Haben wir die Plattform die wir brauchen, um uns auszutauschen? An dieser Stelle möchte ich ein paar Tipps und Ideen geben, wie ein Task Board gestaltet werden kann
- Durch das Hinzufügen eine zeitlichen Komponente kann der zeitliche Umfang der Tasks festgehalten werden. Festgelegt werden diese durch Schätzungen der Teammitglieder. Der Vorteil: Zeitliche Komponente regen Gespräche an und erhöhen die Qualität dahingehend, als dass Schätzungen offen diskutiert werden können, sollten Meinungen dahingehend auseinander gehen.
- Es kann auch hilfreich sein, ein Task maximal 24 h auf “Done” verweilen zu lassen und die Tasks dementsprechend “fein” herunterzubrechen. Der Vorteil: Das Team stellt sicher, dass es schnell Informationen erhält. Beispielsweise kann ein Teammitglied sich mehrere Tage in einer Testphase befinden, ohne dass eine hilfreiche Information an das Team weitergeleitet wird. Dadurch, dass ein Ergebnis nach 24 Stunden sichtbar gemacht werden muss, können schnell Informationen gewonnen und ggf. Hindernisse identifiziert werden.
- Es kann von Nutzen sein, die Tasks täglich zu markieren. Der Vorteil: Durch einfaches Aufkleben von Punkten kann man sichtbar machen, welche Tasks besonders lange bearbeitet wurden. Auch so können Hindernisse schnell aufgedeckt werden.
- Bei besonders langen Sprints mach ein Backlog Item oder Story Kick-off Sinn. Das Team bricht dabei unten stehende Items erst dann herunter, wenn tatsächlich angefangen wird zu arbeiten. Der Vorteil: Bei ausgedehnten Sprints geht der Fokus dennoch nicht verloren.
Es gibt unterschiedlich Möglichkeiten, wie ein Task Board gestaltet und genutzt werden kann. Wichtig ist meiner Meinung nach vor allem, dass eine aktive Ausgestaltung an die individuellen Bedürfnisse des Teams erfolgt. Dafür müssen nicht unbedingt Tools eingesetzt werden. Ich tendiere eher dazu, mit einer ganz einfachen Variante zu beginnen (z.B. mit Papier, Stift und Klebepunkten). Sobald sich das Team mit dem Task Board wohl fühlt, kann natürlich über ein unterstützendes Tool nachgedacht werden.
Zusammenfassung
Es wird oft unterschätzt, dass das selbstorganisierte Entwicklungsteam in Scrum eine größere Verantwortung hat als in vielen anderen Arbeitsweisen. Das Sprint Backlog ist der Plan, nachdem das Team im Sprint vorgeht. Das Task Board ist eine detaillierte Darstellung zur Koordination und Organisation der einzelnen Tätigkeiten, mit dem das Team seiner eigenverantwortlichen Arbeitsweise gerecht wird. Es gibt zahlreiche Möglichkeiten, wie man als Team das Task Board ausgestalten und nutzen kann.
Ich hoffe, ich konnte dir mit meinen Tipps neue Impulse und Ideen für die Nutzung und Gestaltung des Task Boards geben. Hast du Fragen oder Anmerkungen? Ich freue mich immer über ein Feedback.
Ergänzende Perspektive in der Nachlese
Eine ergänzende Perspektive zu dieser Folge gibt Johannes Schartau von Holisticon im Nachlese Interview zu dieser Folge.
Möchtest du Scrum für deine Zwecke effektiver nutzen?