Scrum Guide und Skalierung: Teil 4 - Scrum Artefakte

Scrum Artefacts
Geschrieben von Peter Beck am 24.03.2015

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

Über den Autor

Andreas Schliep

Andreas Schliep ist ein Gründungsmitglied von DasScrumTeam AG. Er arbeitet als Scrum Coach und Trainer. Nach seinem Besuch der Hochschule Bremerhaven arbeitete Andreas zunächst als Softwareentwickler, Projektleiter, Teamleiter und später auch Bereichsleiter. Zu Scrum kam Andreas 2003-2004 durch seine damaligen Kollegen bei WEB.DE. Nach der Scrum Implementierung dort wechselte Andreas 2006 zur SPRiNT iT und machte sich 2008 als Coach und Trainer selbständig. Heute liegen seine Schwerpunkte neben der Einführung und dem Ausbau von Scrum insbesondere beim Qualitätsmanagement und der nachhaltigen Verbesserung von Entwicklungsteams.

  • Erfahrung mit Scrum seit Frühjahr 2004 als Scrum Master, Product Owner, Teammitglied, Coach und Trainer.
  • Einführung von Scrum bei der WEB.DE AG und ComBOTS AG
  • Betreuung von international verteilten Scrum Teams bei BenQ-Siemens
  • Betreuung von Scrum Teams bei bwin Wien Unterstützung des Übergangs von RUP zu Scrum bei UOL Brasilien
  • Weitere Scrum-Implementierungen in D/A/CH
  • Besondere Interessen: Skalierung und Verbesserungsprozesse
Yuliya Mijuk

Über den Autor

Peter Beck

Peter ist leidenschaftlicher Scrum Coach, Trainer (Certified Scrum Trainer, CST) und Moderator mit einem soliden Hintergrund im Engineering. Seit mehreren Jahren trainiert und coacht er eine große Bandbreite von Entwicklungsteams, Fachabteilungen, Projektleitern und Führungskräften in der Anwendung von Scrum, agilen Planungsmethoden und Softwareengineerings-Praktiken.
Peter hat die Österreichische Scrum Gruppe gegründet, an den Scrum Checklisten mitgewirkt, Publikationen auf InfoQ.com veröffentlicht. Er hält regelmäßig Vorträge auf agilen Konferenzen und Community Events.

  • 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 Partner der DasScrumTeam AG
  • Besondere Interessen: Agile Unternehmen und Scrum beyond Software