Produkt-Backlog – Informationen und Tipps zur Erstellung

Ein ordentliches Produkt-Backlog ist wie ein gesunder Mensch: gut gepflegt, organisiert und offen für Änderungen.

Dan Radigan Von Dan Radigan
Themen durchsuchen

Ein gut priorisiertes agiles Backlog vereinfacht nicht nur die Release- und Iterationsplanung, sondern beinhaltet alle Aufgaben für dein Team – einschließlich interner Aufgaben, die der Kunde nie zu sehen bekommt. Das Backlog hilft, Erwartungen von Stakeholdern und anderen Teams einzudämmen, wenn diese zusätzliche Aufgaben an das Team herantragen, und macht die Entwicklungszeit zu einer festen Ressource.

Was ist ein Product Backlog?

Ein Produkt-Backlog ist eine priorisierte Liste von Aufgaben für das Entwicklerteam, die von der Roadmap und ihren Anforderungen abgeleitet wird. Die wichtigsten Elemente werden im oberen Bereich des Produkt-Backlogs angezeigt, damit das Team weiß, woran es zuerst arbeiten muss. Das Entwicklerteam arbeitet sich nicht in der vom Produktinhaber vorgegebenen Geschwindigkeit durch das Backlog, und der Produktinhaber verteilt keine Aufgaben an das Entwicklerteam. Stattdessen entnimmt das Entwicklerteam Aufgaben aus dem Produkt-Backlog, wenn die Kapazität dafür vorhanden ist – entweder kontinuierlich (Kanban) oder nach Iteration (Scrum).

Profitipp:

Nutze einen einzigen Issue Tracker für alle Aufgaben – und nicht mehrere Systeme, um Bugs, Anforderungen und einzelne Entwicklungsaufgaben zu verfolgen. Bewahre alle Aufgaben für das Entwicklerteam in einem einzigen Backlog auf.

Roadmap und Anforderungen als Grundlage

Die Roadmap und die Anforderungen eines Teams bilden die Grundlage für das Produkt-Backlog. Roadmap-Initiativen werden in mehrere Epics unterteilt, die wiederum mehrere Anforderungen und User Storys umfassen. Sehen wir uns die Roadmap für ein fiktives Produkt namens "Teams in Space" an.

Agile Roadmap | Atlassian Agile Coach

Da die "Teams in Space"-Website die erste Initiative in der Roadmap ist, wird diese Initiative in Epics (hier in Grün, Blau und Türkis dargestellt) und User Storys für die einzelnen Epics unterteilt.

Agile Initiativen und Epics | Atlassian Agile Coach

Der Product Owner organisiert für das Entwicklerteam alle User Storys in einer einzigen Liste. Er entscheidet möglicherweise, zunächst ein vollständiges Epic bereitzustellen (links). Vielleicht muss mit dem Programm aber auch das Buchen eines vergünstigten Flugs getestet werden und dafür sind Storys aus mehreren Epics erforderlich (rechts). Beide Beispiele sind unten dargestellt.

Agile Epics und Storys | Atlassian Agile Coach

Welche Aspekte können die Priorisierung des Product Owners beeinflussen?

  • Kundenpriorität
  • Dringlichkeit, Feedback zu erhalten
  • Relative Implementierungsschwierigkeiten
  • Symbiotische Beziehungen zwischen Aufgabenelementen (z. B. wenn B einfacher durchzuführen ist, nachdem A abgeschlossen wurde)

Die Priorisierung des Backlogs fällt zwar in die Verantwortung des Produktinhabers, erfolgt aber nicht in einem Vakuum. Effektive Produktinhaber berücksichtigen Input und Feedback von Kunden, von Designern und vom Entwicklerteam, um die Arbeitsauslastung aller Beteiligten und die Produktbereitstellung zu optimieren.

So verwaltest du Produkt-Backlogs effektiv

Nachdem das Produkt-Backlog erstellt ist, muss es regelmäßig gepflegt werden, um mit dem Programm Schritt zu halten. Produktinhaber sollten das Backlog vor jedem Iterationsplanungsmeeting überprüfen und sicherstellen, dass die Priorisierung nach wie vor korrekt ist und das Feedback der letzten Iteration berücksichtigt wurde. Regelmäßige Backlog-Reviews werden in agilen Kreisen oft als "Backlog-Pflege" bezeichnet (manchmal wird auch der Begriff Backlog-Verfeinerung verwendet).

Wenn das Backlog wächst, muss der Product Owner es in kurz- und langfristige Aufgaben unterteilen. Kurzfristige Aufgaben müssen vollständig ausgearbeitet werden, bevor sie als solche gekennzeichnet werden. Das heißt, User Storys wurden komplett erstellt, die Zusammenarbeit mit Design und Entwicklung ist geplant und die Entwicklung hat ihre Schätzungen abgegeben. Längerfristige Aufgaben können eher vage bleiben, obwohl zumindest eine grobe Schätzung des Entwicklerteams wünschenswert ist, um auch diese Aufgaben priorisieren zu können. "Grob" ist hier ein wichtiger Begriff: Wenn das Team diese längerfristigen Aufgaben vollständig verstanden und mit ihrer Bearbeitung begonnen hat, werden sich diese Schätzungen noch ändern.

Das Backlog stellt die Verbindung zwischen dem Produktinhaber und dem Entwicklerteam dar. Der Produktinhaber kann die Priorität der Aufgaben im Backlog jederzeit neu festlegen, wenn Kunden ihr Feedback übermitteln, Schätzungen neu abgestimmt werden oder neue Anforderungen entstehen. Sobald eine Aufgabe begonnen wird, sollten jedoch nur noch minimale Änderungen vorgenommen werden, um das Entwicklerteam nicht zu stören und Fokussierung, Arbeitsfluss und Moral nicht zu beeinträchtigen.

Profitipp:

Wenn das Backlog die langfristige Kapazität des Teams übersteigt, können Vorgänge geschlossen werden, die das Team nicht in Angriff nehmen kann. Kennzeichne diese Vorgänge in der Vorgangsverfolgung des Teams beispielsweise als "Out of Scope", damit sie später noch einmal überprüft werden können.

Anti-Pattern, die vermieden werden sollten

  • Der Product Owner legt die Prioritäten im Backlog zu Beginn des Projekts fest, passt diese aber nicht an, wenn Feedback von Entwicklern und Stakeholdern zurückkommt.
  • Das Team begrenzt die Elemente im Backlog auf kundenorientierte Aufgaben.
  • Da das Backlog lokal gespeichert und nur selten geteilt wird, werden Aktualisierungen nicht an alle Beteiligten weitergegeben.

Agile Teams dank Produkt-Backlogs

Erfahrene Product Owner pflegen das Backlog ihres Programms sorgfältig, um eine verlässliche Übersicht der Aufgabenelemente eines Projekts bereitzustellen, die vom Team geteilt werden kann.

Stakeholder fechten Prioritäten an und das ist gut so. Diskussionen über die wichtigen Dinge sorgen dafür, dass die Prioritäten aller Beteiligten gleichberechtigt berücksichtigt werden. Solche Diskussionen unterstützen eine Kultur der Gruppenpriorisierung, die sicherstellt, dass alle am Programm Beteiligten auf derselben Linie sind.

Denke daran, dass das Produkt-Backlog auch als Grundlage für die Iterationsplanung dient. Alle Aufgabenelemente sollten in das Backlog aufgenommen werden: Benutzerberichte, Bugs, Designänderungen, technische Schulden, Kundenanfragen, Aufgaben aus der Retrospektive usw. Auf diese Weise kann sichergestellt werden, dass alle Aufgabenelemente für jede Iteration in die Gesamtdiskussion einbezogen werden. Die Teammitglieder können dann Kompromisse mit dem Produktinhaber eingehen, bevor sie eine Iteration beginnen, mit vollständiger Kenntnis von allem, was getan werden muss.

Profitipp:

Product Owner legen die Priorität der Aufgabenelemente im Backlog fest, während das Entwicklerteam durch das Backlog die Velocity bestimmt. Neue Product Owner , die Aufgaben an das Team "verteilen" möchten, können auf einem unsicheren Posten stehen. Mehr dazu erfährst du in unserem Artikel zu Grenzen und Fluss der Work-in-Progress (WIP).

Agile-Pfeil

Priorisiere die wichtigen Dinge mit der Jira Scrum-Vorlage

Verschaffe dir einen vollständigen Überblick über die gesamte zu erledigende Arbeit und konzentriere dich auf die größte Wirkung.

Weiter geht's
Sprint-Reviews