Was ist ein Sprint Backlog?

Das Sprint Backlog ist eines der drei 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 Scrum Commitment des Sprint Backlogs. Es erzeugt Fokus für Dein Team und vermittelt ihm, warum Euer Sprint wichtig ist. Es ist ausreichend präzise und klar, ermöglicht jedoch gleichzeitig verschiedene Wege, es zu erreichen. Auf diese Weise haben die Entwickler Eures Scrum Teams genügend Freiraum es zu erreichen.

Es ist wichtig, dass Ihr Euch immer nur ein einziges Sprintziel setzt und keine Liste mit mehreren, verschiedener Ziele. Denn nur so kann sich Euer gesamtes Team auf das Erreichen dieses einen Ziel einschwören, damit 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 Euer Scrum Team Details und Klarheit. Denn nur weil Ihr wisst, was getan werden soll, bedeutet das ja noch lange nicht, dass Euch 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 unternehmen ist, um dieses Product Backlog Item (PBI) umzusetzen. Meistens 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 auch Hardware austauschen.

Um den Fortschritt beziehungsweise den Stand ihrer Tasks zu visualisieren, nutzen die allermeisten Scrum Teams ein Kanban Board mit den Spalten To Do, 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, werden 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 Burn-Down-Chart. Damit lässt sich der verbleibende Aufwand, um das Sprintziel zu erreichen, sehr gut visualisieren. Das Sprint Burn-Down-Chart ist allerdings genauso wenig durch den Scrum Guide vorgeschrieben wie ein Kanban Board. Es ist lediglich eine weit verbreitete (und sehr 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 ein Scrum Team während seines Sprints hinzulernt.

Dieser Inspect-&-Adapt-Prozess findet spätestens im Daily Scrum statt. Denn in diesem Scrum Event schauen die Entwickler Eures 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 sein neues Increment und erhält von den teilnehmenden Stakeholdern viele Ideen und Anregungen, wie es im nächsten Sprint weitermachen könnte.

Dein gesamtes Team ist von einer der dort aufkommenden Ideen vollauf begeistert und möchte diese Idee direkt im nächsten Sprint umsetzen.

Leider habt Ihr jedoch 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 dieser Feature-Idee 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 zusätzlich 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 oder Scrum Master) 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 Selbstorganisation und Verantwortung für die Umsetzung des Sprints innerhalb des Teams entwickeln können.