Scrum Artefakte
Inhaltsverzeichnis: Definition – Product Backlog – Sprint Backlog – Increment – Commitment – Download – Hinweise
Wissen kompakt: Es gibt drei Scrum Artefakte: Product Backlog, Sprint Backlog und Increment. Sie repräsentieren Aufgaben oder Anforderungen und deren Realisierung.
Scrum Artefakte – der Inhalt und Wert der Arbeit
Der Scrum Guide definiert mit dem Product Backlog, dem Sprint Backlog und dem Increment drei Scrum Artefakte.
Der Begriff Backlog bedeutet „an accumulation of something, especially uncompleted work or matters that need to be dealt with“.¹ Ein Backlog ist also eine Sammlung von Dingen, insbesondere unvollständiger Arbeit oder Angelegenheiten, die erledigt werden müssen. Oder einfach ausgedrückt: Es ist eine Liste von Aufgaben bzw. Anforderungen, die abgearbeitet bzw. realisiert werden sollen.
Und das Increment ist das Ergebnis eines Sprints, das die im Sprint realisierten Aufgaben beinhaltet.
Product Backlog
Ein Product Backlog beinhaltet Elemente, mit denen ein vom Product Owner definiertes Product Goal – das Produktziel – erreicht werden. Das Product Goal sorgt also dafür, dass „lediglich“ Items festgehalten werden, die auf das Ziel der Entwicklung einzahlen.
Verantwortlich für das Product Backlog als auch das Product Goal ist der Product Owner. Im Zuge der kontinuierlichen Verfeinerung und Priorisierung der Items, nutzt er die Meinungen von Stakeholdern und die Expertise der Entwickler (wobei auch diese Backlog Items erfassen dürfen). Er kommuniziert die Product Backlog Items, sorgt für Transparenz und Verständnis und geht mit einer Vorauswahl von Items – auch bekannt als Selected Backlog – in das Sprint Planning.
Interessanterweise spricht der Scrum Guide² immer nur von Product Backlog Items, ohne diese genauer zu benennen. User Storys, Epics, Features, Anforderungen etc. werden nicht explizit erwähnt. In der Praxis sind vor allem das Backlog Refinement³ und damit die wiederholte Priorisierung der Items, da die Inhalte sehr dynamisch sind; es kommen regelmäßig neue Inhalte hinzu und die Stakeholder ändern im Laufe einer Entwicklung ihre Meinung, was direkte Auswirkung auf die Priorisierung haben kann.
Sprint Backlog – der Plan für den aktuellen Sprint
Das Sprint Backlog ist der Plan für den aktuellen Sprint. Er wird im Sprint Planning vereinbart und beinhaltet alle Product Backlog Items, die durch die Entwickler für den aktuellen Sprint ausgewählt und im Sprint umgesetzt werden. Zusätzlich beinhaltet das Sprint Backlog das Sprint-Ziel, auf das sich die Entwickler gemeinsam committen und die Tasks bzw. Aufgaben, die nötig sind, um die Items zu realisieren und das Ziel zu erreichen.
Nachdem der Product Owner das „Warum“ des Sprints und die aus seiner Sicht wichtigsten Items erläutert hat, entscheiden die Entwickler, „was“ „wie“ im Sprint umgesetzt wird. Sie tragen damit die Verantwortung für den Sprint, das Sprint-Ziel und das Sprint Backlog. Idealerweise selektieren sie die Items mit den höchsten Prioritäten, die der Product Owner im Zuge des Backlog Refinements gemeinsam mit ihnen und in Vertretung der wichtigsten Stakeholder festgelegt hat. Die Aufgaben zur Realisierung der einzelnen Items sollten dabei nicht mehr als einen Tag in Anspruch nehmen, so dass jeden Tag Aufgaben abgeschlossen werden können. Der Fortschritt innerhalb des Sprints lässt sich bspw. mit Taskboards oder Burn-Down-Charts visualisieren.
Increment – das Ergebnis aller durchlaufenen Sprints
Ein Product Increment – auf deutsch ein Produkt-Inkrement oder einfach Inkrement – umfasst alle während eines Sprints abgeschlossenen Backlog Items und beinhaltet additiv die Inkremente aller vorherigen Sprints. Am Ende eines Sprints muss das neue Inkrement „Done“ sein, d.h. es muss sich in einem brauchbaren Zustand befinden und der Definition of Done entsprechen. Darüber hinaus muss das Inkrement „potenziell lieferfähig“ sein, d.h. es muss funktionieren, es muss getestet sein, es muss sich in Betrieb nehmen lassen, es sollte dokumentiert sein und den Anwendern einen Mehrwert bieten. Auch mehrere Inkremente pro Sprint sind möglich.
In der Praxis wird nicht jedes fertige Inkrement den Kunden zur Verfügung gestellt, da dies viele Kunden-Organisationen überfordern könnte. Bei einer App, die sich automatisch im Hintergrund auf einem Handy aktualisiert, ist eine Lieferung pro Monat durchaus denkbar, bei einer Anwendung, die unternehmensweit mit mehreren 1000 Anwendern betrieben wird, würde das ggf. zu viel Aufwand erzeugen. Hier sind Marketing und Vertrieb gefordert, gemeinsam mit dem Product Owner eine sinnvolle Release-Strategie zu definieren.
Scrum Artefakte und Commitments
Der aktuelle Scrum Guide betont im Zuge der Artefakte die Bedeutung der Commitments. Als Selbstverpflichtung entspricht das Commitment einem der Scrum Werte. Konkret heruntergebrochen auf die einzelnen Scrum Artefakte ergeben sich drei direkte Zuordnungen:
- Das Produktziel ist das Commitment für das Product Backlog.
- Das Sprint-Ziel ist das Commitment für das Sprint Backlog.
- Und die Definition of Done ist das Commitment für das Increment.
Diese Commitments dienen dazu, Empirie und die Scrum‐Werte für das Scrum Team und seine Stakeholder zu verstärken. Das Produktziel entspricht dem langfristigen Entwicklungsziel des Teams, das es durch seine tägliche Arbeit erreichen soll. Das Sprint-Ziel ist die einzige Zielsetzung für einen konkreten Sprint. Und die Definition of Done ist eine formale Beschreibung, die Qualitätsmerkmale für ein Increment festhält.
Wie kann es gelingen, dauerhaft eine sinnvolle Menge von Backlog Items in das Sprint Backlog einzuplanen, insbesondere wenn die Planung von Aufwänden in der Praxis immer wieder schwierig ist?
Hinweise:
Haben Sie Lust auf einen neuen Lieblings-Newsletter?
Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.
[1] Was ist ein Backlog und welche Arten gibt es?
[2] siehe Scrum Guide
[3] Wie funktioniert ein Backlog Refinement?
In manchen Publikationen ist zu lesen, dass die Scrum Artefakte Prozessdokumente darstellen. Da Scrum ein Framework und kein Prozess ist und es sich bei den Artefakten nicht um Dokumente handeln muss (ein Inkrement bspw. ist eher ein Stück Software als ein Dokument), darf man dies auch anders beurteilen.
Hier finden Sie einen Podcast über die oft missverstandene inkrementelle Entwicklung in Scrum.
Hier finden Sie ergänzende Informationen aus dem t2informatik Blog: