Die drei Scrum Artefakte und ihre Commitments
Jedes Artefakt beantwortet eine andere Frage, und jedes Commitment macht die Antwort überprüfbar.
Artefakt 1
Product Backlog
Geordnete, jederzeit veränderliche Liste dessen, was für das Produkt benötigt wird. Sie ist die einzige Quelle für Arbeit, die das Team übernimmt. Commitment: das Produkt-Ziel.
Artefakt 2
Sprint Backlog
Plan der Developer für diesen Sprint: das Warum, die ausgewählten Einträge und der Weg zur Lieferung. Commitment: das Sprint-Ziel.
Artefakt 3
Increment
Konkreter Schritt zum Produkt-Ziel, der nutzbar ist. Commitment: die Definition of Done als gemeinsamer Qualitätsmaßstab.
Product Backlog und Produkt-Ziel
Das Product Backlog enthält alles, was zur Verbesserung des Produkts beiträgt. Es ist geordnet, nicht sortiert nach Eingang, und es ist nie abgeschlossen. Verfeinert wird es fortlaufend im Refinement: grobe Einträge werden zerlegt, präzisiert und mit gemeinsamem Verständnis versehen. Das Regelwerk gibt für das Refinement bewusst keine feste Dauer und kein festes Format vor.
Das Produkt-Ziel beschreibt einen künftigen Zustand des Produkts und dient dem Team als langfristige Orientierung. Es ist Bestandteil des Product Backlogs; der übrige Inhalt des Backlogs beantwortet die Frage, was zur Erfüllung dieses Ziels nötig ist. Ein Team verfolgt ein Produkt-Ziel, bis es erreicht oder bewusst aufgegeben wird.
Für die Größe der Einträge sind die Developer verantwortlich, nicht der Product Owner. Der Product Owner kann sie dabei unterstützen, indem er den fachlichen Hintergrund erläutert. Einträge, die innerhalb eines Sprints fertiggestellt werden können, gelten als auswählbar für das Sprint Planning.
Sprint Backlog und Sprint-Ziel
Das Sprint Backlog besteht aus drei Bestandteilen: dem Sprint-Ziel als Begründung, den ausgewählten Product-Backlog-Einträgen als Inhalt und einem umsetzbaren Plan für die Lieferung des Increments. Es ist ein Plan von den Developern für die Developer, keine Berichtsvorlage für das Management.
Das Sprint-Ziel entsteht im Sprint Planning und muss vor dessen Ende feststehen. Es ist die einzige Zielsetzung des Sprints und schafft Fokus, weil es das Team auf ein gemeinsames Ergebnis ausrichtet statt auf eine Summe einzelner Aufgaben. Stellt sich während des Sprints heraus, dass der Aufwand anders liegt als erwartet, stimmen die Developer den Umfang mit dem Product Owner neu ab. Das Sprint-Ziel selbst bleibt dabei unangetastet.
Das Sprint Backlog wird während des gesamten Sprints fortlaufend aktualisiert. Es muss detailliert genug sein, damit der Fortschritt im Daily Scrum tatsächlich beurteilt werden kann.
Increment und Definition of Done
Ein Increment ist ein überprüfbarer Schritt in Richtung Produkt-Ziel. Damit es Wert stiftet, muss es nutzbar sein. Innerhalb eines Sprints können mehrere Increments entstehen; ihre Summe wird im Sprint Review vorgestellt. Eine Auslieferung an Stakeholder ist auch vor dem Sprintende möglich, das Review ist keine Freigabehürde.
Der Punkt, an dem die meisten Teams ungenau werden
Arbeit gilt erst dann als Teil des Increments, wenn sie die Definition of Done erfüllt. Erfüllt ein Eintrag sie nicht, wird er nicht released und nicht im Sprint Review präsentiert, sondern kehrt ins Product Backlog zurück. Ein Zwischenstand mit dem Vermerk „fast fertig“ ist kein Increment.
Die Definition of Done beschreibt den Zustand, in dem das Increment die geforderten Qualitätsstandards erreicht. Sie schafft Transparenz, weil alle Beteiligten dasselbe Verständnis davon haben, was abgeschlossen bedeutet. Gibt die Organisation bereits eine Definition of Done vor, ist sie der Mindeststandard, den das Team nicht unterschreiten darf. Gibt es keine, erstellt das Scrum Team sie selbst. Arbeiten mehrere Teams am selben Produkt, müssen sie sich auf eine gemeinsame Definition of Done einigen.
