Scrum: Wie verfeinert man das Product Backlog?

Nicht alle Items im Product Backlog haben gleichzeitig die gleiche Größe und den gleichen Detaillierungsgrad (dh Features / Epics / User Stories und Tasks). PBIs, an denen wir bald arbeiten wollen, sollten ganz oben im Rückstand stehen, klein und sehr detailliert sein, damit sie in einem kurzfristigen Sprint bearbeitet werden können. PBIs, an denen wir einige Zeit nicht arbeiten werden, sollten am Ende des Rückstands stehen, größer und weniger detailliert sein.

Use Cases / Features  sind Funktionen, die Ihre Endbenutzer haben werden, die sie vorher nicht hatten. Beispielsweise wäre der Online-Kauf von Artikeln über Ihr Mobiltelefon eine Funktion. Ihre Produkt-Roadmap besteht normalerweise aus Anforderungen auf Funktionsebene.

Epics  sind die nächste Stufe, um ein Feature in eine umsetzbare Anforderung zu zerlegen. Sie sind eine Reihe von Aktionen, die sich auf die Funktion beziehen. Die Möglichkeit, einen Artikel über Ihr Mobiltelefon aus dem Einkaufswagen mit einer Kreditkarte zu kaufen, wäre ein Epos. Es ist kleiner als eine Funktion (Online-Kauf eines Artikels), aber dennoch größer als die einzelnen Kreditkartenintegrationen, die den Kauf eines Artikels auf einzigartige Weise ermöglichen. Anforderungen, die größer als Epics sind, lassen wir in einem Veröffentlichungsplan nicht zu.

User Stories  sind die kleinsten Formen von Anforderungen, die noch für sich alleine stehen können. Eine User Story besteht aus einer Wertaktion oder einer Wertintegration. Beispielsweise wäre der Kauf eines Artikels über Ihr Mobiltelefon aus dem Warenkorb mit einer Visa-Karte eine User Story. Der Kauf eines Artikels mit einer MasterCard könnte eine andere Integration und damit eine andere User Story sein. User Stories sind klein genug, um sie zu Sprints hinzuzufügen und mit der Entwicklung zu beginnen. In den folgenden Abschnitten gehe ich ausführlich auf User Stories ein.

Aufgaben  sind die internen Schritte, die zur Implementierung der User Story erforderlich sind. Während der Sprintplanung wird eine User Story in Tasks heruntergebrochen. Während Anforderungen Dinge sind, die der Endbenutzer tut, sind Aufgaben das, was das Entwicklungsteam tut, damit die Anforderung funktioniert.

Granularitätsgrad von Product Backlog Items (PBIs)

Die Abbildung zeigt die verschiedenen Ebenen der Anforderungszerlegung, um sie in eine Reihe von Sprints der Entwicklungs-Roadmap einzufügen

• Oben in dieser Abbildung oben sind die orangefarbenen, größten Steine. Sie stellen die Geschäftsziele dar, die durch das System erreicht werden sollen, nämlich Anwendungsfälle oder Benutzerfunktionen.
• Auf der nächstniedrigeren Ebene befinden sich PBIs, die größer als ein einzelner Sprint, aber kleiner als ein Release sind. Nennen wir das PBI auf dieser Ebene Epen.
• Auf der dritten Ebene finden wir PBIs, die für einen Sprint geeignet sind – sie können in Tagen statt in Wochen abgeschlossen werden. Diese Elemente erfüllen die  Definition of Ready des Teams  und können als User Storys dargestellt werden.
• Auf der untersten Ebene können diese PBIs optional in Aufgaben aus einer User Story heruntergebrochen und am Ende einer einzigen Iteration geliefert werden.

Produktrückstand

Das Product Backlog listet alle erforderlichen Ergebnisse auf. Der Inhalt ist nach Geschäftswert geordnet. Wie oben erwähnt, werden die wichtigsten Elemente oben im Product Backlog angezeigt, damit das Team weiß, was es zuerst liefern muss. Die Priorität von Backlog Items kann sich ändern, Anforderungen können hinzugefügt und entfernt werden – somit ist das Product Backlog ein kontinuierlich gepflegter Plan für einen wachsenden Geschäftswert.

Product-Backlog-Einträge

Product Backlog Items (PBIs) sind die Elemente, aus denen das Product Backlog besteht. Product Backlog Items können von Spezifikationen und Anforderungen bis hin zu Anwendungsfällen, Epics, User Stories oder sogar Bugs oder zeitgesteuerten Forschungsaufgaben  reichen  .

Sprint-Planungsprozess

Sprint-Planung ist oft erforderlich, um sicherzustellen, dass das Product Backlog mit Schätzungen und Akzeptanzkriterien  auf ein angemessenes Detailniveau verfeinert wurde   (dies ist der Zweck des Product Backlog Refinement). Wenn die Product Backlog Items während des Product Backlog Refinement Prozesses analysiert und durchdacht wurden, können im Sprint Planning Meeting die Product Backlog Items mit höchster Priorität gut verstanden und einfach ausgewählt werden.

Zusammenfassung

Das Ziel des Product-Backlog-Refinement-Prozesses besteht darin, Product-Backlog-Einträge in einen bereiten Zustand für die Sprint-Planung zu bringen, sodass die Product-Backlog-Einträge:

• Klar genug und verständlich für alle im Team
• Klein genug, um in einen Sprint einbezogen zu werden

Andere empfohlene Scrum-Artikel

• Was sind Scrum-Artefakte?
• Was ist die Definition von Ready in Scrum?
• Wie schreibt man ein Sprintziel?
• Was ist Product Backlog in Scrum? Wer ist dafür verantwortlich?
• Wie verfeinert man das Product Backlog?