Scrum Guide und Skalierung: Teil 4 - Scrum Artefakte

Geschrieben von Peter Beck am 24.03.2015
Scrum Artefacts

Scrum Artefakte oder Prozessdokumente dienen als Orientierung oder Bindeglieder im Prozessrahmen.

4.1 Product Backlog

Das Product Backlog ist das Kernartefakt von Scrum. Bei größeren Produktorganisationen wird das Management desselben unnötig verkompliziert. Was sind Kernaussagen, was sind die Spielregeln für ein Product Backlog, die auch für skalierte Umfelder gelten?

Zunächst einmal: es gibt nur ein Product Backlog. Dazu gibt es im Scrum Guide eine ganz klare Aussage:

Im Product Backlog werden alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen aufgelistet, die die Änderungen an dem Produkt in zukünftigen Releases ausmachen. […,] Häufig arbeiten mehrere Scrum Teams gemeinsam an einem Produkt. Dann wird ein einziges Product Backlog benutzt, um die anstehende Arbeit am Produkt zu beschreiben. In diesem Fall kann ein Gruppierungsattribut für die Product Backlog-Einträge verwendet werden.


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. 

 

Andreas Schliep

Andreas „Andy“ Schliep

Andy ist einer der ersten deutschsprachigen Scrum-Trainer und ein Gründungsmitglied von DasScrumTeam. Nach seinem Studium an der Hochschule Bremerhaven begann Andreas seine Karriere zunächst als Softwareentwickler, später dann als Projektleiter, Teamleiter und schließlich als Bereichsleiter. Zu Scrum fand Andreas zwischen 2003 und 2004 durch seine damaligen Kollegen bei WEB.DE. Nach der Implementierung von Scrum bei WEB.DE wechselte Andreas im Jahr 2006 zu SPRiNT iT und entschied sich 2008, als Coach und Trainer selbstständig zu machen. Heute fokussiert er sich neben der Einführung von Scrum vor allem auf agile Führungskompetenzen und die nachhaltige Transformation von Organisationen. Als Co-Autor hat Andy an der Erstellung der Lernziele der Scrum Alliance für Scrum Master, Product Owner und Entwickler mitgewirkt.

Peter Beck

Über den Autor

Peter Beck

Peter hat es sich zur Aufgabe gemacht Unternehmen zu schaffen, die Wert für ihre Kunden und ihre Mitarbeiter liefern. Das war auch seine Motivation für die Gründung von DasScrumTeam. Peter ist leidenschaftlicher Scrum Trainer (Certified Scrum Trainer, CST) und Berater mit einem soliden Hintergrund im Engineering. Seit 2007 trainiert und berät er eine große Bandbreite von Entwicklungsteams, Fachabteilungen, Projektleitern und Führungskräften in der Anwendung von Scrum, agilen Planungsmethoden und Softwareengineerings-Praktiken. Peter ist Diplom-Ingenieur für Elektro und Informationstechnik (TU).

  • Erfahrung mit Scrum seit 2004 als Teammitglied, ScrumMaster, Product Owner, Coach und Trainer.
  • Führen von international verteilten Scrum Teams als ScrumMaster
  • Mitgründer und Product Owner der DasScrumTeam AG
  • Besondere Interessen: Agile Unternehmen und Scrum beyond Software

Immer informiert mit dem DasScrumTeam Newsletter

Das Beste in Sachen Scrum. Einmal im Monat. Jeden Monat.