die drei scrum Artefakte

Die drei Artefakte im Scrum-Framework geben die Struktur vor, welche die Transparenz und den Informationsaustausch im Entwicklungsprozess fördert. Das iterative Vorgehen ermöglicht Sichtbarkeit und Klarheit über den Arbeitsfortschritt.

Product Backlog: mit Produktziel und Produktvision, Arbeitsspeicher für Arbeiten für die nächsten Monate.
Sprint Backlog: mit Sprint-Ziel, Gefäss für Arbeiten im nächsten Sprint.
Product Increment: Das Produkteinkrement gemäss der Definition of Done (DoD) entspricht dem momentan angebotenen Produkt.

Jedes dieser Artefakte trägt zur Transparenz bei (transparency) und schafft damit die Möglichkeit, das Erarbeitete in den Scrum-Events zu überprüfen (inspect) und nötige Anpassungen (adapt) zu treffen.

Das Product Backlog

Das Product Backlog ist der Arbeitsspeicher für das Scrum Team. Es umfasst alle Arbeiten, welche das Scrum Team ausführt. Mit seiner Struktur und Funktionsweise stellt das Product Backlog sicher, dass das Scrum Team stets an den wichtigsten und für den Kunden wertvollsten Aufgaben arbeitet und sich flexibel an neue Anforderungen und Erkenntnisse anpasst.

Produktvision und Produktziel
Anhand der Produktvision formuliert der Product Owner das Produktziel. Dieses gibt die Richtung vor und sorgt für Alignment während der Sprints.

Zweck des Product Backlogs
Das Product Backlog enthält alle Aufgaben, die für die Entwicklung eines Produkts erforderlich sind. Diese Aufgaben werden als "Product Backlog Items" (PBIs) bezeichnet und können Features, Bug-Fixes, technische Verbesserungen und andere Aktivitäten umfassen.
Während der Sprint Plannings wählen die Entwickler ein Subset von Product Backlog Items aus dem Product Backlog aus und kreiieren damit das Sprint Backlog.

Unsere Registered Scrum Trainer

Philipp Engstler

Mirko Kleiner

Verantwortung für das Product Backlog
Der Product Owner ist als einziger befugt und verantwortlich für das Priorisieren der Product Backlog Items im Product Backlog. Der Scrum Master unterstützt den Product Owner bei der Pflege des Product Backlogs. Neue Einträge können von allen Scrum Team Mitgliedern und Stakeholdern erfasst werden.
Die Definition of Ready (DoR), welche vom Scrum Team definiert wird, stellt die Qualität der PBIs sicher.

Funktionsweise des Product Backlog

Die Items im Product Backlog sind priorisiert, wobei die wichtigsten und wertvollsten Aufgaben an oberster Stelle stehen.
Das Product Backlog ist ein lebendiges Dokument, das sich im Laufe der Zeit entwickelt und angepasst wird. Es wird regelmässig aktualisiert, um Änderungen in den Anforderungen, neuen Erkenntnissen und Rückmeldungen aus den Sprints Rechnung zu tragen.
Die Items im Product Backlog sollten in einer Weise formuliert sein, dass sie verständlich und umsetzbar sind. Dies umfasst eine klare Beschreibung, Akzeptanzkriterien und, falls notwendig, zusätzliche Dokumentation oder technische Details.

Das Product Backlog Refinement
Das Product Backlog Refinement ist ein kontinuierlicher Prozess, bei dem das Scrum Team daran arbeitet, die Details der Backlog-Items zu klären, klein zu schneiden und Schätzungen zu aktualisieren. Dieser Prozess trägt dazu bei, dass das Team gut vorbereitet ins nächste Sprint Planning gehen kann. Refinements sollten nicht mehr als 10% der Sprintkapazität in Anspruch nehmen.

Das Sprint Backlog

Das Sprint Backlog beinhaltet ein Subset aller Aufgaben aus dem Product Backkog, auf welche sich das Team während des nächsten Sprints fokussieren wird um das selbst gesetzte Sprintziel zu erreichen. Es ist ein Werkzeug zur Schaffung von Transparenz und Fokus auf die wichtigsten Arbeiten für den Erfolg des Produktes.

Das Sprintziel
Das Sprintziel wird beim Sprint Planning durch das Scrum Team definiert. Es gilt als Leitstern während des Sprints.

Zweck des Sprint Backlogs
Das Sprint Backlog ist eine Liste von Aufgaben und Anforderungen, die das Scrum Team während eines Sprints umsetzen möchte. Es repräsentiert einen Ausschnitt des Product Backlogs, der für den aktuellen Sprint ausgewählt wurde.

Verantwortung für das Sprint Backlog
Das Scrum Team ist verantwortlich für die Erstellung, Pflege und Aktualisierung des Sprint Backlogs. Dies gilt während des Sprint Plannings und dem gesamten Sprint.
Der Scrum Master unterstützt das Team, indem er sicherstellt, dass das Sprint Backlog transparent und aktuell gehalten wird.

Die Erstellung und Pflege des Sprint Backlogs erfordert eine enge Zusammenarbeit zwischen den Entwicklern und dem Scrum Master. Er stellt sicher, dass die ausgewählten PBIs gut genug verstanden sind, damit das Team sie in detaillierte Aufgaben unterteilen kann.

Funktionsweise des Sprint Backlogs

Das Sprint Backlog wird während des Sprint Plannings erstellt. Das Scrum Team wählt die höchstpriorisierten Product Backlog Items (PBIs) aus, die es im kommenden Sprint bearbeiten wird (Pull-System). Die Menge der Arbeiten bestimmt das Team.
Zusätzlich zu den ausgewählten PBIs enthält das Sprint Backlog detaillierte Aufgaben (Tasks), die zur Umsetzung der PBIs notwendig sind. Diese Aufgaben werden vom Scrum Team erstellt und verfeinert. Ein Task allein liefert keinen Kundenwert und wird nicht im Product Backlog geführt. Tasks sind für das Team in der Umsetzung der PBIs notwendig.
Während des Sprints können Aufgaben hinzugefügt, entfernt oder angepasst werden, um das Sprintziel zu erreichen.
Das Sprint Backlog bietet Transparenz über die Arbeit, die im aktuellen Sprint geleistet wird. Es wird an einem für alle gut sichtbaren Ort gehalten, so dass alle Teammitglieder und Stakeholder den Fortschritt leicht nachverfolgen können.
Der Fortschritt wird fortlaufend aktualisiert, der Status Quo ist somit jederzeit für alle ersichtlich. Das Team nutzt das Sprint Backlog, um zu sehen, welche Aufgaben erledigt, welche noch offen, welche möglicherweise blockiert sind und wo sie von einander Unterstützung benötigen.
Das Sprint Backlog wird in der Regel nach dem Sprint Planning nicht mehr verändert.

Das Product Increment

Das Product Increment entspricht dem momentan angebotenen Produkt und zeigt zusätzlich das Ergebnis der Arbeit des Teams am Ende jedes Sprints. Es stellt sicher, dass das Team kontinuierlich wertvolle und funktionsfähige Produktversionen liefert. Die Definition of Done (DoD) ist für das Product Increment ein zentraler Aspekt.

Definition und Zweck des Product Increment
Das Product Increment ist die Summe aller abgeschlossenen Product Backlog Items (PBIs) am Ende eines Sprints, sowie der Wert aller vorherigen Inkremente.
Es stellt einen Schritt in Richtung des finalen Produkts dar und muss funktionsfähig und potenziell auslieferbar sein. Dies bedeutet, dass es die Definition of Done (DoD) erfüllen muss, um als abgeschlossen zu gelten.

Verantwortung für das Product Increment
Das Scrum Team ist verantwortlich für die Erstellung des Product Increments und steht für den Qualitätsstandard ein.

Funktionsweise des Product Increment

Die Definition of Done (DoD) beschreibt die Kriterien, die ein Increment neben den Akzeptanzkriterien erfüllen muss, um als „fertig“ betrachtet zu werden. Dies umfasst Aspekte wie Code-Qualität, Tests, Dokumentation und Integration.
Das Increment umfasst alle neuen Features, Verbesserungen und Bug-Fixes, die während des Sprints entwickelt wurden.
Jedes Increment muss vollständig integriert und getestet sein, um sicherzustellen, dass es in die bestehende Produktbasis aufgenommen werden kann, ohne bestehende Funktionalitäten zu beeinträchtigen.
Jedes Increment baut auf den vorherigen Inkrementen auf, was bedeutet, dass das Produkt kontinuierlich verbessert und erweitert wird.

Mehr zu den Scrum Verantwortlichkeiten

Scrum tEAM MEMBER

SCRUM MASTER

PRODUCT OWNER

Buche jetzt eines unserer Scrum Trainings

Häufige Fragen und Best practices zu den Scrum artefakten

Best Practices für das Product Backlog: Tipps & Tricks

Ein Product Backlog enthält ca. 50 bis 80 Product Backlog Items (PBI). Diese Beschränkung dient der Übersichtlichkeit und Durchführbarkeit.
Das Refinement wird bei den obersten Items sorgfältig gepflegt. Um Waste zu vermeiden, sind die untersten PBI’s nur wenig detailliert beschrieben. Sie könnten zu einem späteren Zeitpunkt hinfällig werden oder sich verändern.
Die PBIs innerhalb des Product Backlogs sind von oben nach unten priorisiert. Sie stehen in einer Rangreihenfolge, wobei jeder Rang nur einmal vergeben wird. Wären mehrere Items gleich priorisiert, würden die Entwickler die Priorisierung machen. Dieses Vorgehen entspräche nicht dem Scrum Framework und wäre falsch.

Best Practices für das Sprint Backlog: Tipps & Tricks

Das Product Backlog gehört dem Team und dient als Arbeitsfläche. Die Entwicklerinnen und Entwicklern ergänzen Tasks, die für die Stories/Items nötig sind.
Das Product Backlog zeigt zu jeder Zeit den Status Quo der Arbeiten. Es dient der hohen Transparenz und ermöglicht die Überprüfung (inspect) und Anpassung (adapt).
Zuoberst im Sprint Backlog steht die Kaizen-Massnahme, die das Scrum Team in der letzten Retrospective vereinbart hat.

Priorisieren, aber wie?

Für das Product Backlog müssen die Product Backlog Items in eine klare Reihenfolge gebracht werden. Welche Kriterien finden dabei Anwendung?

Der Aufwand für die Arbeiten und der Mehrwert für den Kunden werden einander gegenübergestellt. Während der Aufwand nur durch die Entwickler beurteilt werden kann, kennt im Team nur der Product Owner den Business Value für die Kunden.
Das Scrum-Muster Interrupt Buffer kann im Sprint Backlog angewendet werden, indem Kapazität im Sprint für unvorhergesehene und unvorhersehbare Arbeiten Kapazität reserviert wird. Nur der Product Owner kann entscheiden, ob Arbeiten in den Interrupt Buffer geschoben werden. Der Buffer darf 20% des Gesamtaufwandes nicht übersteigen. Mehr zum Interrupt Buffer