Product Backlog – Ready, Set, Done

Product Backlog

Der Product Backlog wird als Artefakt im Scrum Guide von Ken Schwaber und Jeff Sutherland geprüft. Wir schauen uns im Detail nun an was ein Product Backlog eigentlich ist, wer damit arbeitet und auf welche Art und Weise man diesen managen kann.

Was ist ein Product Backlog?

Der Product Backlog zeigt eine Liste von Funktionalitäten eines Produkts auf. Der Product Owner verwaltet und managt den Product Backlog und sorgt dafür, dass diejenigen Einträge priorisiert werden die den höchsten Kundenwert demonstrieren. Dabei ist der Product Owner stets darauf bedacht nah am Markt und am Nutzer zu arbeiten. Der Product Backlog ist die einzige Quelle für die Aufnahme von Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen.

Was sind Product Backlog Einträge?

Man hört oftmals die Begriffe User Stories und EPICs zur Festhaltung von Anforderungen. Diese Begriffe beschreiben verschiedene Typen von Product Backlog Einträgen.

Dazu gehören die folgenden:

  • Themes / Komponenten – Eine große Ansammlung von mehreren Anforderungen und Produktideen/bereichen
  • EPICs – Dies sind große Features, welches noch heruntergebrochen werden müssen
  • User Stories – Diese sollten so klein wie möglich sein und maximal eine Kapazität von 1/3 des Sprints aufweisen. User Stories sind ein spezielles Format um kundenzentrierte Features zu beschreiben
  • Tasks / Aufgaben – sind meist kleiner und maximal 1 Tag lang. Tasks werden definiert als Unteraufgaben von Backlogeinträgen.
  • Defekte / Fehler – abhängig von Größe und Komplexität

Was ist Bestandteil von einem Product Backlog Eintrag?

Ein Product Backlog Eintrag, nach dem Scrum Guide, enthält eine Beschreibung, eine Indikation der Reihenfolge, eine Schätzung (wird immer vom Entwicklungsteam gemacht) und den Wert.

In der Beschreibung werden die Funktionalitäten betrachtet, die als Anforderung definiert werden. Ein beliebtes Format ist das User Story Format von Rachel Davies:

Als <User> möchte ich <was?>, sodass ich <warum?>

Ein einfaches Beispiel: Als <User> möchte mich in mein <Benutzerkonto einloggen>, sodass ich <mein Passwort ändern kann>.

Das Schreiben einer User Story sollte immer aus dem Blick eines Nutzers erfolgen. Eine User Story wie “Als Backend Developer möchte ich” beschreibt nicht den Endnutzer, sondern einen Begünstigten im Teamkonstrukt. Verpflichtet ist dieses Format nicht. Manchmal bietet es sich auch an einfach eine Kurzbeschreibung im Backlog Eintrag zu verfassen. 

Zusätzlich dazu werden Akzeptanzkriterien geschrieben, die nicht anderes sind, als eine Liste von Anforderungen / Funktionalitäten die erfüllt sein müssen. Die Akzeptanzkriterien werden oftmals als Vorlage zum Schreiben von Tests benutzt. 

Bleibt ein Product Backlog immer gleich?

Der Product Backlog ist ein lebendes Artefakt, entwickelt sich kontinuierlich weiter und schärft sich mit der Zeit. Das Scrum Team versucht so nah wie möglich am Nutzer zu arbeiten und lässt regelmäßig Feedback einfließen in ihre Betrachtungen. Die Reihenfolge der Anforderungen sollte ständig gereviewed werden. Dabei wird stets die Relevanz von Anforderungen in Frage gestellt. Man sollte die Größe des Product Backlogs stets im Blick haben. Wenn ein Product Backlog stetig anwächst, ohne dass wichtige Funktionalitäten umgesetzt werden, so fällt man schnell in ein Loch der Ratlosigkeit. Was ist denn nun wichtig und was sollte ich hinten anstellen?

Wie wird der Product Backlog verwaltet?

Wie bereits oben kurz beschrieben ist der Product Owner dafür zuständig den Product Backlog zu verwalten. Der Scrum Master kann hierbei ebenfalls eine zentrale Rolle spielen und dem Product Owner richtungsweisend Instrumente geben um den Backlog effektiver zu managen.

Wenn mehrere Scrum Teams gemeinsam an einem Produkt arbeitet, so wird ganz klar empfohlen nur einen Product Backlog zu nutzen und mittels Attribute (Komponenten / EPICs in Jira z.B.) die Einträge der Teams voneinander zu unterscheiden.

Damit stets ein Nachschub für den nächsten Sprint da ist wird regelmäßig ein Verfeinerungsmeeting, auch Backlog Refinement genannt, durchgeführt um die Einträge zu besprechen, anzupassen und Schätzungen festzulegen über die Komplexität einer Anforderung. Der Product Owner oder Stakeholder stellen die Backlog Einträge vor und das Entwicklungsteam stellt Fragen und schätzt. Es empfiehlt sich nicht mehr als 10% Zeit des Sprints zu nutzen für das Refinement von Einträgen.

Der Product Backlog sollte stets eine Reihenfolge aufweisen, um Reifegrad und Nutzen widerzuspiegeln. Weit oben angeordnete Einträge können schneller umgesetzt werden, wobei weiter unten eingeordnete Einträge meist noch in ein Refinement müssen um mehr Informationen zu sammeln und einen <Ready> Status zu erreichen. Dieser Ready Status beschreibt, wann ein Product Backlog Eintrag als Bestandteil eines Sprint Backlogs definiert werden kann. Ein Sprint Backlog ist eine Liste von Einträgen, die im nächsten Sprint umgesetzt werden sollen. Dieser Sprint Backlog wird in einem Sprint Planning erstellt. Am Ende wird ein Produkt Inkrement erstellt, welches die Summe aller Product Backlog Einträge beschreibt, die im Sprint umgesetzt worden. Der <Done> Status sagt aus, wann ein Sprint Backlog Eintrag als fertig gilt und alle definierten Kriterien in der Umsetzung erfüllt hat.

Das folgende Schaubild zeigt dies noch einmal:

Ready & Done Status

Product Backlog Management Tools

Um die bereits getane Arbeit im Backlog zu überprüfen und mit definierten Zielen zu vergleichen gibt es verschiedene Fortschrittsprognosen, die man nutzen kann. 

Dazu gehört beispielsweise ein Burndown oder ein Burn Up Diagram. Diese Diagramme zeigen an, wieviel Arbeit im Product Backlog oder z.B. im Sprint Backlog getan wurde bereits und wieviel noch übrig bleibt.

Ein Burndown Chart

Burndown und Burn Up Charts sind durchaus nützlich zur Überwachung von Zielerreichungen, jedoch ersetzen diese nicht die Wichtigkeit von empirischem Vorgehen und der Inspizierung und Adaption von Prozessen.

Zusätzlich zu diesen Charts gibt es eine Reihe von agilen Projektmanagement Tools, denen man sich bedienen kann. Am populärsten ist hier wohl Jira zu nennen. Jira hat sich als Tool zur Pflege und Verwaltung von Product Backlogs und dem Scrum Vorgehen bewährt und wird von vielen Softwareentwicklungsteams genutzt. 

Zusammenfassung

Dein Product Backlog ist ein lebendes “Dokument”. Der Backlog steht niemals still. Wichtig ist, dass man sich nah am Markt platziert und auf Veränderungen flexibel reagieren kann. Kundenfeedback hilft bei der Reflektion und Adaption eines Backlogs. Sind meine angedachten Features wirklich so kundenzentriert und relevant, wie ich gedacht habe? Inspiziere und adaptiere regelmäßig. Ein Stillstand kann heutzutage tödlich für ein Produkt sein. 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.