Sprint-Backlog vs. Product-Backlog

Backlog-Eigentum

Der Product Owner besitzt das Product Backlog und priorisiert es im Namen der Stakeholder. Das Sprint Backlog ist Eigentum des Teams und es ist der alleinige Schiedsrichter über seinen Inhalt.

Inhalt des Sprint Backlogs

Das Sprint Backlog enthält User Stories, die während der Sprint-Planung ganz oben aus dem Product Backlog herausgesprungen sind. Das Sprint Backlog enthält jedoch normalerweise viele Dinge, die nicht im Product Backlog enthalten sind, wie zum Beispiel:

1. Aufgaben, die aus den vom Team für die aktuelle Iteration akzeptierten User Storys zerlegt wurden.
2. Story Points oder Zeitschätzungen für einzelne Aufgaben.
3. Verfeinerungen der „Definition of Done“ in Bezug auf eine bestimmte Geschichte oder Aufgabe.
4. Verfeinerungen von Stories, die das Sprint-Ziel nicht gefährden oder vom Product Owner verlangen, eine vorzeitige Beendigung des Sprints zu fordern.
5. In-Sprint-Storys oder -Aufgaben, die vom Team hinzugefügt wurden, um das aktuelle Sprint-Ziel zu unterstützen.

Das Sprint-Ziel und die für den aktuellen Sprint akzeptierten Storys werden während der Frühjahrsplanung festgelegt, aber Aufgaben (und gelegentlich Storys) im Sprint-Backlog werden vom Team aktualisiert und modifiziert, wie immer sie es für richtig halten – es ist das Artefakt des Teams und gehört ihnen um das Sprint-Ziel zu unterstützen.

Agil bedeutet Veränderung

Während die Stories, die während der Sprint-Planung in das Sprint-Backlog aufgenommen werden, im Allgemeinen festgelegt sind, wird das Team ermutigt, zusätzliche Arbeit aus dem Product-Backlog zu ziehen, wenn sie glauben, dass sie in den aktuellen Sprint passen kann, ohne das Sprint-Ziel zu gefährden, wenn es vorzeitig fertig wird. Darüber hinaus kommen während des Sprints manchmal zusätzliches Wissen oder Informationen ans Licht, und das Team und der Product Owner können gemeinsam Stories aus dem Sprint entfernen, wenn dies dem Team hilft, das aktuelle Sprint-Ziel zu erreichen.

Darüber hinaus sind User Stories Ausgangspunkte für Gespräche mit Stakeholdern (oder dem Product Owner, falls dies durch einen Stellvertreter durchgeführt wird), sodass das Hinzufügen und Löschen von Aufgaben aus dem Sprint Backlog während der Arbeit an Stories durchaus üblich ist. Ein Teil der Kunst von Scrum besteht darin, zwischen Verfeinerungen, die aus der Verringerung des Unsicherheitskegels während eines Sprints resultieren, und Änderungen an Geschichten zu unterscheiden, die das Sprintziel gefährden.

Keine unsichtbare Arbeit, niemals

Im Allgemeinen sollten Sprint-Backlog-Einträge Zerlegungen von Product-Backlog-Einträgen oder unterstützende Aufgaben sein, die Geschichten im aktuellen Sprint zusammenkleben. Auch hier besteht die Kunst darin, zwischen Aufgaben zu unterscheiden, die das Team im Sprint Backlog erstellen muss, um das Sprint-Ziel zu unterstützen, und Geschichten, die im Product Backlog platziert werden müssen.

Wenn Sie beispielsweise eine Story haben, die das Seeding einer Datenbank erfordert, müssen Sie möglicherweise eine Aufgabe zu Ihrem Sprint-Backlog hinzufügen, um einen neuen Datenbankserver zu installieren. Normalerweise wird diese Aufgabe während der Sprint-Planung hinzugefügt, aber die Aufgabe wird möglicherweise erst später im Sprint offensichtlich. In solchen Fällen ist es vollkommen akzeptabel, die neu entdeckten Aufgaben zum Sprint-Backlog hinzuzufügen , solange sie das Sprint-Ziel nicht gefährden oder die in den Sprint aufgenommenen Stories ungültig machen.

Darüber hinausgehende Team Stories gehören eigentlich ins Product Backlog. Beispielsweise ist die Einrichtung einer vollständigen Datenbankarchitektur eine Story, die vom Product Owner als Voraussetzung für andere Storys im Product Backlog priorisiert werden sollte. Diese Arten von Storys werden im Allgemeinen während der Backlog-Pflege und gelegentlich während der Sprint-Planung hinzugefügt; danach werden sie wie jede andere Story im Product Backlog behandelt.

Keine Angst vor dem Product Backlog

[W]wäre es möglich, Dinge wie Elemente aus unserer Retrospektive in das Sprint-Backlog aufzunehmen und zu vermeiden, dass das Produkt-Backlog durcheinander gebracht wird?

Es hängt davon ab, ob. Wenn Ihre Sprint-Retrospektive zu Prozessänderungen oder In-Sprint-Aufgaben für das Team führt, sollten diese Dinge natürlich zu einem der Backlogs hinzugefügt werden. Aufgaben und interne Prozesse gehören ins Sprint Backlog; Teilprojekte, die außerhalb der individuellen Story-Schätzungen Zeit oder Ressourcen verbrauchen, gehören in das Product Backlog.

Haben Sie keine Angst davor, „das Product Backlog zu vermasseln“. Das Product Backlog ist kein unverletzliches, unveränderliches Dokument. Ein gesunder Scrum-Prozess sollte kontinuierliche Gespräche zwischen dem Product Owner und dem Team fördern und das Hinzufügen von Infrastruktur- und Toolchain-Storys zum Product Backlog fördern, damit ihre Kosten und Vorteile für das Projekt und die Organisation sichtbar sind.

Mit Ihrem Eindruck vom Sprint Backlog liegen Sie nicht ganz falsch. Das Product Backlog ist das Werkzeug, das vom Product Owner verwendet wird, um alle Funktionen zu verfolgen, die Stakeholder im Produkt implementiert sehen möchten, während das Sprint Backlog eine Teilmenge des Product Backlog ist, die die aktuelle aktive Sprint-Iteration darstellt.

Aus dem IT BA - Product Backlog vs. Spring Backlog :

Ein Product Backlog ist eine Liste aller gewünschten Produktfunktionen (unabhängig davon, ob Sie diese implementieren möchten oder nicht).

Jeder kann dem Product Backlog jederzeit etwas hinzufügen. Der Product Owner priorisiert es jedoch. Wenn Sie und ich also beide eine Feature-Anfrage hinzufügen, um einem Produkt ein Zitat des Tages hinzuzufügen, könnte der Product Owner dies sehr gut an das Ende des Stapels stellen, was bedeutet, dass er nicht wirklich beabsichtigt, dieses Feature hinzuzufügen.

Das Sprint-Backlog ist eine Aufgabenliste mit Backlog-Elementen, die in der aktuellen Iteration abgeschlossen werden müssen.

Das Sprint Backlog hingegen stellt die aktuelle Sprint-Iteration dar, und sobald ein Sprint beginnt, sollte niemand etwas zum Sprint Backlog hinzufügen oder daraus entfernen. Das Sprint Backlog wird vom Team zusammengestellt – und falls dies nicht klar ist, nur vom Team – indem Elemente aus dem oberen Bereich des Product Backlogs ausgewählt werden. Wenn etwas nicht im Product Backlog ist, sollte es auch nicht im Sprint Backlog sein.

Wenn jemand später Merkmal Y zur Liste hinzufügen möchte und es sich um ein Element mit hoher Priorität handelt, wird es dennoch in das Product Backlog aufgenommen, und wenn es ein Merkmal ist, das wichtig genug ist, kann der Product Owner es an die Spitze des Product Backlog verschieben dass es wahrscheinlich in der nächsten Sprint-Iteration ausgewählt wird.

Die hierarchische Beziehung zwischen einem Product Backlog und einem Sprint Backlog wird durch die Iterationskonfiguration in Ihrer Zeitleiste verursacht (indem Sie Sprint-Iterationen der Release-Iteration unterordnen). Jede Zeitleiste kann eine Backlog-Iteration haben (die normalerweise dem Product Backlog zugeordnet wäre).

Ich kann mir keine Vorteile vorstellen, wenn man das Scrum Backlog Tool zu einer übergeordneten Iteration macht. Indem es mit der Zeitleiste als definierte Backlog-Iteration verknüpft wird, erhält es einen besonderen Status. Wenn Sie es zur Iterationshierarchie hinzufügen, werden die Dinge wahrscheinlich nur zusammengewürfelt (Sie haben beispielsweise mehr Ebenen zum Navigieren, wenn Sie eine Iteration auswählen). Es kann auch Probleme mit Roll-Up-Anzeigen in den Plänen verursachen – Sie sehen jetzt möglicherweise Roll-Ups im Product Backlog, was nicht der Zweck ist und die Arbeit damit erschweren kann.