Scrum - Die 3 Artefakte

Artefakte sind Dokumente, die man "greifen" kann. Dazu zählen:

1. Product Backlog
2. Sprint Backlog
3. Product Increment

Das Geschäftsanforderungsdokument, ein detailliertes Designdokument, eine Teststrategie und ein Testplan, Testfälle, Benutzerhandbücher, Implementierungspläne, Kommunikationspläne, ein Risikoregister und vielleicht noch viel mehr. In Scrum ist keines dieser Artefakte erforderlich. Das heißt aber nicht, dass keines von ihnen in Ihrem organisatorischen Kontext noch benötigt wird. Vielmehr bedeutet es, dass in Scrum keines dieser Artefakte durch die Regeln von Scrum gefordert wird.

Es gibt auch die Definition of Done, die in Scrum nicht als eines der drei Scrum-Artefakte aufgeführt ist. Die Definition of Done ist die Übereinkunft des Scrum-Teams darüber, was es bedeutet, wenn die Developer behauptet, dass etwas, an dem es gearbeitet hat, fertig ist. Sinnvoll ist es die Definition of Done aufzuschreiben und für das gesamte Scrum-Team und jeden anderen, der ein Interesse daran hat zu wissen, sichtbar zu machen.

#Product Backlog

Priorisierte Liste mit Features die entstehen soll, die mit den Kunden abgestimmt wurden. Streng priorisiert, es gibt nicht zwei gleiche Prioritäten. Der Product Owner muss die Liste ständig pflegen (grooming) / aktualisieren und auch erweitern, falls neue Features hinzukommen.

Je Anforderung:

• Priorität
• Kurze Beschreibung (siehe User Stories)
• Akzeptanzkriterien
• grobe Schätzung des Umfangs durch das Team (Story Points)

Je weiter unten in der Liste, des unwichtiger, d.h. der Business Value ist gering oder unklar.

product-backlog.jpg

Das Product Backlog ist eine geordnete Liste von allem, von dem bekannt ist, was für das Produkt benötigt wird. Es ist eine einzige Quelle von Anforderungen für alle Änderungen, die an dem Produkt vorgenommen werden sollen. Man kann sich das Product Backlog leicht als Ersatz für das Dokument mit den Geschäftsanforderungen vorstellen, das oft mit traditionellen Wasserfallprojekten verbunden ist. Anstelle eines dicken Notizbuchs, das mit kleinen, komplizierten Details darüber gefüllt ist, was für ein neues System benötigt wird, ist es für die meisten Menschen leicht zu verstehen, dass ein Product Backlog kurz geschriebene Anforderungen für ein Produkt enthält.

Diese Anforderungen werden oft als Funktions- oder Feature-Anforderungen ausgedrückt, die eine Aufgabe oder ein Ziel verfolgen. Der Product Owner kann diese epischen Anforderungen anschließend in kleinere Anforderungen aufteilen, oft im User-Story-Format, die das Entwicklungsteam innerhalb eines einzigen Sprints fertigstellen kann.

Wie sollte ein Scrum-Team mit Softwarefehlern umgehen, die von Benutzern an den Helpdesk Ihres Unternehmens gemeldet werden? Oder wie sollte ein Scrum-Team mit einem Fehler umgehen, den jemand beim Produktinkrement während des aktuellen Sprints findet, der aber nicht innerhalb des aktuellen Sprints behoben werden kann? Was sollte ein Scrum-Team tun? Die einfache Antwort ist, dass der Product Owner einen solchen Defekt oder Fehler in das Product Backlog aufnehmen sollte, genau wie alle neuen Funktions- und Feature-Anfragen, die im Product Backlog dargestellt werden. Es gibt nur einen Ort, an dem die zukünftigen Änderungen am Produktinkrement verwaltet werden können, und dieser eine Ort ist das Product Backlog.

Der Scrum Guide sagt nicht, wie Fehlerdefekte im Product Backlog von neuen Feature Requests unterschieden werden sollten, oder ob sie überhaupt anders unterschieden werden sollten. In Scrum kommt es darauf an, dass Fehler oder Defekte in das transparente und sichtbare Product Backlog von Scrum aufgenommen werden, so dass jeder sehen kann, welche Probleme im Product Increment vorhanden sind und wie wichtig die Behebung dieser Probleme im Verhältnis zum Hinzufügen neuer oder verbesserter Funktionen zum Product Increment ist, je nachdem, wie der Product Owner die Product Backlog-Elemente angeordnet hat.

Das Product Backlog ist ein lebendiges Artefakt. Das Product Backlog wird sich weiter verändern und entwickeln, wenn das Scrum Team Arbeitsanforderungen abschließt, die im Product Backlog erscheinen. Der Product Owner kann Elemente im Product Backlog während des Projekts neu anordnen, und der Product Owner kann Elemente zum Product Backlog hinzufügen und entfernen, wenn sich die Marktbedingungen ändern, er das Produkt besser versteht, sich die Technologie ändert und andere Umweltfaktoren eintreten. Dies sind alles Gründe, warum der Product Owner die Reihenfolge der Product Backlog-Elemente verschieben kann. Selbst wenn das Projekt abgeschlossen ist und das Scrum Team alle Punkte im Product Backlog erledigt hat, lebt das Product Backlog weiter und es wird erwartet, dass der Product Owner nach dem formellen Ende des Projekts weiterhin eine Mission oder ein Ziel verfolgt, indem er neue Feature Requests zum Product Backlog hinzufügt, die eines Tages in einem anderen zukünftigen Projekt verwendet werden können.

#Verpflichtung: Product Goal

Das Produktziel beschreibt einen zukünftigen Zustand des Produkts, der dem Scrum-Team als Zielvorgabe für die Planung dienen kann. Das Product Goal befindet sich im Product Backlog. Der Rest des Product Backlogs entsteht, um zu definieren, was das Product Goal erfüllen wird.

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
Scrum Guide

Das Produktziel ist das langfristige Ziel. Das Scrum Team muss ein Ziel erfüllen (oder aufgeben), bevor das nächste in Angriff nehmen kann.

#Sprint Backlog

Teilmenge des Product Backlog, was bis zum nächsten Sprint erstellt werden soll. Wird vom Team festgelegt. Es gibt zwei Themen, die im Sprint Planning behandelt werden.

1. Was kann in diesem Sprint getan werden?
2. Wie wird die ausgewählte Arbeit erledigt?

Das Sprint Planning-Event sollte zumindest eine Reihe von Aufgaben auf hohem Niveau erstellt haben, die das Entwicklungsteam in den nächsten Tagen erledigen kann, um die ausgewählten Product Backlog-Elemente in einen "Done"-Status zu bringen. Das Sprint Backlog enthält Elemente aus dem Product Backlog, die die Frage beantworten, was wir in diesem Sprint tun werden.

Das Sprint Backlog enthält aber auch einen Plan für die Durchführung dieser Arbeit. Die Aufgaben oder Aktivitäten, die das Entwicklungsteam durchführen wird, beantworten die Frage nach dem Wie: Wie werden wir diese Arbeit erledigen? Zusammengenommen ist das Sprint Backlog ein sichtbarer Plan, der transparent zeigt, was das Scrum Team in seinem nächsten Sprint tun wird und wie es diese Arbeit erledigen wird. Das Sprint Backlog sollte sich während des Sprints täglich ändern, und der Fortschritt sollte jeden Tag sichtbar sein. Das Sprint Backlog wird sich mit der Zeit entwickeln. Das Entwicklungsteam wird neue Aufgaben hinzufügen, während es während des Sprints zusammenarbeitet. Vorbei sind die Zeiten, in denen jemand in einem Projektstatus-Meeting berichtete: "Ich bin zu 75 % mit der Codierung dieser Webkomponente fertig. Stattdessen zerlegt das Entwicklungsteam seine Arbeit in Aufgaben, die innerhalb eines Tages oder weniger erledigt werden können. Sie beginnen mit dieser Zerlegung während der Sprint-Planung, werden aber während des gesamten Sprints jeden Tag ein kleineres Maß an Planung durchführen. Angenommen, ich gehöre zu Ihrem Entwicklungsteam und ziehe die Aufgabe Datenbankschema erstellen. Bis morgen sollten Sie erwarten, dass ich das Datenbankschema fertiggestellt habe. Wenn das keine vernünftige Erwartung ist, wenn das Erstellen eines Datenbankschemas länger als einen Tag dauert, dann werde ich entweder ein anderes Mitglied des Entwicklungsteams um Hilfe bitten, damit wir beide das Datenbankschema an einem Tag fertigstellen können, oder ich werde einen Weg finden, die Aufgabe aufzuteilen. Was immer ich also heute aus dem Sprint Backlog ziehe, möchte ich morgen als erledigt melden, es sei denn, ich stoße auf eine Straßensperre oder es tritt etwas Unerwartetes ein. Das ist es, was der Scrum Guide meint, wenn er sagt:

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum.
Scrum Guide

#Verpflichtung: Sprint Goal

Das Produktziel beschreibt einen zukünftigen Zustand des Produkts, der dem Scrum-Team als Zielvorgabe für die Planung dienen kann. Das Product Goal befindet sich im Product Backlog. Der Rest des Product Backlogs entsteht, um zu definieren, was das Product Goal erfüllen wird.

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
Scrum Guide

Das Produktziel ist das langfristige Ziel. Das Scrum Team muss ein Ziel erfüllen (oder aufgeben), bevor das nächste in Angriff nehmen kann.

#Product Increment

Das letzte Scrum-Artefakt ist das Produktinkrement. Dieses Artefakt kann für ein Produkt noch nicht existieren, weil es für ein sehr großes und komplexes Software-Projekt, das ein oder mehrere Scrum-Teams in vielen Sprints entwickelt und ausgeliefert sein wird. Einfach ausgedrückt, ist das Produktinkrement:

The sum of all the Product Backlog items completed during a sprint and the value of the increments of all previous sprints.
Scrum Guide

Am Ende eines Sprints sollte ein potenziell veröffentlichungsfähiges Inkrement des Produkts erstellt sein. Das bedeutet, dass das Produktinkrement, so gut entworfen, codiert, getestet und dokumentiert ist, dass der Product Owner das neue Inkrement in die Produktumgebung einführen kann. Wenn er zögert, dies zu tun, weil das Inkrement nicht vollständig getestet wurde, dann hat das Inkrement nicht den Grad der Vollständigkeit erreicht, den Scrum am Ende eines Sprints erwartet.

#Verpflichtung: Definition of Done

The definition of "Done" is used to assess when work is complete on the product Increment
Scrum Guide

Was bedeutet es, zu sagen, dass etwas erledigt ist? Als Softwareentwickler oder Analyst weiß man, dass "fertig" ein schwer fassbarer Begriff ist. In Scrum ist es sehr wichtig, dass sich alle auf eine einzige Definition von "fertig" einigen und diese kennen. Der Scrum-Leitfaden besagt, dass, wenn eine Entwicklungsorganisation bereits über eine Reihe von Konventionen, Standards oder Richtlinien verfügt, dies die Mindestdefinition dafür ist, was "done" bedeutet. Wenn es keine solchen Standards oder Richtlinien gibt, dann muss ein Scrum Team eine Definition dafür entwickeln, was "Done" bedeutet.

Ein Beispiel für die Definition von "Done" im Scrum-Team könnte Folgendes sein:

• Der gesamte neue Code wird entweder von Kollegen begutachtet oder von im Pair Programming-Verfahren programmiert.
• Für den neuen Code werden automatisierte Unit-Testfälle geschrieben.
• Nach der Zusammenführung muss der gesamte neue Code alle automatisierten Testfälle des Systems erfolgreich durchlaufen. Der PO hat die in der PBI aufgeführten Arbeiten persönlich überprüft und genehmigt.

Die Definition of Done ist kein Scrum-Artefakt. Die Entwicklungsorganisation (oder das Developer Team) ist für die Erstellung der Definition of Done verantwortlich. Aber es ist wichtig, dass das gesamte Scrum-Team diese Definition versteht. Da der Product Owner nicht weiß, ob z.B. der Code peer-reviewed wurde, braucht er die Definition of Done nicht zu genehmigen. Aber die Person sollte verstehen, wie diese Definition die Produktqualität aufrechterhält. Wenn in der mehrere Scrum-Teams gemeinsam an demselben Produkt gearbeitet wird, müssen all diese Scrum-Teams dieselbe Definition of Done verwenden. Dies trägt dazu bei, die Komplexität zu verringern, und macht es einfacher, die Produktqualität zu steuern, wenn alle Teams mit demselben Verständnis von Fertigstellung arbeiten.