4.8 12 Votes
Artikel-Rating

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:

  • Erstens besitzt das Sprint Backlog ein Sprintziel, das allen Teammitgliedern vermittelt, warum der aktuelle Sprint wichtig ist.

  • Zweitens beinhaltet es die für den Sprint ausgewählten Product Backlog Items, die erledigt werden müssen, um das Sprintziel zu erreichen. (In der Regel handelt es sich dabei um User Stories.)

  • Drittens ist das Sprint Backlog ein Plan, wie die ausgewählten Product Backlog Items bzw. das Sprintziel erreicht werden sollen.

Das Sprintziel des Sprint Backlogs

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 kollaboratives Arbeiten entsteht.

  • Hier erfährst Du mehr über das Sprintziel und worauf Ihr achten solltest, wenn Ihr es formuliert.

Der Plan des Sprint Backlogs

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.

Kanban-Boards

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.

Sprint Backlog
  • Während die Status ToDo, Doing & Done für Tasks vollkommen ausreichend sind, sind für User Stories, Features oder sogar Epics diverse andere Kanban-Status denkbar. Mehr dazu findest Du in meinem Arkel It’s Time to Learn, Baby!

Sprint Burndown Charts

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.

Grundsätzlich gibt es beim Sprint Burndown Chart zwei verschiedene Varianten, den Aufwand zu visualisieren. Entweder zeigt das Burndown Chart den verbleibenden Aufwand in Stunden oder in Story Points.
0
Welche Variante nutzt Ihr für Euer Sprint Burndown Chart? Und welche Erfahrungen habt Ihr damit gesammelt?x

Beispiel für ein Sprint Burndown Chart

Aktualisierung des (ursprünglichen) Plans

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.

Unvollständiger Plan zu Beginn des Sprints

Vielleicht hast Du Dich schon einmal gefragt, ob Dein Scrum Team einen Sprint beginnen “darf”, wenn der Plan beziehungsweise das Sprint Backlog nach dem Sprint Planning noch nicht (komplett) fertig ist. Die eindeutige Antwort dazu ist: Ja!
0
Seid Ihr schon einmal mit viel Unklarheit in den Sprint gestartet? Was waren Eure Erfahrungen damit?x

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

  • Ihr habt Euch im Sprint Planning zumindest auf ein Sprintziel geeinigt! (Damit klar ist, was Euer Produkt am Ende des Sprint können soll.)

  • Es existieren zumindest für die ersten zwei bis drei Tage des kommenden Sprints ausreichend klare Aufgaben.

Beispiel für ein unvollständiges Sprint Backlog

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

Action Items im Sprint Backlog

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.

Das Sprint Backlog gehört den Entwicklern

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.

  • Sollte Euer Product Owner wiederholt, Aufgaben, ToDo’s, Bugs oder andere Dinge “in Euer Sprint Backlog schieben”, solltet Ihr darüber nachdenken, den laufenden Sprint abzubrechen und (als Erste-Hilfe-Maßnahme) Eure Sprint-Länge zu verkürzen

Fazit zum Sprint Backlog

Soviel von meiner Seite zum Sprint Backlog. Hast Du noch Fragen, Ideen, Anregungen oder Kritik zu diesem Beitrag? Dann hinterlasse mir doch einen Kommentar hier unten auf der Seite. Ich freu mich auf Dein Feedback!