Der Scrum-Prozess

Nach unserer kleinen Einführung zum Ursprung von Scrum erklären wir in diesem Artikel, wie Scrum aufgebaut ist. Scrum wird in verschiedenen recht unterschiedlichen Meetings gelebt und liefert als Ergebnis einige Artefakte die hier im Folgenden beschrieben werden. 

Scrum Einführung

Der Product Owner erstellt anhand von Nutzenbeschreibungen eine Liste mit Anforderungen – das Product Backlog. Die Reihenfolge der Einträge legt zugleich deren Priorität fest. Alle Projektbeteiligten tragen zu seinem Inhalt bei.

Dies geschieht nicht nur zu Beginn einer Entwicklung und ebenso nicht nur zu bestimmten Zeiten, sondern laufend. Sobald Änderungswünsche oder neue Anforderungen auftreten, werden diese eingestellt. Diese grundlegende Offenheit, fortwährend Änderungen zu akzeptieren und diese nicht als Hindernis, sondern als Chancen zu betrachten, führt zu einer hohen Flexibilität in der Entwicklung.

Die Priorisierung erfolgt oft anhand des Geschäftswertes bzw. eines mit einer Anforderung verbundenen Risikos. So kann schnell auf sich ändernde Rahmenbedingungen reagiert werden, ohne das Projekt zu gefährden.

Ein Product Backlog kann beispielsweise folgende Form haben:

Sprint Planning Meeting und Sprint Backlog

Das Sprint Planning Meeting findet zu Beginn eines Sprints statt. An diesem Meeting nehmen alle Projektrollen teil. Team und Product Owner entscheiden hierbei über die Inhalte des nächsten Sprints.

Letzterer erläutert die am höchsten priorisierten Einträge (»Items«) des Product Backlogs und erklärt deren fachlichen Nutzen. Das Team schätzt den Aufwand der »Items« ab.

Aus den »Items« des Product Backlogs werden vom Team gemäß der Priorisierung Einträge für einen Sprint ausgewählt und in das Sprint Backlog überführt.

Sobald sich das Team und der Product Owner mit der Realisierung des Sprint Backlogs im nächsten Sprint einverstanden erklären, wird das Sprint-Ziel definiert.

Danach ergänzt das Team die Sprint Backlog »Items« um einen Umsetzungsplan, zumeist konkrete Entwicklungstätigkeiten.

Dann startet der Sprint. Die Anforderungen des Sprint Backlogs sind während eines Sprints aus Gründen der Stabilität nicht änderbar.

Die Impediment List

Sobald der erste Sprint gestartet ist, kann jedes Teammitglied die sogenannten Impediments (Blocker) in eine Liste einstellen. Jedes Team-Mitglied gibt, sobald sich ein Blocker für die Realisierung eines Tasks ergeben hat, diesen bekannt und stellt ihn in die Liste der Blocker.

Es ist die Aufgabe des Scrum Masters, diese Blocker zu beseitigen. Ein Blocker kann eine Rahmenbedingung sein, aber auch das Warten auf einen nicht fertiggestellten Task. Der Blocker wird im Daily Scrum Meeting an die anderen Team Mitglieder kommuniziert und in der Impediment List festgehalten.

Die zweite Tabelle stellt ein Beispiel einer Impediment List dar. Die Spalten können selbstverständlich noch erweitert werden. Eventuell wäre ein Status pro Zeile noch interessant, wenn nicht nur offene Blocker in der Liste enthalten sein sollen.

Daily Scrum Meeting

Hat ein Sprint begonnen, treffen sich das Team und der Scrum Master täglich zum Daily Scrum Meeting. Das Daily Scrum Meeting ist ein informelles Meeting von maximal 15 Minuten, welches, um es kurz zu halten, oft im Stehen abgehalten wird. In diesem Meeting hat jedes Teammitglied die Aufgabe folgende drei Fragen zu beantworten:

• Was habe ich gestern getan, um dem Entwicklungsteam zu helfen, das Ziel des Sprints zu erreichen?
• Was werde ich heute tun, um dem Entwicklungsteam zu helfen, das Ziel des Sprints zu erreichen?
• Sehe ich irgendein Hindernis, welches das Entwicklungsteam oder mich davon abhält, das Ziel des Sprints zu erreichen?

Dieses Meeting ist keine umfangreiche Diskussionsrunde, sondern ein kurzes Planungsmeeting des Teams, um abzustimmen was an diesem Tag zu tun ist, um das Sprintziel zu erreichen. Dies sicherzustellen ist die Aufgabe des Scrum Masters.

Die Hauptaufgabe des ScrumMasters ist es, auftretende Blocker zu beseitigen, aber nicht die Steuerung des Teams. Das Team organisiert sich selbst.

Folgende Richtlinien gelten für das »Daily Scrum«:

• Das Treffen startet immer pünktlich.
• Das Treffen sollte immer am gleichen Ort und zur gleichen Zeit stattfinden.
• Das Treffen findet offen statt, jeder darf teilnehmen, aber die eigentlichen Rollen haben Sprachrecht.
• Das Treffen ist immer auf maximal 15 Minuten, unabhängig von der Teamgröße, beschränkt.
• Die Teilnehmer sollten während des Treffens stehen. Dies soll helfen, das Treffen kurz zu halten.

Das Sprint Review Meeting / Scrum Retrospektive

Am Ende eines jeden Sprints erfolgt ein »Review Meeting«, in dem das Team die Ergebnisse dem Product Owner und anderen Stakeholdern vorstellt. Bei diesem Termin kann jeder teilnehmen und Feedback zum Ergebnis und dessen Weiterentwicklung geben.

Ebenfalls erfolgt am Ende eines Sprints eine Rückbetrachtung, die Retrospektive, auf den Sprint. Hierbei ist das ganze Scrum Team eingeladen. Es wird darüber diskutiert, was zukünftig verbessert werden soll.

Das Ziel der Sprints

Ein Hauptwert von Scrum ist es, wie bereits erwähnt, neue Anforderungen an das System nach jeder Iteration, jedem Sprint, einfließen lassen zu können. Mit jedem Durchlauf erhält der Kunde ein lauffähiges System, welches sich im Laufe der Zeit dem reinen Endprodukt immer weiter annähert. Im Gegensatz zu anderen iterativen Entwicklungsmodellen liegt bei Scrum das Hauptaugenmerk nicht nur auf lauffähigen, sondern auch tatsächlich einsetzbaren Systemen.

So soll die Entwicklung eines Gesamtsystems nicht in einzelne Module getrennt werden, die zwar getrennt voneinander geplant, realisiert, getestet und ausgeliefert werden können, aber als einzelne Module ohne das Gesamtsystem nicht wirklichkeitsgetreu eingesetzt werden können.

Damit soll vermieden werden, dass der Kunde erst am Ende ein tatsächlich von den Anwendern einsetzbares Produkt erhält und erst dann Änderungswünsche auftauchen. Der Grundsatz dabei ist, dass der Kunde erst dann wirklich entscheiden kann, was er tatsächlich an Funktionalität benötigt und wie diese verfügbar ist, wenn er mit einem System arbeitet – denn das Ziel sollte nicht zwingend sein, dass der Kunde das bekommt, was er spezifiziert hat, sondern das, was er tatsächlich benötigt. Die Priorisierung der Anforderungen nach Geschäftswert sorgt zusätzlich dafür, dass der Kunde frühzeitig seine wichtigsten Funktionen nutzen kann.

Im nächsten Post reden wir über die Kontrolle von Fortschritten im Sprint. Vorher könnt ihr euer Wissen wieder durch unsere Testfragen überprüfen. Viel Erfolg!

Fortschrittskontrolle im Sprint