Backlog-Management

Geschrieben von Sven Wiegand am 4. Oktober 2015 in Projektmethodik
Geschätzte Lesedauer: 8 Minuten

Das Product-Backlog ist das Steuerungsinstrument des Product-Owners in Scrum. Es ist gleichermaßen bei der Definition der Anforderungen als auch beim Tracking des Fortschritts von zentraler Bedeutung. In diesem Artikel zeige ich Dir, wie Du auch bei vielen User-Stories den Überblick behältst.

Im letzten Artikel haben wir uns mit der Art, wie wir Anforderungen formulieren (User-Stories) und darstellen (Mockups) beschäftig. Heute geht es darum, wie wir diese Anforderungen über die gesamte Projektdauer verwalten.

Das Product-Backlog

Prinzipiell ist das Product-Backlog ein tabellarisches Dokument, das mindestens folgende Spalten enthält:

1. Priorisierung
2. User-Story mit Akzeptanzkriterien
3. Grobabschätzung

Zusätzlich definiert die Position der Einträge im Backlog die Implementierungsreihenfolge. Sicherlich wirst Du noch weitere, auf Dich maßgeschneiderte Spalten zu Deinem Backlog hinzufügen.

Das Backlog ist ein lebendes Dokument, das heißt, es wird während der gesamten Projektdauer verfeinert und angepasst. Wahrscheinlich wirst Du mit vielen Epics starten und dann erst Stück für Stück diese in einzelne Stories aufbrechen.

Story-Status

User-Stories im Product-Backlog durchlaufen verschiedene Status

Diese inkrementelle Herangehensweise erfordert die Möglichkeit, den Status einzelner Anforderungen verwalten zu können. In einer Tabelle kannst Du das einfach über eine Statusspalte realisieren. Ich arbeite dabei mit folgenden Status:

• In Entstehung: Die Story ist noch nicht fertig definiert. Entweder ist es ein Epic, es existiert nur ein Story-Titel oder die Story ist beschrieben aber die Akzeptanzkriterien fehlen noch.
• Entwurf: Ich bin mit der Definition der Story fertig, das heißt Titel, Inhalt, Akzeptanzkritierien und – falls notwendig – Mockup sind vorhanden. Allerdings muss die Story noch mit dem Team und anderen Stakeholdern durchgesprochen werden.
• Abgestimmt: Ich habe die Story in einem Backlog-Grooming (siehe unten) mit dem Team und anderen Stakeholdern abgestimmt und alle sind einverstanden.
• Abgeschätzt: Die Story wurde vom Team mit einer Abschätzung versehen.
• Ready (Bereit): Die Story erfüllt alle Kriterien der »Definition of Ready« (siehe unten) und ist somit bereit, um in ein Planungs-Meeting eingereicht zu werden.
• In Arbeit: Die Story wurde im Rahmen eines Planungs-Meetings in einen Sprint aufgenommen. Hier prüfe ich nicht, ob das Team die Story tatsächlich gerade bearbeitet. Sobald sie im Planungs-Meeting akzeptiert wurde erhält sie diesen Status.
• Done (Erledigt): Die Story ist fertig umgesetzt und wurde im Review-Meeting vom Product-Owner abgenommen.

Bei »Ready« und »Done« habe ich hier die englischen Ausdrücke verwendet, da diese im Umfeld von Scrum weit verbreitet sind. Außerdem passen sie gut zur »Definition of Ready« und zur »Definition of Done«.

Backlog-Groomings

Backlog-Groomings sind eineinhalb- bis zweistündige Meetings in denen ich Stories im Status »Entwurf« mit dem Team und zentralen Stakeholdern durchspreche. Meist decken wir hier diverse Lücken oder Inkonsistenzen auf, die eine Überarbeitung der Story erforderlich machen.

Kleinere Korrekturen nehme ich direkt im Meeting vor. Umfangreichere Anpassungen zum Beispiel an Mockups pflege ich später nach und bringe die Stories dann im nächsten Backlog-Grooming wieder ein.

Definition of Ready

Die »Definition of Ready« ist eine Sammlung von Anforderungen, die eine Story erfüllen muss, damit sie als »bereit« (»ready«) angesehen und in ein Planungs-Meeting eingereicht werden kann. Es liegt in der Verantwortung des Product-Owners, die Einhaltung sicherzustellen.

Alle Anforderungen sollten in großer Schrift auf ein Blatt Papier passen, so dass sie im Team-Raum für jeden deutlich sichtbar aufgehängt werden können. Die Anforderungen, definiert der Product-Owner gemeinsam mit dem Team. Auf meiner »Definition of Ready« befinden sich folgende Punkte:

• Story mit Akzeptanzkriterien existiert
• Mockup existiert
• Story mit Team abgestimmt
• Story von Team abgeschätzt
• Icons vorhanden
• GUI-Texte in Deutsch und Englisch definiert

Auch hierbei handelt es sich um ein »lebendes« Dokument, das über die Zeit hinweg nach Bedarf angepasst wird.

Definition of Done

Die »Definition of Done« beschreibt die Anforderungen, die erfüllt sein müssen, damit eine Story im Review-Meeting abgenommen werden kann. Diese Liste ist also ähnlich den Story-spezifischen Akzeptanzkriterien. Es liegt in der Verantwortung des Teams, die Einhaltung der Anforderungen zu sicherzustellen.

Das Team definiert die Liste und der Product-Owner darf Pflichtpunkte beisteuern. Auch diese Liste wird sich über die Zeit hinweg ändern, darf aber keine Auswirkungen auf die Aufwände eines bereits geplanten Sprints haben.

In meinem Team wird eine Web-Anwendung entwickelt. Daher befinden sich auf der »Definition of Done« unter anderem folgende Punkte:

• GUI in Deutsch und Englisch geprüft
• Unit- und Integrationstests mit 100% Testabdeckung
• Selenium-Tests erstellt
• In IE, Firefox und Chrome getestet
• Code-Review durchgeführt
• Performance geprüft (siehe Architekturdokument)
• Product-Owner hat »ja« gesagt
• Durch QA abgenommen
• JIRA-Issue auf »Confirmed«

Auch die »Definition of Done« sollte für jeden deutlich sichtbar im Team-Raum aufgehängt werden.

Tools

Ich kenne Product-Owner, die verwalten ihr Backlog klassisch mit Karteikarten auf einem Whiteboard. Auch wenn ich nach anfänglicher Skepsis zu einem Verfechter physikalischer Scrum-Boards geworden bin, konnte ich mich mit der Idee eines analogen Backlogs bisher nicht anfreunden. Hier fehlen mir Filter- und Suchmöglichkeiten. Somit stellte sich für mich die Frage nach einem geeigneten Tool.

Da beim Backlog von einem tabellarischen Dokument gesprochen wird, war es für mich naheliegend mit Excel zu starten. Leider hat es sich für mich als untauglich herausgestellt, was im Wesentlichen drei Ursachen hat:

1. Verschachtelte Strukturen (Stories unterhalb ihrer Epics) lassen sich nur schwer abbilden.
2. Das Erfassen von Texten (zum Beispiel Aufzählungen für die Akzeptanzkriterien) ist in Excel unkomfortabel.
3. Und am schlimmsten: Man kann die Anforderungen nicht einfach per Drag-&-Drop in die gewünschte Reihenfolge bringen.

Ein Problem teilt Excel mit vielen anderen Backlog-Tools: Umfangreiche Backlogs mit über 100 User-Stories lassen sich in einer linearen Liste schwer verwalten. Dadurch, dass die Anforderungen gemäß der Implementierungsreihenfolge abgelegt werden, ist eine thematische Gruppierung nicht mehr gegeben.

Bei späteren Projekten fing ich somit an, mich nach dedizierten Backlog-Tools umzuschauen. Diverse Lösungen kamen für mich nicht in Frage, da sie ausschließlich als Cloud-Lösungen verfügbar waren und wir unsere Anforderungen auf lokalen Servern speichern möchten.

Andere Produkte wie zum Beispiel JIRA Agile (damals noch Greenhopper) entsprachen nicht meinen Anforderungen, da sie maximal eine Strukturierungsebene (Epics) boten. Bei umfangreichen Projekten möchte ich aber User-Stories zu einem Thema in Blöcken gruppieren und das auch über mehrere Ebenen (ähnlich der Überschriftenstruktur in einem Lastenheft).

In der Strukturansicht von Agilefant kannst Du User-Stories thematisch anordnen – ähnlich der Überschriftenstruktur eines Lastenhefts.

Das Tool, das ich am Ende gefunden habe und mit dem ich seit zwei Jahren erfolgreich arbeite, ist Agilefant. Agilefant ist ursprünglich als Open-Source-Lösung entstanden. Diese kostenlose Variante ist auch weiterhin verfügbar und es ist auch die Version, die ich nutze. Inzwischen gibt es allerdings noch einen kommerziellen Ableger als Cloud-Lösung oder zum Selbstbetreiben.

Was Agilefant für mich besonders macht, sind die beiden unterschiedlichen Sichten auf mein Backlog. Zum einen existiert eine Strukturansicht, in der ich Stories über beliebig viele Ebenen verschachteln kann und zum anderen gibt es die klassische lineare Tabellenansicht. Letztere zeigt nur die sogenannten »Leaf-Stories« an, also Stories, die keine weiteren untergeordneten Stories besitzen.

Story-Inhalte pflege ich ausschließlich in der Strukturansicht. Dort sind sie – ähnlich einem Lastenheft – thematisch gruppiert. Bei einem neuen Projekt starte ich auf oberster Ebene mit Überschriften. Sobald ich merke, dass eine Story zu umfangreich ist, breche ich sie in untergeordnete Stories auf.

In der klassischen Backlog-Ansicht von Agilefant werden nur Leaf-Stories (Stories ohne weitere Unterelemente) angezeigt. Die Reihenfolge kannst Du per Drag-&-Drop anpassen.

Erst wenn es an die Planung geht, wechsel ich in die tabellarische Ansicht, wo ich dann die Stories bequem per Drag-&-Drop in die gewünschte Reihenfolge bringen kann. Neben dedizierten Feldern für Status, Business-Value und Abschätzungen bietet Agilefant Labels als zusätzliche Strukturierungsmöglichkeit.

Im Rahmen der Sprint-Planung bietet Agilefant auch die Möglichkeit, Stories in Tasks aufzubrechen. Da wir mit einem physikalischen Scrum-Board arbeiten, bleibt diese Funktionalität bei mir aber ungenutzt.

Wo Licht ist, ist auch Schatten und so hat auch Agilefant einige Nachteile:

• Die Liste der möglichen Status die eine Anforderung haben kann, ist fest vorgegeben und passt leider nicht zu meinem eigenen Workflow. Ich löse das über eine teilweise »Zweckentfremdung« der vordefinierten Status in Verbindung mit Labels.
• Mir fehlen viele Bulk-Aktionen (also das gleichzeitige Bearbeiten mehrerer Stories auf einmal). Für einige Anpassungen sind umfangreich Klickarien notwendig.
• Das Burnup-Chart ist zumindest in der von mir noch eingesetzten Version 3.3 sehr beschränkt.
• Mir fehlt eine Integration mit JIRA.
• Das Hinzufügen von Bildern zu Stories ist nicht sinnvoll möglich.
• Die Nutzung per Tastatur ist nur eingeschränkt möglich.

Aufgrund dieser Einschränkungen und der Tatsache, dass mein Team nur einen Lesezugriff benötigt, habe ich ein eigenes Read-Only-Web-Frontend erstellt, das dem Team alle notwendigen Informationen bereitstellt. Labels in einer bestimmten Syntax werden als Mockups dargestellt, die Anlage und Verlinkung von JIRA-Issues erfolgt per Klick und Burnup-Charts werden nach meinen Wünschen generiert. Fehlende Tastatur-Shortcuts im Agilefant-Editor habe ich über Client-seitiges JavaScript nachgerüstet.

Du siehst also: Die Lösung ist alles andere als optimal. Falls Du also ein gutes Backlog-Tool kennst, freue ich mich über Dein Feedback.

Fazit

Mit dem richtigen Workflow und Tool hast Du auch ein umfangreiches Backlog jederzeit im Griff. Und ein sauberes Backlog ist der erste Schritt hin zu Scrum oder anderen agilen Methoden.

Starte mit dem Erfassen der Anforderungen auf abstrakter Ebene (Epics) und brich diese dann auf Einzel-Stories herunter. Im ersten Schritt genügt es, nur die Story-Titel zu definieren.

Je nachdem wie »agil« Dein Unternehmen ist, wirst Du Liefertermine und oder Kosten (gegebenenfalls nur grob) benennen müssen. Meiner Erfahrung nach genügt schon ein Backlog auf Story-Titel-Ebene, um eine Grobabschätzung gemeinsam mit dem Team zu erstellen.

Bringe die Stories danach grob in die abzuarbeitende Reihenfolge. Sorge dann dafür, dass Du Stories für mindestens zwei Sprints »ready« hast, indem Du sie mit Beschreibung, Akzeptanzkriterien und Mockups vervollständigst, in Backlog-Groomings mit dem Team besprichst und in Abschätzungs-Meetings bewertest. Danach kannst Du mit dem ersten Planungs-Meeting starten.

Tags:Agilefant, Backlog, Backlog-Management, Scrum, Tool, User-Story

Trackback von deiner Website.

Sven Wiegand

Ich leite seit 2005 Softwareprojekte und führe Entwicklungsteams in mittelständischen Softwareunternehmen. Nach einigen erfolglosen Projekten auf Basis des konventionellen Wasserfallmodells begann ich 2008, Scrum anzuwenden. Seitdem stellte ich mehrere Teams erfolgreich auf agile Methoden um. Auf »Agil Managen« möchte ich meine Erfahrungen aus der Praxis mit Dir teilen.