Scrum Guide und Skalierung: Teil 4 - Scrum Artefakte

• Scrum Guide und Skalierung: Teil 1 - Scrum Theorie
• Scrum Guide und Skalierung: Teil 2 - Die Scrum Teams
• Scrum Guide und Skalierung: Teil 3 - Die Scrum Ereignisse
• Scrum Guide und Skalierung: Teil 4 - Die Scrum Artefakte

Ein solches Gruppierungsattribut eignet sich für die Filterung des Product Backlogs in verschiedenen Szenarien:

• Bei der Schätzung durch ein passendes Entwicklungsteam
• Beim Sprint Planning, um die Teamaufteilung zu kennzeichnen
• Generell, um zusammengehörige Product Backlog-Einträge als solche zu kennzeichnen.

4.2 Sprint Backlogs

Wie schon im Abschnitt Sprint Planning - Punkt 2 beschrieben, erarbeiten und pflegen Entwicklungsteams ihren Arbeitsplan für den kommenden Sprint in Form eines Sprint Backlogs. Im Regelfall führt jedes Entwicklungsteam sein eigenes Sprint Backlog im eigenen Daily Scrum fort, wie sich auch schon aus diesem Zitat ableiten lässt:

Das Sprint Backlog ist ein ausreichend detaillierter Plan, um den Fortschritt innerhalb des Sprints im Daily Scrum erkennen zu können.

Kann es nicht ein gemeinsames Sprint Backlog für alle Entwicklungsteams geben? Das könnte die Komplexität der Abstimmung erhöhen, anderseits für mehr Transparenz in Bezug auf die gemeinsame Lieferung sorgen. Nun, dazu trifft der Scrum Guide keine Aussage. Das Sprint Backlog besteht aus der Auswahl der für den aktuellen Sprint selektierten Product Backlog-Einträge sowie den Umsetzungsplan des Teams. Wenn sich die Entwicklungsteams für einen gemeinsamen Umsetzungsplan entscheiden, liegt das in ihrer Verantwortung. Die Herausforderung der Scrum Master ist es, dem Team dementsprechend Alternativen vorzustellen und die selbstorganisierte Arbeit in Abstimmung mit den anderen Entwicklungsteams und dem Product Owner zu unterstützen.

4.3 Inkrement

Das Inkrement ist das Ergebnis aus allen in einem Sprint fertiggestellten Product Backlog- Einträgen und dem Resultat der Inkremente aller früheren Sprints. Am Ende eines Sprints muss das neue Inkrement "Done" sein; das heißt es muss in einem verwendbaren Zustand sein und die Definition of Done des Teams erfüllen.

Wenn mehrere Scrum Teams an einem Produkt arbeiten, dann gelten die Spielregeln für diese Produktorganisation so wie für ein einzelnes Scrum Team. Das bedeutet insbesondere, dass der Product Owner am Ende eines gegebenen Sprints auch ein einziges - also vollständig integriertes - Inkrement entgegennehmen kann.

Es ist durchaus möglich, dass in einer skalierten Variante des Sprint Reviews Teilaspekte des Produkt-Inkrements mit den jeweiligen Entwicklungsteams begutachtet werden. Ungeachtet dessen gibt es in einer Produktorganisation nach Scrum nur ein Produkt, und nach jedem Sprint ein Inkrement dieses Produktes in potentiell auslieferbarem Zustand.

4.4 Transparenz der Artefakte

Die Aufgabe des Scrum Masters ist es, mit dem Scrum Team und der Organisation an der Verbesserung der Transparenz der Artefakte zu arbeiten. Diese Arbeit bedeutet zumeist Lernen, Überzeugen und Verändern. Transparenz fällt einem nicht in den Schoß, sie ist ein Weg, den es zu beschreiten gilt.

Dem ist eigentlich nichts hinzuzufügen. Und das ist wörtlich gemeint. Jedes Artefakt, das über die inhärenten Product Backlog, Sprint Backlog, Inkrement und dem ein oder anderen Fortschritts-Reporting hinaus eingesetzt wird, bremst das Scrum Team aus. Das bedeutet nicht automatisch, dass man auf jedwede Zusatzdokumente verzichten sollte. Wenn der Wert eines Artefakts seine Kosten übersteigt, kann es von einer Produktorganisation gerne zum Einsatz gebracht werden.

Übrigens: Mit Artefakten sind hier nicht Produktbestandteile, wie Betriebshandbücher oder Online-Hilfen gemeint. Solche Produktbestandteile werden u.a. in der Definition of Done oder im Product Backlog als Liefergegenstände erfasst.

4.5 Definition of "Done"

Aus dem Scrum Guide ergibt sich eine scheinbar paradoxe Vorschrift für die Definition of "Done" mehrerer Scrum Teams:

Es müssen alle verstehen, was „Done“ bedeutet, sobald ein Product Backlog-Eintrag oder ein Produkt-Inkrement als „Done“ bezeichnet wird. Obwohl sich dies erheblich von Scrum Team zu Scrum Team unterscheidet, müssen alle Teammitglieder ein gemeinsames Verständnis davon haben wann Arbeit fertig ist, um Transparenz zu gewährleisten.

Bedeutet das nun, eine gemeinsame Definition of „Done“ für eine Reihe von Scrum Teams aufzustellen, oder nicht? Prinzipiell befolgen alle Scrum Teams, die an einem Produkt arbeiten, die gleiche Definition von „Done“. Es gibt allerdings Fälle, in denen ein bestimmtes Scrum Team eine abweichende, meistens umfangreichere Definition von „Done“ als Maßstab hat. Das gilt insbesondere, wenn in einem Produktbereich andere Anforderungen an die Dokumentation oder Überprüfung des Inkrements gelten. Gerade in diesem Fall muss die Produktorganisation beachten, dass die unterschiedlichen Stufen allen bekannt sind, die an dem Produkt arbeiten - um zum Beispiel eine falsche Einschätzung der Leistung des betreffenden Teams zu vermeiden.