Was ist ein Sprint Backlog?

Das Sprint Backlog ist eines der drei sogenannten Scrum Artefakte. Genauso wie beim Product Backlog und beim Increment besteht sein Hauptzweck darin, Transparenz zu erzeugen. Und zwar Transparenz über die noch zu erledigende Arbeit, um das Sprintziel zu erreichen. Um diesen Zweck zu erfüllen, besteht das Sprint Backlog aus drei verschiedenen Elementen:

Das Sprintziel ist das zum Sprint Backlog dazugehörige Scrum Commitment. Es erzeugt Fokus für Dein Team und vermittelt ihm, warum der Sprint wichtig ist. Es ist ausreichend präzise und klar, ermöglicht aber verschiedene Möglichkeiten, es zu erreichen, damit die Entwickler Deines Scrum Teams genügend Freiraum dabei haben, es zu erreichen.

Es ist sehr wichtig, dass es nur ein einziges Sprintziel gibt und keine Liste mehrerer, verschiedener Ziele. Nur so kann sich Dein gesamtes Team auf das Erreichen dieses einen Ziel einschwören, sodass Kollaboration entsteht.

Das Sprint Backlog ist mehr als eine “lose Ansammlung” von User Stories, die erledigt werden sollen. Damit es wirklich einen konkreten Plan darstellt, benötigt Dein Scrum Team mehr Details und Klarheit. Denn nur weil Ihr wisst, was getan werden soll, bedeutet das ja noch lange nicht, dass auch klar ist, wie Ihr das Sprintziel erreichen möchtet.

Üblicherweise werden dazu an jede für den Sprint ausgewählte User Story Tasks notiert, die benennen, was exakt zu tun ist, um das Product Backlog Item (PBI) umzusetzen. Meist sind das Tasks wie Datenbank aktualisieren, UI/UX testen, Repository aktualisieren, Code schreiben und dergleichen mehr. Aber auch andere Tasks sind möglich, beispielsweise Informationen aus dem Marketing besorgen oder Hardware austauschen.

Um den Fortschritt beziehungsweise den Stand ihrer Tasks zu visualisieren, nutzen die allermeisten Scrum Teams ein Kanban Board mit den Spalten ToDo, Doing und Done. Auf diese Weise lässt sich sehr schnell erfassen, wie es um die Erreichung des Sprintziels bestellt ist.

Kanban Boards und andere Kanban Praktiken wie WIP-Limits sind zwar eine weitverbreitete Praxis in Scrum Teams, sind jedoch nicht vom Scrum Guide vorgeschrieben. Sollte Dein Team also eine andere Möglichkeit nutzen, um den Stand seiner Arbeit zu visualisieren, ist das vollkommen in Ordnung.

Viele Scrum Teams ergänzen ihr Sprint Backlog mit einem sogenannten Sprint Burndown Chart. Damit lässt sich der verbleibende Aufwand, um das Sprintziel zu erreichen, sehr gut visualisieren. Das Sprint Burndown Chart ist allerdings genauso wenig durch den Scrum Guide vorgeschrieben wie ein Kanban Board. Es ist lediglich eine weit verbreitete (und nützliche) Praktik vieler Scrum Teams.

Das Sprint Backlog ist kein fester Plan, der bis zum Ende eines Sprints in jedem Fall durchgezogen werden muss oder soll. Angesichts der hohen Komplexität, mit der ein Scrum Team konfrontiert ist, wäre das auch gar nicht möglich. Vielmehr ist es (wie auch das Product Backlog) ein lebendes Artefakt, das angepasst und aktualisiert wird, sobald das Scrum Team während des Sprints hinzulernt.

Dieser Inspect-&-Adapt-Prozess findet spätestens im Daily Scrum statt. Denn in diesem Scrum Event schauen die Entwickler des Scrum Teams auf das Sprint Backlog, um erstens zu prüfen, wie es um die Erreichung des Sprintziels bestellt ist, und zweitens die Arbeit für die nächsten 24 Stunden zu planen.

Damit das Daily Scrum seinen Sinn & Zweck erfüllen kann, ist es natürlich wichtig, dass das Sprint Backlog spätestens kurz zuvor von jedem beteiligten Entwickler auf den aktuellen Stand gebracht wurde.

Zwei Bedingungen solltet Ihr dabei jedoch beachten, wenn Ihr mit einem “unfertigen” Sprint Backlog in den Sprint starten müsst/möchtet:

Stell Dir folgende Situation vor: In der Sprint Review präsentiert Dein Team das neue Increment und erhält Ideen und Anregungen, wie es im nächsten Sprint weitermachen könnte. Dein gesamtes Team ist von einer der aufkommenden Ideen vollauf begeistert und Ihr möchtet sie direkt im nächsten Sprint umsetzen. Leider habt Ihr noch keinen blassen Schimmer, wie Ihr das neue Feature umsetzen könntet.

Nun wäre es wenig agil, diese Idee aus der Review als User Story ins Product Backlog aufzunehmen, dann zu refinen und erst in einem späteren Sprint umzusetzen, falls Ihr wirklich alle der Meinung seid, dass es das Wichtigste und Sinnvollste ist, was Ihr im nächsten Sprint umsetzen könntet.

Viel besser ist es, wenn Ihr Euch die Umsetzung dieses Features als Sprintziel setzt, und im Sprint Planning zumindest soviel Klarheit erreicht, dass Ihr mit der Arbeit an diesem Feature beginnen könnt. (Natürlich ist diese Situation nicht der Optimalfall, aber hier schlägt der potenzielle Wert für Eure Nutzer die Notwendigkeit ausreichender Klarheit.)

Neben den Aufgaben, die zur Erreichung des Sprintziels zu erledigen sind, kannst Du mit Deinem Scrum Team darüber hinaus Action Items aus Eurer Sprint Retrospektive festhalten. Der große Vorteil dieser Vorgehensweise liegt darin, dass Ihr als Team in Eurem Daily Scrum täglich an den Maßnahmen, die Ihr Euch in der Retrospektive vorgenommen habt, vorbeikommt.

Genauso wie das Product Backlog dem Product Owner gehört, gehört das Sprint Backlog zur Scrum Rolle des Entwicklers. Das bedeutet, dass niemand (auch kein Product Owner) zusätzliche Aufgaben, Bugs, etc. in das Sprint Backlog verschieben darf oder Aufgaben daraus löschen kann.

Das ist in der täglichen Anwendung von Scrum ein leider oft vergessener (oder geflissentlich übergangener) Aspekt des Sprint Backlogs. Für die erfolgreiche Umsetzung von Scrum hat es jedoch einen gravierenden Einfluss. Denn nur dann, wenn die Entwickler Deines Scrum Teams sich wirklich auf das Sprintziel und die Umsetzung des Plans fokussieren können, werden sich Selbstmagement und Verantwortung für die Umsetzung des Sprints innerhalb des Teams entwickeln können.