Backlog: Team in Besprechung

Backlog: Alles zur Organisation von Aufgaben im Scrum-Team

In der agilen Arbeit ersetzt das Backlog die aufwendige Planung des klassischen Projektmanagements. Die dynamische Liste ist die primäre Arbeitsquelle eines Scrum-Teams. Doch was ist ein Backlog genau? Was unterscheidet den Product vom Sprint Backlog? Und wie lässt sich die Liste effektiv managen? Unser Artikel liefert die Antworten.

E-Book
Backlog: Alles zur Organisation von Aufgaben im Scrum-Team
Später lesen? Den vollständigen Leitfaden als E-Book herunterladen.
Jetzt herunterladen

Was ist ein Backlog?

Ein Backlog ist eine Sammlung von Aufgaben und Anforderungen, die fortlaufend aktualisiert wird. Die dynamische Liste wird mithilfe agiler Methoden priorisiert. 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 werden weitere Backlogs gepflegt, beispielsweise gibt es Release, Solution oder Portfolio Backlogs. In diesem Artikel fokussieren wir uns auf die beiden im Scrum-Framework notwendigen Artefakte: Product und Sprint Backlog.

Das Product Backlog ist eine emergente, geordnete Liste der Dinge, die zur Produktverbesserung benötigt werden. Es ist die einzige Quelle von Arbeit, die durch das Scrum Team erledigt wird.

Scrum Guide

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 nicht mehr umgesetzt werden. 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 umgesetzt werden soll. Letztlich entscheidet das Team aber eigenständig, welche Aufgaben es bearbeitet und welche Items vom Product in den Sprint Backlog wandern.

Product Backlog vs. Pflichtenheft

Was unterscheidet einen Product Backlog vom klassischen Pflichtenheft? Beide Ressourcen bilden Anforderungen an ein Produkt oder Projekt ab und dienen als Orientierung in der Entwicklung. Der große und entscheidende Unterschied liegt in der Dynamik: Ein Pflichtenheft ist eine statische und möglichst konkrete Auflistung der Tätigkeiten und Aufgaben eines (Projekt-)Teams. Es beschreibt, wie die Anforderungen an ein bestimmtes Produkt oder Projekt erfüllt werden sollen. In der Regel wird ein Pflichtenheft vor Start eines Projekts geschrieben und nur selten aktualisiert. Viele Pflichtenhefte enthalten lange Formulierungen, die detailliert Funktionen, Anforderungen und Sonderfälle beschreiben. In der Praxis sorgt dies für Interpretationsspielraum und in der Folge zu Diskussionen zwischen Autor*innen und Umsetzenden.

Das Product Backlog ist hingegen nicht abgeschlossen und verändert sich im Laufe der Entwicklung. Die Anforderungen sind nach einem gleichbleibenden Standard formuliert, z. B. in User Stories oder Job Stories. Das sorgt für einen kompakten und verständlichen Aufbau. Je nachdem, welche Erkenntnisse ein Team gewinnt oder sich die Umgebung ändert, können neue Anforderungen hinzukommen, bestehende überarbeitet werden oder alte entfallen. Ein Product Backlog ist somit deutlich anpassungsfähiger und ermöglicht es dem Team, flexibel auf sich ändernde Marktsituationen zu reagieren

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

Wie halten Sie Ihr Backlog sauber?

Wie organisiert man das Refinement des Backlogs? Was sind die DEEP-Prinzipien? Wie werden Abhängigkeiten sichtbar? Im Deep Dive lernen Sie die Konzepte und Tipps erfahrener Agile Coaches.

Mehr zu den Digital Deep Dives
Agile Coach Vanessa Bern

Wer schreibt die Einträge im Product Backlog?

Der Product Backlog lebt: Er ist keine starre Liste, die abgearbeitet wird, 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.

Da ich die Anforderungen sammele, schreibe ich die User Stories und Epics selbst – allerdings auf einem relativ hohen, abstrakten Level. Daraus leiten sich die Entwickler dann ihre eigenen User Stories ab, die dann auf einer Umsetzungsebene geschrieben sind.

Mathias Kruse
Product Owner bei Gieseke+Devrient

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.

Das Refinement des Product Backlogs ist der Vorgang, durch den Product‐Backlog‐Einträge in kleinere, präzisere Elemente zerlegt und weiter definiert werden. Dies ist eine kontinuierliche Aktivität, wodurch weitere Details wie Beschreibung, Reihenfolge und Größe ergänzt werden.

Scrum Guide

Für eine spätere Umsetzung müssen die Einträge in der Regel verfeinert und mit weiteren Informationen ausgearbeitet werden. 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.

Ausbildung zum Agile Coach (IHK)

Treiben Sie den Kulturwandel in Ihrem Unternehmen voran. In unserer berufsbegleitenden Ausbildung erhalten Sie alle Werkzeuge, die es braucht, um die Rolle des Agile Coach einzunehmen.

Mehr zur Ausbildung
Agile Coaches sorgen für mehr Kommunikation zwischen Interessensgruppen

Definition of Ready: Wann ist ein Item „fertig“?

Wann ist ein Item so weit, dass es umgesetzt und in das Sprint Backlog aufgenommen werden kann? Viele Teams stellen hierfür eine Definition of Ready auf – eine Liste von Kriterien, die Einträge erfüllen müssen, um „fertig“, also umsetzungsfähig, zu sein. Das Team erstellt die Definition of Ready (DOR) dabei nicht für jede Story einzeln, sondern legt für alle Items gültige Kriterien fest. In einigen Organisationen ist die DOR sogar unternehmensweit definiert und somit in allen Teams gleich.

Mögliche Kriterien sind beispielsweise:

  • Es besteht keine Abhängigkeit zu anderen Einträgen, so dass es unabhängig priorisiert, geschätzt und umgesetzt werden kann.
  • Der Aufwand für das Item ist geschätzt.
  • Der Mehrwert für unsere Kund*innen ist beschrieben.
  • Es ist klein genug, um in einem Sprint umgesetzt zu werden.
  • Das Item hat mindestens ein Akzeptanzkriterium.

READY is when the team says: ‚Ah, we get it‘.

Jeff Sutherland
Mitbegründer von Scrum
Bitte akzeptiere unsere Marketing-Cookies um dieses Video anzusehen.

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.

To ensure that the product backlog is DEEP and stays that way, you have to groom or refine it regularly. Grooming the product backlog is an ongoing, collaborative process that involves the product owner and team.

Roman Pichler
Experte für Produktmanagement und Miterfinder der DEEP-Merkmale

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

Bitte akzeptiere unsere Marketing-Cookies um dieses Video anzusehen.

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:

Bitte akzeptiere unsere Marketing-Cookies um dieses Video anzusehen.

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 Ziel erreicht werden soll.

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 können auch Hindernisse und aktuelle Probleme diskutiert werden.

Das Sprint Backlog besteht aus dem Sprint‐Ziel (Wofür), den für den Sprint ausgewählten Product‐Backlog‐Einträgen (Was) sowie einem umsetzbaren Plan für die Lieferung des Increments (Wie).

Scrum Guide

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 bearbeitet werden sollen. 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 wird in der Regel diskutiert: 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 vom PO vorgeschlagene Stories eventuell nicht berücksichtigt werden.

Zusätzlich stellen die Entwickler*innen einen Plan auf, wie sie die einzelnen Items bearbeiten. Hierzu brechen sie diese in kleinere Arbeitseinheiten herunter, die an (maximal) einem Tag abgeschlossen werden 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.

Wie steigern Agile Master den Wert ihrer Retro, Review & Co.?

Wie strukturiert man die Review sinnvoll? Wann sind Team Health Checks sinnvoll? Bestehen Daily Standups immer aus den gleichen Fragen? Im Deep Dive zu agilen Meetings lernen Sie die Konzepte und Tipps erfahrener Agile Coaches.

Mehr zu den Digital Deep Dives
Agile Coach Alex Dodig

Definition of Done: Wann gilt ein Backlog Item als erledigt? 

Wann ein Eintrag aus dem Sprint Backlog fertiggestellt ist, bewertet das Team anhand einer gemeinsam entwickelten Definition of Done. Ähnlich wie die Definition of Ready stellt sie Kriterien auf, die ein Item erfüllen muss, um als „Done“, also auslieferbar, zu gelten. Und genau wie die DOR wird auch die Definition of Done einmalig und allgemeingültig für alle Einträge formuliert.

Mögliche Kriterien für eine Definition of Done sind:

  • Alle Aufgaben des Items sind erledigt.
  • Feedback aus dem Team ist eingeholt.
  • Die Funktionalität ist getestet.
  • Es treten keine Fehler auf.
  • Abnahme durch Product Owner ist erfolgt.

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.

NACH OBEN