Scrum Training Scrum Foundation Scrum Master Product Owner FAQ EN

Was ist ein Product Backlog in Scrum?

Ein Produkt kann ein Service, Produkt oder Software sein. Das Produkt Backlog ist die Liste der Funktionen und User Stories eines Produktes. Die Funktionsliste wird häufig mit Trello oder Jira gepflegt. Die wertvollsten Funktionen des Product Backlogs werden sortiert. Die wichtigste Funktion liegt oben und wird als wichtigste Funktion definiert. Im Refignment Meeting wird der Umfang der Funktionalitäten geschätzt. In den Refignment Meetings werden die Funktionen vom Product Owner mit den Entwickler definiert und erkannt. Ein Refignment Meeting darf nicht mehr als 10 % der Entwicklungszeit entsprechen. Der Product Owner pflegt das Product Backlog.

Das erste oder initiale Product Backlog, die Aufgabenliste ist beim Beginn der Erstellung umfangreich. Der Product Owner muss bei der Definition der User Stories eine Vision zum Produkt haben. Bei der Erstellung der User Stories wird das Entwicklungsteam und deren Expertise benötigt. Er muss die Produktlinie und Roadmap der Produkte und des Produkts des Unternehmens kennen. Das erste funktionsfähige Produkt und vom Kunden akzeptierte Produkt ist Minimum Viable Product (MVP) woraufhin Feedback für die Weiterentwicklung gegeben werden kann. Stackholder wie Kunden oder Käufer können und sollen die Anforderungen mit definieren und Feedback geben.

Der Product Backlog ist eine Liste von Funktionen des Produktes, Services oder Hardware. Die Funktionen einer Software oder Hardware werden in einen "Requirements Workshop" mittels Kreativitätstechniken ermittelt. Der Product Owner baut den Product Backlog auf in denen sich die Aufgaben sogenannte Product Backlogs Items (PBI's) befinden. Die Funktionen können in einer Exceltabelle oder in Tools wie Jira dokumentiert werden. Mit Jira ist es möglich das Produkt Backlog zu teilen oder Sortierungen vorzunehmen. Viele Scrum Teams verwenden Sticky Notes auf denen Anforderungen geschrieben. Auf die Rückseite einer Sticky Note ist es möglich Akzeptanzkriterien einer Funktion zu beschreiben. Durch das haptische, der Flexibilität im Umgang und das hängen der Stick Note an eine Wand wird der Dialog und die Kommunikation gefördert. Der Product Owner nimmt die Priorisierungen der Anforderungen vor. Die Anforderungen welche wichtig und umgesetzt werden sollen, stehen oben und sind gut definiert, strukturiert und können in einen Sprint von maximal vier Wochen bearbeitet werden. Die Priorisierungen können nach Umsatz, Kosten, Risiko, Risiko-Wert-Abschätzung und Wissensaufbau vorgenommen werden. Aufgaben welche einen hohes Risiko und Wert haben sollten priorisiert werden sodass Unsicherheiten bereinigt werden. Sodann werden Aufgaben priorisiert welche ein niedriges Risiko und einen hohen Wert haben. Sodann werden Aufgaben priorisiert welche ein niedriges Risiko und Wert haben. Aufgaben mit hohen Risiko wo kein wertvolles Inkrement geliefert werden kann, sollten nicht priorisiert sondern gelöscht und vermieden werden.

Ein Product Backlog sollte nach DEEP gestaltet sein. Detailed oder Detailliert. Die Aufgaben und User Stories im Product Backlog sind ausführlich formuliert und erfüllen die Qualitätskriterien der Definition of Ready und weitere individuelle Qualitätskriterien für eine User Story. Das Product Backlog sollte ein Fülle von Aufgaben für die nächsten 1-2 Sprints haben. Emergent oder entstehend. Das Product Backlog und die User Stories können abgeändert, erweitert oder entfernt werden (agiler Ansatz). Estimated oder abschätzend. Der Aufwand sollte abgeschätzt werden können sodass die Ressourcen für einen Sprint und die Umsetzung geplant werden können. Prioritized oder priorisiert. Die User Story muss nach für den Kunden wichtigen Funktionen sortiert werden können. Eine Priorisierung muss nach Wertschöpfung, Komplexität (Unbekannte früh begegnen), Umsetzbarkeit (Einträge müssen mit der vorhanden Expertise umgesetzt werden können), Unabhängigkeit (User Stories müssen für sich alleinstehend sein). Der Product Owner erstellt und pflegt mit dem Scrum Master und Entwicklungsteam das Product Backlog.

In Jira sieht das Backlog folgendermaßen aus; Eine Story kann durch Create Issue erstellt werden:

Backlog in Jira

Product Backlog in Jira

Ein Product Backlog enthält Product Backlog Items (PBIs). Ein Product Backlog Item welches oben im Backlog Item liegt (und am wertvollsten für den Kunden is), sollte nach dem INVEST (Independent, Negotiable, Valuable, Estimatable, Small, Testable) Prinzip gestaltet sein. Als Product Backlog Items können Funktionen (Features), Softwarefehler (Defects oder Bugs), technische Arbeiten (Infrastrukturaufgaben, CI/CD Aufgaben, Deployment Pipeline usw.) oder Experimente zur Wissensanreicherung aufgeführt werden. Die Funktionen können bevorzugt in einer User Story, Use Case oder frei in Textform beschrieben werden. Projekte können technisch mangelhaft gestaltet sein. Diese Mängel werden als Defekt aufgeführt (technische Schuld oder technical dept). Softwarefehler können auch in einen gesonderten Backlog oder issue tracker geführt werden. Jedes Product Backlog Item muss auch eine Schätzung des Aufwands mit aufgeführt haben.



Anfrage zu EXIN Agile Scrum

Sie wollen ein EXIN Agile Scrum Training absolvieren? Bitte füllen Sie folgendes Formular aus. Wir melden uns dann bei Ihnen.

EXIN Partner




Vorname
Nachname
E-Mail
Nachricht