Backlog: Alles zur Organisation von Aufgaben im Scrum-Team

Was ist ein Backlog?

Ein Backlog ist eine Sammlung von Aufgaben und Anforderungen, die fortlaufend aktualisiert wird. Agile Teams priorisieren die dynamische Liste mithilfe agiler Methoden. Ins Deutsche übersetzt bedeutet der Begriff „Rückstau“ oder „Arbeitsrückstand“, das Verb „to backlog“ heißt „sich anhäufen“. Es handelt sich also um eine Liste unerledigter oder unvollständiger Arbeit. Im Backlog sammeln sich beispielsweise neue Ideen und Anforderungen, geplante Leistungsmerkmale oder auch Fehlerbehebungen. Diese einzelnen Einträge bezeichnet man als Backlog Item.

Oft wird der Begriff „Backlog“ synonym mit dem „Product Backlog“ verwendet. In diesem sammeln Scrum-Teams alle Aufgaben und Anforderungen, die zur Entwicklung eines Produkts, eines Services oder einer Lösung erforderlich sind. Neben dem Product Backlog gibt es in Scrum noch den Sprint Backlog. Hierin stellt das Team im Sprint Planning die Aufgaben und das Ziel für den nächsten Arbeitszyklus (dem sogenannten Sprint) zusammen.

In einigen Unternehmen und Kontexten gibt es weitere Backlogs, beispielsweise Release, Solution oder Portfolio Backlogs. In diesem Artikel fokussieren wir uns auf die beiden im Scrum-Framework notwendigen Artefakte: Product und Sprint Backlog.

Product Backlog vs. Sprint Backlog

Der Scrum Guide legt den Product und den Sprint Backlog als Scrum-Artefakte fest. Ihre zentrale Aufgabe ist es, „die Transparenz von Schlüsselinformationen zu maximieren.“ Im Klartext heißt das: Beide machen die anstehenden Aufgaben bzw. Arbeit des Teams sichtbar.

So können alle Teammitglieder und auch Stakeholder*innen (z. B. Ansprechpartner aus anderen Fachbereichen oder dem Management des Unternehmens) den Product Backlog einsehen. Hierin sammelt der Product Owner alle Stories und Aufgaben, die für die Erstellung des Produkts erforderlich sind. Die dynamische Liste verändert sich im Laufe der Entwicklung: Durch gewonnene Erkenntnisse aus den Sprints oder zusätzliche Anforderungen von Stakeholder*innen nimmt das Team neue Backlog Items auf, verändert bestehende oder nimmt Einträge heraus, die es nicht mehr umsetzt. Das Product Backlog bleibt für den gesamten Zeitraum der Produktentwicklung bestehen – oft sogar darüber hinaus.

Das Sprint Backlog stellt das Team hingegen nur für den jeweiligen Sprint auf. Es besteht aus den für den aktuellen Sprint ausgewählten Einträgen aus dem Product Backlog und einem übergeordneten Sprint-Ziel.

Wie funktioniert ein Product Backlog?

Ein Product Backlog funktioniert zunächst einmal als Sammelbecken. Das Scrum-Team kann hier alle Aufgaben, Arbeiten und Anforderungen aufnehmen, die (zukünftig) wichtig für die Entwicklung sind. Diese Sammlung orientiert sich an dem Produktziel. Das Produktziel „beschreibt einen zukünftigen Zustand des Produkts, welches dem Scrum Team als Planungsziel dienen kann“ (Scrum Guide). Idealerweise zahlen alle Items, die aufgenommen werden, auf dieses übergeordnete Ziel ein.

Aus diesem Grund sollte das Product Backlog gut sortiert und gepflegt sein. Es reicht nicht, alles Wichtige aufzunehmen und in die Liste zu stopfen. Die einzelnen Einträge müssen so detailliert beschrieben sein, dass das Team weiß, was umgesetzt werden soll. Zudem sind die Einträge priorisiert, damit die wichtigsten Dinge auch zuerst bearbeitet werden. Der Product Owner gibt hierbei pro Sprint ein Ziel vor und macht Vorschläge, was das Team umsetzen soll. Letztlich entscheidet das Team aber eigenständig, welche Aufgaben es bearbeitet und welche Items vom Product in den Sprint Backlog wandern.

Welche Backlog Items gibt es?

Backlog Items fassen die Anforderungen und Bedürfnisse von Kund*innen und Stakeholder*innen zusammen. Je nach Größe oder Fokus der umzusetzenden Aufgabe gibt es unterschiedliche Item-Arten. Die einzelnen Einheiten reichen von größeren Vorhaben (Initiativen und Epics) bis hin zu Aufgaben, die ein Team an einem Arbeitstag erledigen kann (Tasks):

• Initiativen: Größere Vorhaben über mehrere Monate oder Quartale. Eine Initiative umfasst mehrere Epics, die ein gemeinsames Ziel verfolgen.
• Epic: Große Anforderung, die nicht in einem Sprint erledigt werden kann. Ein Epic ist oftmals nicht sonderlich ausformuliert und nur solange im Backlog erlaubt, bis es in die Umsetzung geht. Hierfür unterteilt das Team es dann üblicherweise in mehrere User Stories oder kleinere Items.
• User Story: Eine User Story beschreibt (möglichst) in einem Satz den Mehrwert für die Nutzer*innen, den es mit der Fertigstellung erreicht. Sie ist also nicht als Arbeitsanweisung oder Feature formuliert, sondern als Ziel. Die konkreten Aufgaben leiten die Entwickler*innen aus der Story ab. Eine User Story ist aus Kundensicht verfasst und kann innerhalb eines Sprints abgeschlossen werden.
• Spike-Items: Zeitlich begrenzte Aufgabe mit dem Ziel, eine Frage zu klären oder Wissen zu sammeln.
• Task: Ein Task ist eine Aufgabe innerhalb einer User Story, die an (maximal) einem Arbeitstag von einer Person bearbeitet werden kann.
• Bug: Funktionaler Fehler, der die Nutzung des Produkts erschwert oder behindert. Der Begriff “Bug” stammt aus der Softwareentwicklung, kann aber auch in der Entwicklung physischer Produkte genutzt werden. Auch hier kann es zu Fehlern kommen, die die Nutzerfreundlichkeit erschweren. Dann muss eine neue Lösung gefunden oder der Fehler beseitigt werden.

Diese Strukturierung ist ein Vorschlag. In manchen Teams haben sich weitere Item-Arten etabliert wie z. B. funktionale Anforderungen oder Job Stories. Was alle Items jedoch gemeinsam haben sollten, sind eine Beschreibung sowie eine Priorisierung, um ein effektives Backlog-Management zu ermöglichen.

Wer schreibt die Einträge im Product Backlog?

Der Product Backlog lebt: Er ist keine starre Liste, die ein Team abarbeitet, sondern bleibt dynamisch. Regelmäßig kommen neue Items dazu, bestehende werden überarbeitet oder auch gelöscht. Im Scrum-Team ist der Product Owner (PO) „Hüter des Backlogs“ und für dessen Pflege und Management verantwortlich. Das heißt: Er erstellt und kommuniziert die Einträge und ist auch für die Priorisierung zuständig. Zudem sorgt er dafür, dass das Product Backlog transparent, sichtbar und verstanden ist.

In der Praxis ist es häufig so, dass der PO hier nicht alleine handelt: Oft schreibt das gesamte Scrum-Team Einträge und die Verfeinerung der Items passiert oft im Dialog zwischen PO und Entwickler*innen.

Wie auch immer das Team seinen Backlog füllt, der Product Owner ist ergebnisverantwortlich für den Mehrwert des zu entwickelnden Produkts. Deshalb sollte er es immer im Blick haben und über alle Einträge informiert sein.

Backlog Refinement: Verfeinerung der Einträge 

Backlog Items können jederzeit geschrieben werden – je nachdem, wann die Anforderung reinkommt. Oft sind sie am Anfang noch nicht so ausgereift, dass das Team sie bearbeiten kann. Manchmal bestehen die Items zunächst nur aus einem Titel oder Stichpunkten.

Für eine spätere Umsetzung muss das Team die Einträge in der Regel verfeinern und mit weiteren Informationen ausarbeiten. Hierfür bietet sich ein regelmäßiges Backlog Refinement an. In diesem Meeting bespricht das Scrum-Team die hoch priorisierten Einträge und versorgt sie mit zusätzlichen Informationen. Zudem bietet das Treffen die Möglichkeit, Stories oder Epics herunterzubrechen. Ziel ist es, diese auf eine Größe zu bringen, dass eine Person sie bearbeiten kann, sie aber immer noch Wert stiften.

Effektives Management mit den DEEP-Merkmalen 

Roman Pichler und Mike Cohn haben mit dem DEEP-Merkmalen ein hilfreiches Werkzeug für ein effektives Backlog Management aufgestellt. DEEP identifiziert vier zentrale Eigenschaften für einen guten Backlog: Das Akronym steht für Detailed appropriately, Estimated, Emergent und Prioritized:

• Detailed Appropriately (Angemessen detailliert): Die höher priorisierten Items sind detaillierter beschrieben als die Einträge, die sich weiter unten im Backlog befinden. Rückt die Umsetzung näher, werden die Items zunehmend detaillierter und feiner definiert.
• Estimated (Geschätzt): Für jedes Item gibt es eine Aufwandschätzung. Auch hier gilt: Die höher priorisierten Einträge sind genauer geschätzt. Die später umzusetzenden Items werden grob geschätzt und können auch noch einmal neu bewertet werden.
• Emergent (Sich entwickelnd): Das Product Backlog ist dynamisch und verändert sich ständig. Durch neue Informationen und Erkenntnisse im Laufe der Entwicklung entstehen neue Items, bestehende werden aktualisiert oder entfernt. Auch die Priorisierung und Ordnung der Items kann sich ändern.
• Prioritized (Priorisiert): Die Items sind priorisiert. Erkennbar ist dies an der Reihenfolge: Die obersten Einträge der Liste haben die höchste Priorität und werden möglichst zuerst umgesetzt.

Fokus liegt auf Mehrwert 

Product Owner können ihr Backlog noch so gut pflegen – in der Regel ist es trotzdem zu voll. Über die Zeit häufen sich die Tickets an, viele davon sind alt oder längst hinfällig. Manche sind ohnehin erst in der Liste gelandet, weil man einem Kollegen einen Gefallen tun wollte. Chance auf Umsetzung bei diesen Einträgen: gering bis nicht vorhanden.

Hat ein Team ein riesiges, unübersichtliches Backlog, kann es sich im „Dschungel der Anforderungen“ verirren. Das „große Ganze“, die Unternehmensstrategie und die übergeordneten Ziele, gerät dabei aus dem Blick. Deswegen ist es wichtig, die Inhalte immer auf die Werthaltigkeit zu prüfen: Bringt dieses Feature etwas für den Kunden und zahlt es auf die Unternehmensziele ein? Dann darf es im Backlog blieben. Nein? Dann kann es verschwinden.

„Der Fokus liegt immer auf dem Kundenwert, Anforderungen werden immer dahingehend geprüft“, sagt Benjamin Britten, Lead Product Owner bei Shop Apotheke. „Man sollte idealerweise nichts umsetzen, nur um jemandem im Unternehmen einen Gefallen zu tun.“

Die Strategie und Ziele sollten führend sein, nicht die Backlog-Logik. Ziel sollte es also nicht sein, das Backlog möglichst leer zu kriegen, sondern immer Wert zu schaffen. Deswegen ist es wichtig, regelmäßig auszumisten. Aber auch ein „Prä-Backlog-Management“ ist sinnvoll: Lassen Sie Anforderungen erst gar nicht in die Liste wandern, wenn sie keinen Wert schaffen und nicht auf das Produktziel oder die Unternehmensziele einzahlen. Das erfordert, auch einmal „Nein“ zu den Stakeholder*innen bzw. Anspruchssteller*innen zu sagen.

Alan Kelly schlägt eine radikale Methode vor, das Backlog aufzuräumen. In seinem Vortag auf der 2022er-Ausgabe der Hands-on Agile 44-Konferenz rät der Agile Coach und Autor dazu, es komplett zu vernichten:

Was ist ein Sprint Backlog?

Jeden Sprint stellt das Scrum-Team ein Sprint Backlog auf. Dieses bildet das Arbeitspaket für den anstehenden Zyklus. Enthalten sind das übergeordnete Sprintziel, die benötigten Backlog Items und ein Plan, wie das Team dieses Ziel erreicht.

Den Fortschritt des Sprints kann das Team beispielsweise an einem Scrum Board visualisieren:

• Welche Stories/Items gehören zum aktuellen Sprint?
• Woran wird gerade gearbeitet?
• Was ist bereits fertig?

Den aktuellen Stand des Sprints bespricht das Team im Daily Standup. Hier diskutiert es auch Hindernisse und aktuelle Probleme.

Sprint Planning: Initialzündung für das Sprint Backlog

Das Sprint Planning eröffnet den Sprint. In der Regel bereitet der Product Owner (PO) ein Sprintziel vor und trifft eine Vorauswahl der Items aus dem Product Backlog, die das Team bearbeiten soll. Das finale Sprint Backlog wird dann im Team-Dialog festgelegt.

So einigen sich Entwickler*innen und PO im Planungstreffen auf ein gemeinsames Sprintziel. Dieses beschreibt das Ergebnis (Outcome) des Sprints und den Mehrwert für die Nutzer*innen bzw. Kund*innen. Und auch über die Backlog Items diskutieren sie in der Regel: Die Entwickler*innen entscheiden eigenständig, wie viel Arbeit sie übernehmen und wählen die Einträge aus, die sie innerhalb des Sprints umsetzen. Das bedeutet, dass sie vom PO vorgeschlagene Stories eventuell nicht berücksichtigen.

Zusätzlich stellen die Entwickler*innen einen Plan auf, wie sie die einzelnen Items bearbeiten. Hierzu brechen sie diese in kleinere Arbeitseinheiten herunter, die sie an (maximal) einem Tag abschließen können. Das im Team abgestimmte Sprint-Ziel, die ausgewählten Backlog Items und der Plan zur Bearbeitung bilden somit am Ende das Sprint Backlog.

„Ich mache am Anfang des Plannings einen Vorschlag, was meiner Meinung nach im Sprint umgesetzt werden kann und sollte“, beschreibt Andreas Schneider, Product Owner bei den DEVK Versicherungen, den Ablauf in seinem Team. „Und dann fangen wir an zu diskutieren: Das Team schreibt die Unteraufgaben zu den einzelnen Stories. Anhand der Unteraufgaben und der Aufwandschätzung aus dem Refinement legen wir dann gemeinsam die Stories fest, die im Sprint erledigt werden. Es kommt manchmal vor, dass wir noch Aufgaben aus dem letzten Sprint zu erledigen haben. Wir bringen diese und die neuen Stories in eine priorisierte Reihenfolge.“

Wer verantwortet das Sprint Backlog?

Während der Product Owner das Product Backlog verantwortet, wacht das Entwicklungsteam über das Sprint Backlog. Die Entwickler*innen entscheiden, welche Items hinein wandern. Voraussetzung hierfür ist beispielsweise, dass der Eintrag ausreichend definiert ist. Üblicherweise werden nur Items übernommen, welche die im Team festgelegte Definition of Ready erfüllen.

Im laufenden Sprint dürfen nur die Entwickler*innen das Sprint Backlog anpassen oder verändern. Aus diesem Grund achtet das Team beim Sprint Planning darauf, nicht zu viel Arbeit zu planen. Es sorgt dafür, dass immer ein Puffer für unvorhergesehene Aufgaben (z. B. Fehlerbehebungen) übrig ist. So bleibt auch das Sprint Backlog dynamisch und nimmt unter Umständen neue Aufgaben auf.

Zusammenfassung

Sowohl das Product Backlog als auch das Sprint Backlog spielen im Scrum-Framework eine wichtige Rolle. Sind sie gut gepflegt und zusammengestellt, erleichtert dies die Arbeit des Scrum-Teams. Ein aktives Backlog Management und ein konkreter Fokus auf den (Kunden-)Wert macht die Team-Arbeit effektiver und führt zu besseren Ergebnissen.