In unserer Blog-Reihe zum Thema Scrum stellen wir nützliche Arbeitsansätze des Frameworks vor. Nach den Rollen und den Events geht es in diesem Beitrag darum, wie die Scrum Artefakte unseren Projektalltag bereichern und erleichtern können.

Scrum Artefakte

Artefakte sind formelle “Helferlein”, die den Wert bzw. die Aufgaben innerhalb eines Projektes sichtbar und somit transparent für alle Beteiligten machen. Wir setzen sie ein, um unsere Arbeit kontinuierlich zu überprüfen und bei Bedarf anzupassen.

Konkret geht es um die Bausteine

• Product Backlog
• Sprint Goal
• Sprint Backlog
• Definition of Done
• (Produkt-) Inkrement

sowie ergänzend (optional) dazu

• Product Vision
• Definition of Ready
• Impediment Backlog

Product Backlog

Alle bekannten Anforderungen an ein Produkt sind im Product Backlog gelistet. Der Product Backlog, für den der Product Owner verantwortlich ist, ist dynamisch, entwickelt sich im Laufe des Projektes stetig weiter und bildet somit dauerhaft alle Funktionalitäten, Fehlerbehebungen und Verbesserungen ab.

Als Faustregel gilt: Pro Produkt gibt es einen Product Backlog und einen Product Owner, aber ggf. mehrere (Scrum)Teams, die am selben Produkt arbeiten.

Sprint Goal

Das Sprint Goal umschreibt als “Mini-Vision" das Ziel eines Sprints, greift also einen relevanten Teilaspekt der Produkt Vision auf. Dies gibt dem Development Team Orientierung bei der Auswahl der zu bearbeitenden Aufgaben und hilft im Sprintverlauf, den Fokus zu wahren. So können auch potenzielle Hindernisse schnell erkannt und entsprechende Maßnahmen getroffen werden – immer in Absprache mit dem Product Owner.

In der Scrum-Theorie formuliert das Development Team dieses Ziel, in der Praxis ist es häufig so, dass der Product Owner einen Vorschlag macht, also seine Wünsche für das Inkrement äußert, und das Scrum Team dann gemeinsam definiert. Dies erfolgt im Rahmen des Sprint Plannings.

Sprint Backlog

Auch der Sprint Backlog entsteht während des Plannings und enthält alle Product-Backlog-Einträge, die im nächsten Sprint bearbeitet werden sollen. Die Einträge werden vom Development Team ausgewählt. Damit prognostiziert es das mögliche Arbeitspensum und welche Funktionalitäten umgesetzt werden können, um das Sprint Goal zu erreichen. Es wird für jeden Sprint neu erstellt.

Ebenso wie beim Product Backlog ist der Inhalt des Sprint Backlogs dynamisch – hier im Verlauf eines Sprints. Aufgaben fallen weg oder kommen hinzu. Der Sprint Backlog ermöglicht zu jedem Zeitpunkt einen Echtzeit-Einblick in den Arbeitsverlauf (Fortschritt), unterstützen kann hierbei die grafische Aufbereitung als Burn-Down-Chart.

Definition of Done (DOD)

Für ein gemeinsames Verständnis wann bzw. ob ein Teilstück des Produkts fertig gestellt (”Done”) ist, sorgt die Definition of Done (DOD). Sie wird initial vom gesamten Scrum Team definiert und dokumentiert damit die Kriterien, die zum Erfüllen des eigenen Qualitätsanspruchs beachtet werden sollen. Im Laufe einer Produktentwicklung kann es auch notwendig werden, die DOD anzupassen – man hat vielleicht bemerkt, dass Teilaspekte initial nicht bedacht wurden. Im Rahmen der Retrospektive kann das Team erneut am Thema arbeiten und die DOD kontinuierlich verfeinern. Je eingespielter das Team, umso präziser die DOD.

(Produkt-) Inkrement

Als Inkrement bezeichnet man das Resultat aus allen Sprint-Backlog-Einträgen, also ein in sich lauffähiges Teilstück des Produktes. Es muss im Sinne der DOD “Done” sein und damit einen Zustand abbilden, der ab sofort ausgeliefert werden könnte.

Optionale Artefakte

Die Product Vision dient besonders dem Team als Orientierung und definiert, was mit dem zu erstellenden Produkt erreicht werden soll. Diese gemeinsame Ausrichtung auf ein Ziel kann außerdem ein motivierender Faktor im Scrum Team sein.  

Die Definition of Ready (DOR) kann dem Product Owner helfen, wenn er einen Vorschlag für das Sprint Goal ausarbeitet. Sie beschreibt jene Aufgaben im Product Backlog, die detailliert genug sind, um vom Team in einem Sprint abgeschlossen zu werden. Die Aufgaben haben dann einen gewissen Reifegrad, der häufig durch das Refinement erreicht wird. Ein Beispiel für eine Aufgabe, die „Ready“ ist, wäre zum Beispiel:

• alle Akzeptanzkriterien sind definiert
• der Aufwand ist geschätzt
• die Aufgabe ist detailliert genug für das Development Team

Die DOR ist optional, weil ein Scrum Team auch ohne Aufgaben, die „Ready“ sind, in ein Sprint Planning starten kann.

Ein weiteres optionales Artefakt ist der Impediment Backlog, quasi die „Hindernis-Liste“. Da der Scrum Master derjenige ist, der das Team bei Hindernissen unterstützt und diese aus dem Weg räumt, ist es sein Artefakt. Er allein verwaltet es, das Scrum Team kann ihm bei der Identifizierung von Hindernissen helfen, die die effiziente Arbeit des Development Teams stören. Im Impediment Backlog werden diese erfasst. Sie haben gemeinsam, dass sie nicht vom Development Team selbst gelöst werden können, sondern Hilfe z. B. von der Organisation voraussetzen. Durch die Veröffentlichung des Impediment Backlogs wird Transparenz geschaffen. Idealerweise befähigt der Scrum Master das Development Team, möglichst viele Hindernisse selbstorganisiert zu lösen, damit im Impediment Backlog nur wenige davon liegen.

Pragmatisch, kreativ, gerne analog – Hauptsache transparent

Wie eingangs beschrieben, handelt es sich bei den Artefakten um formelle Elemente, die der Dokumentation dienen. Bleibt die Frage: Wie machen wir die Informationen für alle Beteiligten sichtbar und jederzeit zugänglich?

Es gibt genügend Software-Lösungen am Markt, die einem die Dokumentation out of the box, teilweise automatisiert, ermöglichen (z. B. das Burn-Down-Chart in Gitlab oder allen etablierten Ticket-Systemen). Man sollte dieses Lösungs-Spektrum aber für jedes Projekt individuell beleuchten, denn am Ende ist es nur dann erfolgreich, wenn Transparenz für alle Beteiligten herrscht – und das möglichst barrierearm.

Für die Arbeit an einer unserer derzeitigen Produkt-Entwicklungen, TOBI.SOCIAL, haben wir uns für ein haptisches, analoges Scrum Board auf einer Stellwand entschieden. Wir haben erkannt, dass wir so unsere Stakeholder für dieses Projekt sehr gut ansprechen können.

Dort finden alle Artefakte, die wir im Projekt nutzen, ihren Platz und werden regelmäßig aktualisiert. Im Projektverlauf haben sich zusätzlich noch einige andere Infos als nützlich erwiesen und damit ihren festen Platz auf unserem Board gefunden. Zum Beispiel haben wir eine “Stakeholders Corner” etabliert, der klassische Kummerkasten, wie man ihn vielleicht noch aus Schulzeiten kennt.

Unser Tipp: einfach ausprobieren!

(Fotos: Unsplash)