4.8 16 Votes
Artikel-Rating

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:

  • 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 das Sprintziel erreicht werden soll.

Inhaltsverzeichnis

Das Sprintziel des Sprint Backlogs

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.

  • Erfahre 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 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.

Kanban Boards

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.

  • Während die Status To Do, Doing & Done für Tasks in der Regel vollkommen ausreichend sind, kann es sinnvoll sein, Euren Arbeitsprozess für User Stories und Features detaillierter zu regeln. Wirf einen Blick in meinen Artikel Mit Kanban den Workflow verbessern & Prozesse optimieren, um mehr zu erfahren!

Sprint Burn-Down-Charts

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.

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

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

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

Unklares und unvollständiges Sprint Backlog zu Beginn eines Sprints

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

Action Items im Sprint Backlog

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.

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

  • Sollte Euer Product Owner wiederholt, Aufgaben, To Do’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 Thema 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!