16Artefakte

Scrum kennt nur drei Artefakte: Das Product Backlog, das Sprint Backlog und das Inkre-ment. Im Folgenden werden diese Elemente nicht im Detail beschrieben. Sie werden auchnicht lernen, wie Sie zu diesen Artefakten gelangen können.Was Sie aber lernen ist, woraufSie besonders bei diesen Dingen achten müssen, um erfolgreich sein zu können.

16.1 Produktinkrement

Scrum verlangt von Ihrem Entwicklungsteam, dass es am Ende jedes Sprints ein „ferti-ges“ Produktinkrement ausliefert. „Fertig“ bedeutet dabei, dass Sie das Ergebnis mit wenigoder keinem Aufwand an den Kunden ausliefern könnten. Es reicht also nicht aus, dasProdukt an die Qualitätssicherung zu liefern oder an ein anderes Team zu übergeben. EinProduktinkrement nach Scrum muss immer „potentiell auslieferbar“ sein, es dürfen al-so keinerlei Restarbeiten anstehen. Bei der Einführung von Scrum liegt hier eine häufigeFehlerquelle, da nachWasserfallAbteilungen oder Teams aus Spezialistenmit gleicher Spe-zialisierung bestehen. Mit Scrum benötigen Sie aber interdisziplinäre Teams, die aus Spe-zialisten verschiedener Fachrichtungen bestehen. Wenn Sie es zulassen, dass „Testteams“oder „Konzeptteams“ auch weiterhin existieren, so werden die Scrum-Teams niemals dievolle Verantwortung für ihr Handeln übernehmen, nur in eingeschränkten Bahnen überihre Arbeit nachdenken und niemals ihre volle Produktivität entfalten. Sorgen Sie dafür,dass jeden (!) Sprint ein fertiges Produkt erstellt wird.

16.2 Product Backlog

Das Product Backlog enthält die Summe aller Anforderungen, die das Team umsetzen soll.Scrum schreibt nicht vor, in welcher Form (z. B. User Stories) die einzelnen Elemente desProduct Backlogs (Product Backlog Items) formuliert werdenmüssen. Im Endeffekt ist das

177D. Maximini, Scrum - Einführung in der Unternehmenspraxis,DOI 10.1007/978-3-642-34823-5_16,© Springer-Verlag Berlin Heidelberg 2013

178 16 Artefakte

auch zweitrangig:Wichtig ist, dass der ProductOwner es schafft, seinemEntwicklungsteamtransparent zu machen, was er von ihm will. Dabei ist das Product Backlog aber mehr eineErinnerung als eine Spezifikation. Wichtiger noch: Das Product Backlog darf niemals miteinem Lastenheft verwechselt werden. Ein Solches erfordert ein hohes Maß an Präzision,während in einem Scrumprojekt die Präzision erst durch die Kommunikation (verbal undpersönlich) zwischen ProductOwner undEntwicklungsteamentsteht. Versuchen Sie nicht,jedeAnforderung perfekt zu formulieren. Streben Sie danach, dass alleAnforderungen „gutgenug“ formuliert sind. Das bedeutet, dass Product Owner und Entwicklungsteam damitarbeiten können. Dieses „gut genug“ kann sich auch mit der Zeit entwickeln. ÜberprüfenSie es regelmäßig in Ihren Retrospektiven. Achten Sie beim Product Backlog außerdemdarauf, dass der Product Owner es kennt, pflegt und dafür sorgt, dass die Elemente deraktuellen Releases immer durch das Entwicklungsteam geschätzt sind. Nur so können Siemittel- und langfristig planen.

16.3 Sprint Backlog

Das Sprint Backlog besteht aus den für einen Sprint vom Team angenommenen ProductBacklog Elementen sowie den Tasks1, die für deren Erfüllung notwendig sind. Es entstehtwährend des Sprint Plannings und gehört ausschließlich dem Entwicklungsteam. Perso-nen außerhalb des Scrum-Teams haben nichts am Sprint Backlog verloren. Im Zweifel –spätestens, wenn jemand außerhalb des Scrum-Teams anfängt mit dem Sprint Backlogzu argumentieren – sollten Außenstehende vom Sprint Backlog ausgeschlossen werden.Das Wichtige am Sprint Backlog ist, dass es ein lebendes Artefakt ist. Es muss sich täglichverändern, um den aktuellen Stand der Arbeiten zu reflektieren. Verändert es sich nicht,sollten Sie ergründen, warum. Häufig ist der Fehler, dass dem Entwicklungsteam nicht er-klärt wurde, wozu das Sprint Backlog gut ist – und es in der Folge nur für „den ScrumMaster“ erstellt wird. An der Qualität und Aktualität des Sprint Backlogs können Sie inhohem Maße ablesen, wie selbstorganisiert Ihr Team arbeitet. Was vielen auch nicht klarist: Die Informationen, die durch das Sprint Backlog transparent werden, sind erst einmalwertneutral. Sie spiegeln die Realität wider. Ob geringer Fortschritt gut oder schlecht ist,hängt von vielen Faktoren ab. Wichtig ist aber, dass dies erst einmal transparent wird, da-mit die Umstände analysiert werden können. Das ist die Aufgabe des Sprint Backlogs. Esist nicht Aufgabe des Sprint Backlogs, als Druckmittel zu dienen. Achten Sie sehr genau aufsich selbst, ob Sie solche Impulse an sich erkennen.

1 Es gibt auchTeams, die ohne Tasks arbeiten.Manchehaben schon die Anforderungen so kleinteilig,dass sie keine Tasks benötigen. Andere Teams benutzen andere Werkzeuge der Arbeitsaufteilung alsTasks. Trotzdem: Wenn Sie neu beginnen, halten Sie sich an Tasks – diese sind bewährt und einfach.

16.4 Definition of Done 179

16.4 Definition of Done

Die Definition of Done (DoD) ist eine bindende Vereinbarung zwischen Entwicklungs-team und Product Owner. In ihr wird genau festgehalten, welche Maßnahmen für jedeumgesetzte Anforderung erfüllt sein müssen, damit diese von allen als fertig (done) ange-sehen wird. Die DoD ist das wichtigste Werkzeug des Scrum-Teams zur Sicherstellung derProduktqualität. Die durchzuführenden Maßnahmen werden gemeinsam erarbeitet undzwischen Product Owner und Entwicklungsteam verhandelt. Es ist zulässig, die Definitionof Done in jeder Retrospektive zu verändern, wobei sie allerdings niemals verschlechtertwerden darf. Daher ist es ratsam, mit einer schlanken DoD zu beginnen. Alle vereinbartenMaßnahmen sind stets einzuhalten. In der Folge gelten nur solche umgesetzten ProductBacklog Items als fertig, die alle Anforderungen der DoD erfüllen. Ist auch nur ein Ele-ment der DoD nicht erfüllt, so kann das Product Backlog Item nicht abgenommen werdenund muss im nächsten Sprint fertiggestellt werden. Typische Elemente einer DoD sind:

• Alle Aufgaben sind erledigt bzw. es sind keine Reste mehr übrig• Jede Aufgabe wurde nach dem vier Augen Prinzip geprüft• Alle Akzeptanzkriterien sind erfüllt• Alle Akzeptanzkriterien sind durch automatische Tests abgesichert• Der Code ist vollständig integriert• Alle Tests der Software laufen fehlerfrei durch (auch die Bestandstests)• Die Dokumentation ist angepasst• Die Codierrichtlinien wurden eingehalten• Der Code wurde refaktorisiert

Diese Punkte sind nur als Beispiele anzusehen. Product Owner und Entwicklungsteamsind vollkommen frei in der Gestaltung ihrer DoD, der Phantasie sind keine Grenzen ge-setzt. Das Entwicklungsteam ist dafür verantwortlich, die DoD einzuhalten. Im Gegenzugstellt der Product Owner sicher, dass dem Team auch genug Zeit gegeben wird, die ge-wünschte Qualität zu liefern. So reden alle über das Gleiche, wenn sie „fertig“ sagen.

Der einzige unverzeihliche Fehler in Scrum ist der so genannte ethische Bruch. Die-ser tritt auf, wenn das Entwicklungsteam behauptet, es habe die DoD eingehalten, obwohles genau weiß, dass es dies nicht getan hat. Damit belügt es den Product Owner vorsätz-lich. Dieser ist normalerweise aufgrund mangelnder technischer Kenntnisse nicht in derLage zu beurteilen, ob die Aussage des Teams zutrifft und muss sich darauf verlassen kön-nen.Durch den ethischenBruch wird dasVertrauensverhältnis so fundamental geschädigt,dass eineweitere Zusammenarbeitmit diesemEntwicklungsteam in aller Regel keinen Sinnmehr macht – das Teammuss gehen. Auch fällt ein ethischer Bruch immer auf. Zwar meisterst nach einiger Zeit, aber früher oder später kommen die Sünden wieder ans Tageslicht.Für das Entwicklungsteam bedeutet das schlicht und einfach, dass es dem Product Ow-ner zu jeder Zeit offen und ehrlich sagen muss, wenn es die DoD nicht eingehalten hat.Das Schlimmste, was passieren kann, ist, dass die nicht fertigen Product Backlog Items imnächsten Sprint vervollständigt werden müssen. Ehrlich währt am längsten.