Der Scrum Guide 2020 definiert drei Scrum-Artefakte, und zu jedem gehört eine Verpflichtung: Das Product Backlog verpflichtet auf das Product Goal, das Sprint Backlog auf das Sprint Goal und das Increment auf die Definition of Done. Die Artefakte machen Arbeit und Wert transparent, und die Verpflichtungen geben jedem Artefakt einen klaren Zweck, an dem sich der Fortschritt messen lässt. Wenn du diese drei Paare verstanden hast, kannst du einen großen Teil der Artefakt-Fragen in den Prüfungen PSM I, PSPO I und CSM beantworten.
Was sind die drei Scrum-Artefakte?
Scrum-Artefakte repräsentieren Arbeit oder Wert. Sie sollen die Transparenz wichtiger Informationen maximieren, damit alle, die sie inspizieren, dieselbe Grundlage für Anpassungen haben. Das knüpft direkt an die drei Säulen von Scrum an: Transparenz, Inspektion und Anpassung. Ein Artefakt, das nicht transparent ist, führt zu schlechten Entscheidungen, denn du kannst nicht inspizieren, was du nicht siehst.
Die Ausgabe 2020 des Scrum Guide hat jedem Artefakt eine Verpflichtung hinzugefügt. Der Guide beschreibt diese Verpflichtungen so, dass sie Empirismus und die Scrum-Werte für das Scrum Team und seine Stakeholder stärken sollen.
Scrum-Artefakte und Verpflichtungen auf einen Blick
| Artefakt | Verpflichtung | Wer ist verantwortlich |
|---|---|---|
| Product Backlog | Product Goal | Product Owner (Product Backlog Management, einschließlich Entwicklung und Kommunikation des Product Goal) |
| Sprint Backlog | Sprint Goal | Developers (das Sprint Backlog ist ihr Plan, von ihnen und für sie) |
| Increment | Definition of Done | Die Developers halten sie ein; das Scrum Team erstellt sie, wenn die Organisation keine vorgibt |
Merke dir diese Tabelle für die Prüfung. Viele Fangfragen vertauschen schlicht den Verantwortlichen eines Artefakts oder ordnen einem Artefakt die falsche Verpflichtung zu.
Product Backlog und Product Goal
Das Product Backlog ist eine emergente, geordnete Liste dessen, was zur Verbesserung des Produkts nötig ist. Es ist die einzige Quelle für die Arbeit, die das Scrum Team übernimmt. Einträge weiter oben sind meist klarer und besser verfeinert, weil sie wahrscheinlich im nächsten Sprint Planning ausgewählt werden.
Product Backlog Refinement ist das Aufteilen von Einträgen und das Ergänzen von Details wie Beschreibung, Reihenfolge und Größe. Es ist eine fortlaufende Aktivität und kein Scrum-Event. Der Guide 2020 nennt dafür keinen festen Prozentwert; die alte Richtlinie „nicht mehr als 10 % der Kapazität der Developers“ wurde gestrichen.
Der Product Owner ist für das Product Backlog Management verantwortlich. Der Product Owner ist eine Person, kein Komitee. Er kann die Arbeit des Schreibens oder Ordnens von Einträgen an andere delegieren, bleibt aber verantwortlich.
Was ist das Product Goal und warum kam es 2020 dazu?
Das Product Goal beschreibt einen zukünftigen Zustand des Produkts und dient dem Scrum Team als Ziel, auf das es plant. Es ist das langfristige Ziel des Scrum Teams, und das Product Backlog entsteht, um das „Was“ zu definieren, das es erfüllt.
Vor 2020 hatte Scrum kein ausdrückliches Ziel auf Artefakt-Ebene oberhalb des Sprint Goal. Teams konnten Sprint für Sprint arbeiten, ohne eine gemeinsame Vorstellung davon, wohin sich das Produkt entwickelt. Das Product Goal schließt diese Lücke: Es verbindet jedes Sprint Goal mit einem größeren Zweck und gibt Stakeholdern etwas Konkretes, an dem sie den Fortschritt inspizieren können.
Zwei Prüfungsdetails sind wichtig. Erstens arbeitet das Scrum Team immer nur an einem Product Goal. Zweitens muss es ein Product Goal erfüllen (erreichen) oder verwerfen, bevor es das nächste angeht.
Sprint Backlog und Sprint Goal
Das Sprint Backlog besteht aus drei Teilen: dem Sprint Goal (warum), der Menge der für den Sprint ausgewählten Product Backlog Items (was) und einem umsetzbaren Plan zur Lieferung des Increments (wie). Sie entsprechen den drei Themen des Sprint Planning: Warum ist dieser Sprint wertvoll, was kann in diesem Sprint fertig (Done) werden und wie wird die gewählte Arbeit erledigt.
Das Sprint Backlog ist ein Plan von und für die Developers. Es ist ein gut sichtbares Echtzeitbild der Arbeit, die die Developers im Sprint erledigen wollen. Die Developers besitzen es und aktualisieren es während des gesamten Sprints, wenn sie mehr lernen.
Wie das Sprint Goal Flexibilität schafft
Das Sprint Goal ist das einzige Ziel des Sprints. Es wird im Sprint Planning erstellt und dem Sprint Backlog hinzugefügt. Obwohl es eine Verpflichtung der Developers ist, lässt es Flexibilität bei der genauen Arbeit, die zu seiner Erreichung nötig ist.
In der Praxis heißt das: Die ausgewählten Items und der Plan können sich im Sprint ändern, während das Ziel stabil bleibt. Stellt sich die Arbeit als anders als erwartet heraus, verhandeln die Developers gemeinsam mit dem Product Owner den Umfang des Sprint Backlog innerhalb des Sprints, ohne das Sprint Goal zu ändern. Im Daily Scrum inspizieren die Developers den Fortschritt in Richtung Sprint Goal und passen das Sprint Backlog bei Bedarf an.
Wenn das Sprint Goal selbst obsolet wird, kann nur der Product Owner den Sprint abbrechen.
Increment und Definition of Done
Ein Increment ist ein konkreter Schritt in Richtung Product Goal. Jedes Increment baut auf allen früheren Increments auf und wird gründlich verifiziert, damit alle Increments zusammenarbeiten. Um Wert zu liefern, muss das Increment nutzbar sein.
Was „Done“ bedeutet
Die Definition of Done (DoD) ist eine formale Beschreibung des Zustands des Increments, wenn es die für das Produkt erforderlichen Qualitätsmaßstäbe erfüllt. In dem Moment, in dem ein Product Backlog Item die Definition of Done erfüllt, entsteht ein Increment.
Die DoD schafft Transparenz, indem sie allen ein gemeinsames Verständnis davon gibt, welche Arbeit als Teil des Increments abgeschlossen wurde. Sie ist die Qualitätslatte, und die Developers sind dafür verantwortlich, Qualität sicherzustellen, indem sie sie einhalten.
Woher die Definition of Done kommt:
- Wenn die Organisation eine Definition of Done als Teil ihrer Standards hat, müssen alle Scrum Teams sie mindestens einhalten.
- Wenn nicht, muss das Scrum Team eine für das Produkt passende Definition of Done erstellen.
- Ein Team darf seine DoD strenger machen als den Standard der Organisation, aber nicht lockerer.
Was passiert mit unfertiger Arbeit?
Wenn ein Product Backlog Item die Definition of Done nicht erfüllt, kann es nicht ausgeliefert und nicht einmal im Sprint Review präsentiert werden. Stattdessen geht es zurück ins Product Backlog für spätere Überlegungen. Es gibt in Scrum kein „fast fertig“ oder „zu 90 % fertig“: Arbeit ist entweder Done oder sie ist nicht Teil des Increments.
Mehrere Increments pro Sprint
Ein verbreitetes Missverständnis ist, dass ein Sprint genau ein Increment am Ende erzeugt. Der Guide 2020 stellt klar, dass innerhalb eines Sprints mehrere Increments entstehen können. Das Sprint Review sollte nie als Gate für die Auslieferung von Wert betrachtet werden: Ein Increment darf schon vor Ende des Sprints an Stakeholder ausgeliefert werden. Die Summe der Increments wird im Sprint Review präsentiert.
Häufige Prüfungsfallen zu Scrum-Artefakten
Diese Punkte erwischen Kandidaten in Probeprüfungen und echten Prüfungen am häufigsten:
- Wem gehört das Sprint Backlog? Den Developers. Nicht dem Product Owner und nicht dem Scrum Master. Der Product Owner besitzt das Product Backlog.
- Kann sich das Sprint Backlog im Sprint ändern? Ja. Die Developers aktualisieren es, wenn sie mehr lernen, und der Umfang kann mit dem Product Owner geklärt und neu verhandelt werden. Nicht gefährdet werden dürfen das Sprint Goal und die Qualität.
- Darf das Team die DoD der Organisation absenken? Nein. Eine DoD der Organisation ist das Minimum. Das Team kann etwas hinzufügen.
- Ist ein Burndown-Chart ein Artefakt? Nein. Burndown-Charts, Velocity, Story Points und User Stories stehen nicht im Scrum Guide. Es sind ergänzende Praktiken.
- Gibt es ein Increment pro Sprint? Nicht unbedingt. Mehrere Increments können innerhalb eines einzigen Sprints entstehen und ausgeliefert werden.
- Darf unfertige Arbeit im Sprint Review gezeigt werden? Nein. Sie geht zurück ins Product Backlog.
- Wie viele Product Goals gleichzeitig? Eines. Es muss erfüllt oder verworfen werden, bevor das nächste kommt.
Am besten prüfst du, ob du diese Regeln wirklich beherrschst, indem du Fragen im Prüfungsstil unter Zeitdruck beantwortest. Probiere die kostenlose PSM-Probeprüfung (20 Fragen, 20 Minuten) oder, wenn du dich auf die Product-Owner-Prüfung vorbereitest, das Product-Owner-Zertifizierungstraining, in dem Fragen zu Product Goal und Product Backlog Management oft vorkommen.
FAQ
Was sind die 3 Artefakte in Scrum?
Das Product Backlog, das Sprint Backlog und das Increment. Im Scrum Guide 2020 hat jedes eine Verpflichtung: das Product Goal, das Sprint Goal bzw. die Definition of Done.
Wer erstellt die Definition of Done?
Wenn die Organisation eine Definition of Done hat, befolgen die Scrum Teams sie mindestens. Wenn nicht, erstellt das Scrum Team eine, die zum Produkt passt.
Kann sich das Sprint Backlog im Sprint ändern?
Ja. Die Developers besitzen das Sprint Backlog und aktualisieren es während des Sprints, wenn sie mehr lernen. Das Sprint Goal bleibt fest, und der Umfang kann mit dem Product Owner neu verhandelt werden.
Ist das Product Goal ein Artefakt?
Nein. Das Product Goal ist die Verpflichtung des Artefakts Product Backlog. Es ist das langfristige Ziel des Scrum Teams, und das Team arbeitet jeweils an einem.