Scrum-Leitfaden | 18. Was ist das Product Backlog?

Veröffentlicht: 2022-05-19

Das Product Backlog ist die einzige Quelle für Aufgaben, die vom Scrum-Team ausgeführt werden. Es handelt sich um eine Liste geplanter Produktfunktionen und -verbesserungen. Seine Form ist veränderbar und nicht alle im Product Backlog enthaltenen Aufgaben werden abgeschlossen. Es entwickelt sich während der Diskussionen mit Stakeholdern. Es wird auch ständig verbessert. Das bedeutet, je näher der Abgabetermin rückt, desto detaillierter wird eine Aufgabe.

Was ist das Product Backlog? - Inhaltsverzeichnis:

  1. Einführung
  2. Was beinhaltet das Product Backlog?
  3. Die Form des Product Backlogs
  4. Produkt-Backlog-Verbesserung
  5. Zusammenfassung

Einführung

Das Product Backlog ist das größte der Scrum-Artefakte. Es spiegelt den Stand der Arbeit an einem Produkt in Bezug auf das Produktziel wider. Wenn andererseits die Arbeit an einem Produkt abgeschlossen ist, wird sein Backlog zu einer vollständigen Liste der Aufgaben, die vom Scrum-Team zur Erstellung des Produkts erledigt wurden. Es enthält jedoch keine detaillierten technischen Lösungen.

What is the Product Backlog?

Was beinhaltet das Product Backlog?

Das Product Backlog wird während der Meetings des Product Owners mit Stakeholdern erstellt. Der Product Owner ist der alleinige Eigentümer und die Person, die für diese Aufgabenquelle verantwortlich ist.

Die Geschäftssprache prägt die Einträge im Product Backlog. Mit anderen Worten, sie beschreiben den Wert des Produkts aus Sicht der Stakeholder.

Aufgabenbeschreibungen, die in der Aufgabenliste enthalten sind, müssen kohärent und klar sein. Sie beinhalten Funktionen und Verbesserungen des Produktes, die meist in Form von User Stories dargestellt werden, denen wir einen eigenen Beitrag widmen. An dieser Stelle sei nur erwähnt, dass es sich um Beschreibungen von Teilfunktionalitäten des Produkts handelt, die Fragen zu folgenden Themen beantworten:

  • Der Umfang der Produktänderungen
  • Der Zweck der Änderung des Produkts
  • Der Benutzertyp, für den diese Änderung gilt
product backlog

Die Form des Product Backlogs

Die Reihenfolge der im Product Backlog enthaltenen Aufgaben ändert sich mit der Entwicklung des Produkts. Während der Arbeit daran formt und verbessert das Scrum-Team seine Funktionalitäten. Wenn sie auf Hindernisse stoßen, ermöglichen ihre umgesetzten Maßnahmen allen, über zukünftige angemessene Lösungen nachzudenken und diese zu definieren, und auch diese werden sich entsprechend ändern, wenn unvorhergesehene weitere Hindernisse auftreten. Daher gibt es keine klare und definierte Reihenfolge der Aktionen, alles ist veränderbar. Die Verbesserung des Product Backlogs zielt auf seine kontinuierliche Aktualisierung und Vorbereitung auf die nächsten Aufgaben ab. Aus diesem Grund ist es kontinuierlich.

Aufgaben mit weit entfernter Deadline sind typischerweise große, allgemeine Ganzheiten. Ihre Beschreibung enthält keine Details, sondern nur eine Skizze der zu realisierenden Funktionalität. Es ist auch möglich, Aufgaben darunter zu finden, die niemals beendet werden.

Einträge im Product Backlog können alternative Lösungen präsentieren. Und auch Ideen des Kunden, die vielleicht veraltet, unrentabel oder aus anderen Gründen nie in die Umsetzungsphase gelangen. Aus diesem Grund wird das Product Backlog manchmal scherzhaft als „Wunschliste des Kunden“ bezeichnet.

Ein weiterer Grund für Änderungen in der Form des Product Backlogs ist die Neudefinition von Lösungen. Manchmal stellt sich heraus, dass ein bestimmtes Problem bereits gelöst wurde, während eine andere Produktfunktionalität erstellt wurde. Oder die erwartete Funktionalität ist aufgrund von Änderungen in anderen Lösungen überflüssig geworden.

Eine der grundlegenden Aktivitäten während der Verbesserung des Product Backlogs ist die Aufteilung der im Product Backlog enthaltenen Aufgaben in Teile. Dadurch wird der allgemeine Überblick über die Funktionalität in Form von kleineren, detaillierteren und präziser definierten Einheiten dargestellt.

Aufgaben, die auf eine engere Umsetzung ausgelegt sind, werden detaillierter. Sie werden auch kleiner und enthalten Details von Lösungen. Details entstehen während der Produktentwicklung. Und dank der Kenntnis des aktuellen Zustands des Produkts und der aktuellen Erwartungen der Stakeholder ergänzt der Product Owner die anstehenden Aufgaben mit ihrer Beschreibung, Reihenfolge und Größe. Wählt dann die am besten beschriebenen Aufgaben für das nächste Sprint Backlog aus.

Produkt-Backlog-Verbesserung

Während der Arbeit an einem Produkt modifiziert und detailliert der Product Owner das Product Backlog in Zusammenarbeit mit dem Entwicklungsteam. Gemäß den Vorschlägen des Product Owners wählt das Team während der Sprint-Planung Features aus, die aus dem Product Backlog implementiert werden sollen. Sie werden dann in das Sprint Backlog verschoben und in zu erledigende Aufgaben unterteilt. Die in das Sprint Backlog verschobenen Aufgaben werden in technischer Sprache beschrieben, die für Entwickler am nützlichsten ist.

Die Aufgabengröße ist aus Sicht des Entwicklungsteams eine wichtige Kennzahl. Seine richtige Einschätzung wird besonders kritisch, wenn User Stories aus dem Product Backlog zum Sprint Backlog ausgewählt werden.

Das Entwicklungsteam lernt im Laufe der Zeit, den Zeit- und Arbeitsaufwand für die Fertigstellung einer bestimmten User Story richtig einzuschätzen. Dies wird in Tagen, Arbeitsstunden oder Story Points ausgedrückt und liefert eine Schätzung eines Werts namens Team Velocity.

Zusammenfassung

Das Product Backlog ist eine kontinuierlich verbesserte Liste von Aufgaben, die zum Produktziel führen. Der Inhalt des Product Backlogs wird üblicherweise in Form von User Stories ausgedrückt. Und je kürzer die Zeit bleibt, um eine Aufgabe zu erledigen, desto:

  • Die Stellenbeschreibung ist ausführlicher
  • Der Umfang der Aufgabe ist kleiner
  • Der Umfang der Aufgabe ist besser definiert

Das Scrum Team kümmert sich um die Aufgaben. Der Product Owner verwaltet und modifiziert das Product Backlog.

Wenn Ihnen unsere Inhalte gefallen, werden Sie Teil unserer fleißigen Bienen-Community auf Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 18. What is the Product Backlog? caroline becker avatar 1background

Autorin: Caroline Becker

Als Projektmanagerin ist Caroline Expertin darin, neue Methoden zu finden, um die besten Arbeitsabläufe zu gestalten und Prozesse zu optimieren. Ihre organisatorischen Fähigkeiten und ihre Fähigkeit, unter Zeitdruck zu arbeiten, machen sie zur besten Person, um komplizierte Projekte in die Realität umzusetzen.

Scrum-Leitfaden:

  1. Glossar der Grundbegriffe, Rollen und Begriffe
  2. Was ist Scrum?
  3. Scrum-Werte
  4. Wie implementieren Sie Scrum in Ihrem Unternehmen?
  5. Scrum Team – was ist das und wie funktioniert es?
  6. Wer ist ein Product Owner?
  7. Die häufigsten Fehler des Product Owners
  8. Wer ist der Scrum-Master?
  9. Eigenschaften eines guten Scrum Masters
  10. Die häufigsten Fehler des Scrum Masters
  11. Welche Statistiken und Metriken sollte der Scrum Master verfolgen?
  12. Zusammenarbeit zwischen Product Owner und Scrum Master
  13. Entwicklungsteam in Scrum
  14. Die häufigsten Fehler von Entwicklern
  15. Scrum-Artefakte
  16. Scrum skalieren
  17. Sprint-Rückstand
  18. Was ist das Product Backlog?
  19. Was sind User Stories?
  20. Erstellen Sie die beste User Story mit INVEST
  21. Die häufigsten Fehler in User Storys
  22. Akzeptanzkriterien für User Storys
  23. Schätzung und Story Points in Scrum
  24. Planungspoker
  25. Team-Schätzspiel
  26. Inkrement definieren
  27. Scrum-Ereignisse
  28. Was ist Sprint in Scrum?
  29. Verpflichtungen des Scrum-Teams – Produktziel, Sprintziel und Abschlussdefinition
  30. Was ist ein Burndown-Diagramm?
  31. Wie erstellt und interpretiert man ein Burndown-Diagramm?
  32. Vor- und Nachteile des Burndown-Charts
  33. Kanban-Boards in Scrum und Scrumban
  34. Velocity in Scrum - Schnelligkeit des Entwicklungsteams
  35. Tägliches Scrum
  36. Sprint-Planung
  37. Sprint-Review
  38. Was ist eine Sprint-Retrospektive?
  39. Häufige Fehler während einer Sprint-Retrospektive
  40. Pflege des Produkt-Backlogs