Backlog

Backlog Definition

Backlog ist ein Begriff aus dem Englischen und bedeutet „an accumulation of something, especially uncompleted work or matters that need to be dealt with“. Ein Backlog ist also eine Sammlung von Dingen, insbesondere unvollständiger Arbeit oder Angelegenheiten, die erledigt werden müssen. Oder einfach ausgedrückt: Es ist eine Liste von Aufgaben bzw. Anforderungen, die abgearbeitet bzw. realisiert werden sollen.

Wortwörtlich übersetzt steht der Begriff für Rückstand, Rückstau, Arbeitsrückstand, Nachholbedarf oder Auftragsüberhang. Und to backlog something bedeutet im Deutschen etwas auf Halde legen oder zu späterem Gebrauch beiseitelegen.

Was sind Backlog Items?

In der Software- und Produktentwicklung bzw. im agilen Projektmanagement werden in Backlogs unterschiedliche Arten von Einträgen verwaltet. Diese werden Backlog Items genannt. [1] Folgende Items lassen sich u. a. unterscheiden:

• Funktionale und nicht-funktionale Anforderung
• Epic
• User Story
• Job Story
• Use Case
• Use Case Slice
• Impediment

Idealerweise enthält jedes Item eine Beschreibung, eine Priorität, eine Aufwandsschätzung und einen Kundennutzen. Je höher die Priorität eines Items ist, desto genauer wird es in der Praxis spezifiziert. Gleichzeitig steigt mit der Priorität die Wahrscheinlichkeit, dass es abgearbeitet bzw. realisiert wird.

Product Backlog

Das Product Backlog ist der erste Container, in dem zu erledigende Aufgaben, funktionale Anforderungen, Features etc. erfasst werden. In manchen Organisationen wird es auch als Domain Backlog betitelt – immer dann, wenn Organisationen in verschiedenen Domänen aktiv sind und es Sinn macht, die Items pro Domäne zu erfassen. Ein Product Backlog lässt sich anhand von vier Eigenschaften beschreiben:

• Priorisierung: Die Items werden priorisiert.
• Detaillierung: Ein Item wird umso detaillierter beschrieben, je größer seine Priorität ist.
• Schätzung: Für jedes Item wird eine Aufwandsschätzung durchgeführt. Je höher die Priorität, desto präziser ist diese Schätzung.
• Bewertung: Ein Item beschreibt einen Kundennutzen und dieser wirkt sich auf Priorisierung des Items aus.

Die Priorisierung der Product Items ist essentiell. Nicht alle Anforderungen sind gleich wichtig, haben denselben Kundennutzen oder verursachen denselben Aufwand zur Realisierung. Die Priorisierung wird bspw. in Scrum durch den Product Owner – idealerweise in enger Zusammenarbeit mit den Entwicklern – vorgenommen. Der Product Owner ist Ansprechpartner für die relevanten Stakeholder. Während Stakeholder Anforderungen oft mit einem Blick auf einen Geschäftswert bewerten, achtet das Team auf den Entwicklungsaufwand und eine technisch sinnvolle Reihenfolge der Umsetzung. Für die Aufwandsschätzung bietet sich die Nutzung relativer Werte mit Fibonacci-Zahlen an. Dies hat den Vorteil, dass Aufwände in kleinem Umfang sehr genau auf Tagesniveau (1 Tag, 2 Tage, 3 Tage, 5 Tage etc.), Aufwände in großem Umfang relativ grob (bspw. 20 Tage, 40 Tage, 100 Tage etc.) geschätzt werden können.

Zu beachten ist, dass die Priorisierung immer wieder durchgeführt werden muss, denn durch neue Anforderungen oder die Verfeinerung von bestehenden Items kommen neue Erkenntnisse hinzu. Ein Product Backlog ist also sehr dynamisch und unterscheidet sich damit wesentlich von Lastenheft oder Pflichtenheft.

Release Backlog

Agile Projekte und zahlreiche Produktentwicklungen gliedern sich in Releases und Iterationen. Da der zeitliche Umfang dieser Iterationen in Scrum bspw. mit einer empfohlenen Dauer von einer Woche bis maximal einem Monat relativ kurz ist, werden sie als Sprints bezeichnet. Sie haben in einem Projekt immer dieselbe Dauer. Eine definierte Menge an Sprints ergibt ein Release. Beides – also Dauer und Menge – muss jedes Unternehmen für sich definieren. Beispiel: Nach fünf Sprints erfolgt das erste Release, nach fünf weiteren ein nächstes Release, usw.

Bei mehreren Teams und parallelen Sprints, sollten die Intervalle aufeinander abgestimmt werden. Anforderungen werden basierend auf ihren Prioritäten den jeweiligen Releases zugeordnet. Die Festlegung von Prioritätsgrenzen hilft bei der Verteilung von Anforderungen auf Releases. Bestimmt der Product Owner bspw. eine Untergrenze von 802, dann landen die Items des Product Backlogs mit den Prioritäten 802 und höher im nächsten Release, Anforderungen mit Prioritäten 801 und niedriger landen in späteren Releases.

Sprint Backlog

In jedem Sprint soll ein funktionsfähiges, potentiell auslieferbares Zwischenprodukt – ein sogenanntes Inkrement – entwickelt werden. Im Sprint Planning Meeting wird entschieden, welche Items aus dem Product oder dem Release Backlog (je nach Vorgehen innerhalb einer Organisation) in das Sprint Backlog wandern, um im nächsten Sprint umgesetzt zu werden. Das Team wählt die Items bzw. User Storys mit den höchsten Prioritäten aus und schätzt, welche und wie viele sich innerhalb des nächsten Intervalls realisieren lassen. Die umzusetzenden Items landen im Sprint Backlog. Anschließend werden die User Storys in Tasks – also Aufgaben – unterteilt, die innerhalb eines Tages erledigt werden können. Dabei bestimmt das Entwicklungsteam selbständig, wer die Aufgaben realisiert.

Um den Fortschritt der Entwicklung zu erkennen, ist es wichtig, die Aufgaben und in der Folge die User Storys mit Zuständen zu versehen. Sind alle Aufgaben zur Realisierung einer User Story erledigt und die Definition of Done erfüllt, gilt diese als realisiert. Zur Visualisierung bietet sich die Verwendung von Taskboards an.

Priorisierung von Backlog Items

Die Priorisierung von Items ist ein wichtiger Erfolgsfaktor für die Software- und Produktentwicklung, denn so stellen Sie sicher, dass die wichtigen und richtigen Anforderungen realisiert werden. Zur Priorisierung gibt es verschiedene Methoden, die sich auch miteinander kombinieren lassen:

• Das Kano Modell klassifiziert fünf Merkmale, die in unterschiedlicher Weise zur Kundenzufriedenheit beitragen: Basis-, Leistungs- und Begeisterungsmerkmals, sowie unerhebliche Merkmale und Rückweisungsmerkmale. Basismerkmale erzeugen Unzufriedenheit, wenn sie fehlen. Leistungsmerkmale sind ein wichtiger Faktor für die Kundenzufriedenheit und die Differenzierung zum Wettbewerb. Und Begeisterungsmerkmale führen zu überproportionaler Zufriedenheit.
• Das MoSCoW-Prinzip unterscheidet zwischen Funktionen, die das Entwicklungsteam unbedingt umsetzen sollten und solchen, die  umgesetzt werden könnten:
  Must: Must-Have Funktionalitäten, die umgesetzt werden müssen.
  Should: Funktionalitäten, die nach den Must-Haves umgesetzt werden.
  Could: Funktionalitäten, die umgesetzt werden können, wenn sie keine Must-Haves oder Should-Funktionen damit beeinträchtigen.
  Won’t: Funktionalitäten, die nicht umgesetzt werden sollen.
• Bei der Relative Weight Methode wird jedes Backlog Item in den Kategorien Vorteile, Strafen, Risiken und Kosten jeweils mit einer Zahl von 1 – 9 bewertet. Die Fragen nach den Vorteilen (Wie groß wäre der Vorteil, wenn eine Anforderung realisiert würde) und den Strafen (Wie groß wäre die Strafe, wenn die Anforderung nicht realisiert würde) bewertet der Product Owner gemeinsam mit den relevanten Stakeholdern. Und die Fragen nach dem Risiko (Wie hoch sind Implementierungsrisiken und Abhängigkeiten zu anderen Teams und Entwicklungen) und den Kosten für die Umsetzung bespricht der Product Owner mit den Entwicklern. Anschließend werden die Werte für Vorteile und Strafen durch die Werte für Risiken und Kosten dividiert. Aus den Ergebnissen ergibt sich die Priorisierung.
• Beim Theme Screening identifizieren Sie bis zu neun Beurteilungskriterien und wählen anschließend ein Baseline Theme, also ein Backlog Item aus, das als Basis für eine relative Bewertung dient. Es empfiehlt sich hier ein Element auszuwählen, das dem Entwicklungsteam vertraut ist und demnächst umgesetzt werden sollte. Danach bewerten Sie die Items in den Beurteilungskriterien im Verhältnis zum Baseline Theme mit Plus, Minus oder einer Null. Die Priorisierung entsteht durch das Addieren der Plus- und Subtrahieren der Minus-Werte pro Item.

Es gibt noch weitere Methoden wie Rocks, Pebbles & Sand, Walking Skeleton oder Theme Scoring. Welche Methode sich am besten für die Priorisierung eignet, lässt sich nicht allgemeingültig beantworten. Hier sollte jedes Unternehmen für sich selbst eine Entscheidung treffen.

Tipps für die Arbeit mit Backlogs

Es gibt eine Reihe von Tipps für die Arbeit mit Backlogs:

• Backlogs sind dynamisch. Neue Features, User Storys oder Defects kommen hinzu und Stakeholder ändern ihre Wünsche. Dadurch ergeben sich fortlaufend neue Prioritäten. Die regelmäßige Pflege wird als Refinement oder Grooming bezeichnet. [3] Es sorgt für hohe Transparenz, so dass alle Projektbeteiligten stets wissen, woran gerade gearbeitet wird und was demnächst ansteht. Gleichzeitig können Unternehmen schnell und flexibel auf Veränderungen reagieren.
• Die sogenannte 5S Technik verspricht Hilfe bei der Organisation und Plege von Backlogs. Im Japanischen stehen die S für Seiri, Seiton, Seiso, Seiketsu und Shitsuke, im Englischen für Sort, Set in Order, Shine, Standardize und Sustain. [4]
• Als sinnvolle Ergänzung für die Arbeit mit Backlogs hat sich in der Praxis die Arbeit mit User Story Mappings erwiesen.
• In zahlreichen Publikationen werden Backlog Items mit User Storys gleichgesetzt. Für die spätere Umsetzung mag das Sinn ergeben, für die inhaltliche Arbeit kann die Gruppierung auf Basis von Epics oder Features sehr sinnvoll sein.
• Da der Umfang von Backlogs schnell wächst, kann es nützlich sein, Items zu identifizieren, die gelöscht werden können.
• Bei der Priorisierung ergibt es viel Sinn, absolute Werte pro Item zu definieren, so dass es keine zwei Items gibt, die dieselbe Priorität haben.
• Laut Scrum Guide ist der Product Owner für Sortieren der Product Backlog Items zuständig. Gleichzeitig darf er diese Aufgabe auch delegieren, sofern er die Verantwortung behält. Die Sortierung im Team sorgt für frühzeitige Transparenz und ein erhöhtes Verständnis der Beteiligten.

Weitere Tipps finden Sie in der zweiteiligen Blog-Serie Boost your Backlog.

Backlogs in der Praxis

Es gibt eine Liste an Fragen im Kontext von Backlogs. Auf einige der Fragen finden Sie Antworten in unserem Blog oder in unserer Rubrik Wissen kompakt:

• Wie lassen sich Backlogs Items mit dem Team Estimation Game schätzen?
• Wie funktioniert Planning Poker?
• Was ist eine Definition of Ready?
• Welche Inhalte gehören in eine Definition of Done?
• Welche Aufgaben obliegen dem Product Owner in Bezug auf Backlogs?
• Was tun, wenn Backlogs glorifiziert werden?
• Wie kann ein Backlog Teams dabei helfen, in agilen Projekten zu lernen?
• Wie lässt sich aus einem Business Model Canvas ein initiales Backlog ableiten?

Sicherlich fallen Ihnen noch weitere Fragen ein. Melden Sie sich gerne bei uns und wir versuchen Ihre Fragen zu beantworten oder entsprechende Beiträge zu publizieren.

Auch wenn der Scrum Guide keine Release Backlogs kennt, erachten viele Organisationen sie als sehr nützlich. Fehlt der Begriff aus Ihrer Sicht?

Und: Was ist das typische Alter eines Product Backlog Items?

Hinweise:

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!

[1] Der Scrum Guide spricht bewusst von Product Backlog Items (PBI), weil er eine generische, universelle Terminologie verwenden möchte, die in verschiedenen Kontexten und für unterschiedliche Arten von Projekten anwendbar ist. Würde sich der Guide bspw. auf User Storys beschränken, könnte dies den Eindruck erwecken, dass Scrum nur für Softwareentwicklungsprojekte geeignet ist oder dass Teams gezwungen wären, das User-Story-Format zu verwenden. Der allgemeine Begriff PBI vermeidet solche Missverständnisse.

[2] Interessanterweise nennt der Scrum Guide den Begriff Product Backlog Item (PBI) 13 Mal, den Begriff Sprint Backlog Item jedoch gar nicht, obwohl das PBI durch die Einplanung ins Sprint Backlog zu einem Sprint Backlog Item wird.

[3] Das im deutschsprachigen Raum relativ gebräuchliche „Backlog Grooming“ oder „Scrum Grooming“ wird im englischsprachigen Raum fast nicht mehr verwendet, da Grooming ein sogenanntes Trigger Word mit einer sehr negativen sexuellen Konnotation ist. Wir verwenden daher bewusst Refinement.

[4] Hier finden Sie weitere Informationen zur 5S-Technik.

Unter dem Stichwort „lebenslanges Lernen“ empfehlen immer mehr Menschen, mehr Zeit dem persönlichen Lernen zu widmen. In diesem Zusammenhang wird auch der Begriff „Lernbacklog“ verwendet.

Hier finden Sie ein englischsprachiges Video über die Erstellung eines Product Backlogs.

Hier finden Sie einen Podcast über die ideale Größe von Product Backlogs.

Und hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.