Der Scrum-Reiseführer. Tobias Renk

für das Scrum Framework zu schaffen und dafür zu sorgen, dass das Regelwerk eingehalten wird. Zudem ist er Ansprechpartner, um alle Probleme zu beseitigen, die das Team an der Zielerreichung behindert. Dabei ist der Punkt Regelwerk ein Thema für sich. Während mit dem Begriff eine gewisse Starrheit und Gehorsam in der Führung assoziiert werden könnten, steckt darin bereits ein Grund, weshalb in der Praxis die Einführung von Scrum Probleme bereitet. Es geht weniger darum, Scrum à la Textbuch einzuführen, sondern die Gegebenheiten der Organisation miteinzubeziehen und die passende Variante von Scrum zu finden. Letztendlich ist das doch der Kern einer agilen Organisation, oder?

      Bisher gab es mit dem Product Owner, dem Scrum Master und dem Development Team drei Scrum Rollen, die zusammen das Scrum Team bildeten. Im Scrum Guide 2020 wurde das Development Team gestrichen und die Rollen durch die drei Verantwortungen (Accountabilities) Scrum Master, Product Owner und Developer ersetzt. So kommt es nicht mehr zu der häufigen Frage, ob der Scrum Master oder der Product Owner nicht Teil des Teams sind. In Großunternehmen hat die bisherige Team-im-Team-Struktur häufig zusätzlich dazu geführt, dass unnötige Hierarchieebenen in die Scrum Teams einbezogen wurden und die Development Teams an ihre Product Owner berichten mussten. Mit der Abschaffung des Development Teams wird hervorgehoben, dass alle Mitglieder eines Scrum Teams gemeinsam für die produktbezogenen Aktivitäten verantwortlich sind. Dazu muss das Scrum Team so aufgestellt sein, dass es alle notwendigen Fähigkeiten vereint, um mit jedem Sprint mindestens ein neues Produktinkrement zu schaffen. Der Verantwortungsbereich eines Developers ist hierbei nicht auf die Softwareentwicklung begrenzt. Grafikdesigner, Experten aus dem Fachbereich oder Linienmanager können beispielsweise auch inhaltlichen Mehrwert liefern.

      Das Scrum Team ist selbstverwaltend (self managing) und nicht mehr selbstorganisierend (self organised). In der Folge bedeutet das nicht nur einen Austausch der Begrifflichkeiten. Der Fokus wird dadurch noch stärker auf die Eigenverantwortung des Scrum Teams gelenkt. Allein das Team ist verantwortlich für alle produktbezogenen Aktivitäten. Hierfür muss es sich selbst verwalten. Es muss also dazu befähigt werden, selbst entscheiden zu können, welche Arbeiten wie zu erledigen sind und wer sich wann darum kümmert.

      3.3 Scrum Artefakte

      Unter Artefakten versteht man Prozessdokumente, die während eines Projekts erstellt werden. Scrum kennt die drei Artefakte Product Backlog, Sprint Backlog und Produktinkrement. Das Product Backlog listet die priorisierten Anforderungen an das zu erstellende Produkt auf. Diese Aufstellung ist niemals vollständig und existiert in der Regel so lange, wie das Projektprodukt entwickelt wird. Der Product Owner ist für das Product Backlog verantwortlich und überarbeitet kontinuierlich die Backlog-Anforderungen und deren Prioritäten. Das bedeutet, dass er die Einträge regelmäßig verfeinert, das Backlog um neue Anforderungen erweitert und obsolet gewordene Anforderungen aus der Aufstellung löscht. Je wichtiger eine Anforderung ist, desto detaillierter muss sie ausformuliert und desto größer muss deren Priorität sein. Beschrieben werden die Anforderungen häufig in Form von User Stories. Das Sprint Backlog enthält die Product Backlog-Einträge, die in der aktuellen Projektiteration umgesetzt werden sollen. Diese Einträge werden auch als Sprint Backlog Items bezeichnet. Die Verantwortung für das Sprint Backlog liegt beim Entwicklerteam. Das bedeutet insbesondere, dass das Team entscheidet, welche Product-Backlog-Einträge es in der nächsten Iteration bearbeitet und wie diese in detaillierte Aufgaben (Tasks) unterteilt werden können. Während eines Sprints wird das Sprint Backlog nach der Erledigung eines Tasks vom Entwicklerteam aktualisiert. Das Ergebnis einer Iteration bezeichnet man als Produktinkrement. Dieses Artefakt besteht somit aus den in der aktuellen Iteration umgesetzten User-Stories und allen Anforderungen, die bereits in den vorherigen Iterationen realisiert wurden. Wichtig ist, dass jedes Produktinkrement release-fähig ist, also potenziell an den Kunden ausgeliefert werden kann.

      Im neuen Scrum Guide wird das ProduktzielProduktziel (Product Goal) als zusätzliche Begrifflichkeit eingeführt. Dieses Ziel beschreibt, was der Sinn des zu erstellenden Produkts ist. Eine konkrete Benennung des Sinns vermeidet eine willkürliche Ansammlung von Features, Tasks und Defects. So steht das Produktziel als Leitbild über dem Product Backlog und mit jedem Sprint wird das Produkt näher an dieses Produktziel herangebracht.

      Die Einführung des Produktziels ermöglicht es, jedem Scrum Artefakt eine klare Zuordnung (CommitmentCommitment) zuzuweisen: Das Produktziel gehört zum Product Backlog, das SprintzielSprintziel zum Sprint Backlog und die Definition of Done zum Produktinkrement. Diese drei Commitments sollen die Transparenz erhöhen und den Entwicklungsfortschritt sicht- und messbarer machen. Das Produktziel wird vom Product Owner entwickelt und gilt für das gesamte Scrum Team. Das Sprintziel wird vom Scrum Team festgelegt und ist die selbstverpflichtende Zielvorgabe für den aktuellen Sprint. Die Abschlusskriterien für ein Produktinkrement (Definition of DoneDefinition of Done) werden vom Scrum Team in Einklang mit den Organisationsvorgaben erstellt. Die Entwickler verpflichten sich dazu, diese Kriterien bei der Erstellung des Produktinkrements zu erfüllen.

      Der Scrum Guide 2020 ermöglicht die Erstellung mehrerer Produktinkremente in einem Sprint. In der Vergangenheit war es notwendig, bis zum Sprintende zu warten, um ein neues Produktinkrement produktiv setzen zu können. Stattdessen gilt nun: Jedes Mal, wenn ein Product Backlog Item die Definition of Done erfüllt, gibt es ein neues Produktinkrement. Diese Inkremente können also auch während eines Sprints abgenommen und theoretisch ausgeliefert werden. Dadurch wird nicht nur eine kontinuierliche Auslieferung ermöglicht, die Änderung führt hoffentlich auch dazu, dass das Sprint Review nicht mehr als „Freigabe-Veranstaltung“ missinterpretiert wird. Ziel des Sprint Reviews ist es vielmehr, anhand der Prüfung der erstellten Produktinkremente neue Impulse für das Product Backlog zu bekommen, um so die zukünftigen Sprintziele noch besser am Produktziel ausrichten zu können. Damit sind wir bereits mittendrin in den Scrum Events.

      3.4 Scrum Events

      Das Vorgehensmodell Scrum beinhaltet fünf Ereignisse mit festgelegter Dauer. Dazu gehören der Sprint, das Sprint Planning, das Daily Scrum, das Sprint Review und die Sprint Retrospektive. Der ein- bis vierwöchige Sprint repräsentiert einen vollständigen Iterationslauf. Innerhalb dieser Zeitspanne findet die eigentliche Entwicklungsarbeit statt und es werden die übrigen vier Ereignisse praktiziert. Endet ein Sprint, startet direkt im Anschluss die nächste Iteration. Ein Sprint kann vom Product Owner jederzeit abgebrochen werden. Der Sprint wird mit dem Ereignis Sprint Planning eröffnet. In diesem Meeting stellt der Product Owner das Ziel des Sprints vor. Das Entwicklungsteam erstellt das Sprint Backlog, indem es so viele Anforderungen aus dem Product Backlog übernimmt, wie es in einem Sprint umsetzen kann. Während des Sprints findet täglich zur gleichen Zeit das Daily Scrum statt. Dies ist ein kurzes Meeting, in dem jeder Entwickler auf seine aktuelle Arbeit eingeht und den Fortschritt bis zum nächsten Daily Scrum prognostiziert. Hierzu beantworten die Entwickler üblicherweise nacheinander folgende drei Fragen:

      1 Was war mein Beitrag zum Sprintziel seit dem letzten Daily Scrum?

      2 Welche Aktivitäten plane ich bis zum nächsten Daily Scum?

      3 Sehe ich Hindernisse, die mich oder das Entwicklungsteam vom Erreichen des Sprintziels abhalten?

      Die beiden übrigen Ereignisse folgen am Ende eines Sprints. Zunächst wird im Sprint Review das erstellte Produktinkrement vorgestellt. An dieser Veranstaltung nehmen das ganze Scrum Team und die Projekt Stakeholder teil. Ziel ist es, von den Stakeholdern ein Feedback über das Produktinkrement zu erhalten. Dieses wird anschließend genutzt, um das Product Backlog anzupassen und um neue Anforderungen aufzunehmen. In der abschließenden Sprint Retrospektive reflektiert das Team den Verlauf und diskutiert Verbesserungsmöglichkeiten für den nächsten Sprint.

      Während eines Sprints findet die Entwicklungsarbeit an den Sprint Backlog Items statt. Gestartet wird mit dem Sprint Planning Meeting. In dieser Besprechung fokussiert man sich auf folgende zwei Fragestellungen: Was kann in diesem Sprint realisiert werden und wie wird diese Arbeit umgesetzt? Das Entwicklungsteam übernimmt im ersten Teil der Planungssitzung so viele User Stories aus dem Product Backlog in das Sprint Backlog, wie es im Sprint umsetzen kann. Hieraus abgeleitet formuliert das gesamte Scrum Team das Ziel des Sprints. Im zweiten Teil überlegt das Entwicklungsteam, welche Tasks zum Erreichen ihres Sprintziels und zur Abarbeitung der ausgewählten