Backlog
Ein Backlog ist eine dynamisch gepflegte Liste von durchzuführenden Arbeitsaufträgen, den Items. Diese können in Form von Anforderungen, User Storys oder Funktionsbeschreibungen vorliegen. Backlogs kommen häufig zum Einsatz bei der Arbeit in agilen Rahmenwerken wie Scrum und Kanban.
Backlog
Ein Backlog ist eine dynamisch gepflegte Liste von durchzuführenden Arbeitsaufträgen, den Items. Diese können in Form von Anforderungen, User Storys oder Funktionsbeschreibungen vorliegen. Backlogs kommen häufig zum Einsatz bei der Arbeit in agilen Rahmenwerken wie Scrum und Kanban.
Was ist ein Backlog?
Abstract: Ein Backlog ist eine dynamisch gepflegte Liste von durchzuführenden Arbeitsaufträgen, den Items. Diese können in Form von Anforderungen, User Storys oder Funktionsbeschreibungen vorliegen. Backlogs kommen häufig zum Einsatz bei der Arbeit in agilen Rahmenwerken wie Scrum und Kanban.
Backlog bedeutet wörtlich übersetzt "Arbeitsrückstand" beziehungsweise "Auftragsbestand". Durch das Arbeiten mit einem Backlog können Durchführung und Planung im agilen Projektmanagement bis zu einem gewissen Grad parallelisiert werden.
Der Backlog erfüllt dabei die Aufgabe eines Puffers. Die Elemente werden priorisiert und durch die blockweise Abarbeitung in Sprints wird gewährleistet, dass ein Team innerhalb des Budgets und dem vereinbarten Termin ein funktionsfähiges Produkt liefert.
Welche Vorteile bietet die Arbeit mit einem Backlog?
Ein Backlog erzeugt ein hohes Maß an Transparenz über erfasste Anforderungen, User Storys oder Tasks. Die Umsetzung von Vorhaben oder Produkten wird damit inhaltlich und zeitlich geplant. Ein gut gepflegtes Backlogs ist stets aktuell und zeigt, woran ein Team gerade arbeitet. So erleichtert es den Teammitgliedern die Arbeit, da alle Klarheit haben über die zu erledigenden Aufgaben. Die Priorisierung hilft beim Fokussieren auf bestimmte Aufgaben und es gelingt eine bessere Organisation.
Durch die eindeutige Priorisierung seiner Items sorgt ein Backlog zudem für eine hohe Akzeptanz bei den Stakeholder:innen. Dank ihm werden die Bedürfnisse der Kunden berücksichtigt und eine Langzeitplanung erleichtert.
Welche Arten von Backlogs gibt es?
Im Scrum Guide werden zwei Arten von Backlogs genannt: Den Product Backlog, der den Umfang der gesamten zu erstellenden Software aus Anwendersicht beschreibt, sowie den Sprint Backlog, den Product Owner und Entwicklungsteam aus dem Product Backlog zusammenstellen. Darin wird der zu erbringende Leistungsumfang eines Sprints festgelegt.
Das agile Vorgehensmodell SAFe, das entworfen wurde für große Software-Entwicklungsprojekte unter Beteiligung mehrere Entwicklungsteams, kennt insgesamt vier Backlogs:
- der Team Backlog, der dem Product Backlog entspricht,
- der Program Backlog, mit dem das Produktmanagement den Produktlebenszyklus steuert,
- der Solution Backlog, der für verschiedene Einsatzbereiche Lösungen oder Hilfsmittel enthält, um den Program Backlog abzuarbeiten, sowie
- der Portfolio Backlog, der alle Epics enthält, die bereits genehmigt und konzipiert sind, sich jedoch noch nicht in der Umsetzung befinden.
Die Struktur eines Backlogs ist je nach Organisation unterschiedlich. Wenn im Rahmen einer Entwicklung verschiedene Teams involviert sind, dann bietet es sich an, mit Team Backlogs zu arbeiten und die Items entsprechend auf die Teams zu verteilen. Wenn nur ein Team involviert ist, dann ist das Team Backlog identisch mit dem Release Backlog (siehe dafür weiter unten).
Product Backlog
Der Product Backlog ist der erste Container, in dem die Aufgaben, die zu erledigen sind, erfasst werden. Dazu gehören funktionale Anforderungen, Features usw. In manchen Organisationen wird dieser auch als Domain Backlog betitelt, vor allem dann, wenn Organisationen in verschiedenen Domänen als Fachgebieten aktiv sind und es sinnvoll ist, die Aufgaben pro Domäne in einem eigenen Backlog zu erfassen.
Für das Product Backlog werden die Items priorisiert und der jeweilige Aufwand für ihre Erstellung geschätzt. Je höher die Priorisierung, desto detaillierter die Beschreibung und desto präziser die Schätzung. Darüber hinaus werden die Items bewertet bzgl. ihres Kundennutzens, dieser wirkt sich entscheidend die Priorisierung aus.
Aufwände in kleinem Umfang sollten exakt auf Tagesniveau geschätzt werden. Bei einem großen Umfang reicht eine grobe Schätzung. Darüber hinaus gilt es zu beachten, dass die Items regelmäßig neu priorisiert werden muss, um neue Erkenntnisse oder Anforderungen zu berücksichtigen. Ein Product Backlog ist also hochdynamisch und unterscheidet sich damit wesentlich von einem Pflichtenheft oder einem Lastenheft.
Sprint Backlog
Innerhalb eines jeden Sprints soll ein funktionsfähiges und potentiell auslieferbares Zwischenprodukt entwickelt werden. In einem Sprint Planning Meeting wird entschieden, welche Items aus dem Product Backlog in das Sprint Backlog wandern, um im nächsten Sprint umgesetzt zu werden. Dabei wählt das Team die Items beziehungsweise 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 hinsichtlich ihres Bearbeitungsstatus definiert werden.
Release Backlog
Zahlreiche Produktentwicklungen und agile Projekte gliedern sich in Releases und Iterationen. Da der zeitliche Umfang dieser Iterationen mit einer empfohlenen Dauer von einer bis vier Wochen relativ kurz ist, werden sie als Sprints bezeichnet. In einem Projekt haben sie immer dieselbe Dauer. Eine definierte Menge an Sprints ergibt ein Release. Dauer und Menge muss jedes Unternehmen für sich selbst definieren. Beispielsweise kann nach vier Sprints das erste Release erfolgen und nach vier weiteren das nächste.
Bei parallelen Sprints in mehreren Teams müssen die Intervalle aufeinander abgestimmt werden. Die Anforderungen werden auf Basis der Prioritäten der jeweiligen Releases zugeordnet. Durch die Festlegung von Prioritätsgrenzen wird eine bessere Verteilung der Anforderungen auf Releases ermöglicht. Wird eine Untergrenze von beispielsweise 2 durch den Product Owner bestimmt, dann landen die Items des Produkt Backlogs mit Prioritäten 2 und höher im aktuellen Release, während Anforderungen mit Prioritäten 1 und niedriger dem nächsten Release zugeordnet werden.
Was sind Backlog Items?
In Backlogs werden unterschiedliche Arten von Einträgen verwaltet, die sogenannten Backlog Items. Dabei lassen sich unter anderem folgende Items unterscheiden:
- User Story
- Epic
- Job Story
- Funktionale Anforderungen
- Qualitätsanforderungen
- Use Case
- Defect (Bugs & Errors)
- Impediment
Im besten Fall enthält jedes Item eine Beschreibung, eine Priorität, eine Aufwandsschätzung sowie einen Kundennutzen. Je höher die Priorität des Items ist, desto genauer wird es in der Praxis spezifiziert. Gleichzeitig sorgt die steigende Priorität dafür, dass das Item mit höherer Wahrscheinlichkeit abgearbeitet beziehungsweise realisiert wird.
Methoden zur Priorisierung von Backlog Items
Die Priorisierung der Items ist ein essentieller Erfolgsfaktor für die Software- und Produktentwicklung. Damit wird sichergestellt, dass die richtigen und wichtigen Anforderungen umgesetzt werden. Für die Priorisierung gibt es verschiedene Methoden, die auch miteinander kombiniert werden können. Nachfolgend eine Auswahl von Methoden.
Das Kano-Modell klassifiziert fünf Merkmale, die in unterschiedlicher Weise zur Kundenzufriedenheit beitragen. Basis, Leistungs- und Begeisterungsmerkmale sowie unerhebliche Merkmale und Rückweisungsmerkmale. Wenn Basismerkmale fehlen, dann wird Unzufriedenheit erzeugt. Ein wichtiger Faktor für die Kundenzufriedenheit sind Leistungsmerkmale. Sie heben das Produkt oder die Software vom Wettbewerb ab. Die Begeisterungsmerkmale führen zu einer überproportionalen Zufriedenheit.
Die MoSCoW-Methode unterscheidet zwischen Funktionen, die das Entwicklungsteam unbedingt umsetzen sollte und Funktionen, die umgesetzt werden können.
- Must: Hierzu zählen Funktionalitäten, die unbedingt umgesetzt werden müssen.
- Should: In diesem Bereich werden Funktionalitäten eingeordnet, die umgesetzt werden sollten, jedoch erst nach den Must-Haves.
- Could: Diese Funktionalitäten können umgesetzt werden, wenn dadurch keine Must-Haves oder Should-Funktionen beeinträchtigt werden.
- Won’t: Diese Funktionalitäten sollten nicht umgesetzt werden.
Die Relative-Weight-Methode dient dazu, dass jedes Backlog Item in den Kategorien Vorteile, Strafen, Risiken und Kosten mit einer Zahl von 1-9 bewertet werden. Die Frage nach den Vorteilen und den Strafen bewerten Product Owner:innen gemeinsam mit relevanten Stakeholder:innen. Dabei wird geklärt, wie groß der Vorteil wäre, wenn eine Anforderung realisiert werden würde, und wie groß die Strafe wäre, wenn eine Anforderung nicht realisiert werden würde.
Die Frage, wie hoch die Risiken der Implementierung und Abhängigkeiten zu anderen Teams und Entwicklungen sind, sowie die Kosten für die Umsetzung bespricht ein:e Product Owner:in mit den Entwickler:innen. Die Werte für Vorteile und Strafen werden durch die Werte für Risiken sowie Kosten dividiert. Aus den Ergebnissen ergibt sich die Priorisierung.
Beim Theme Screening werden neun Beurteilungskriterien identifiziert und anschließend ein Backlog Item ausgewählt, welches als Basis für eine relative Bewertung dient. Dabei ist ein Element empfehlenswert, welches dem Entwicklungsteam vertraut ist und in nächster Zeit umgesetzt werden soll.
Danach werden die Items in den Beurteilungskriterien im Verhältnis zu diesem Backlog Item mit plus, minus oder einem neutral bewertet. Die Priorisierung entsteht durch das Addieren und Subtrahieren der Werte.
Es gibt noch viele weitere Methoden. Jede Organisation sollte für sich entscheiden, welche sich am besten für sie eignen.
Analogien im traditionellen Projektmanagement
Der Backlog ergänzt oder tritt an die Stelle von Spezifikation, Leistungsverzeichnis und Lastenheft im traditionellen Projektmanagement.
