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.
Vor der eigentlichen Entwicklung stehen die Projektplanung sowie das Design der Grobarchitektur. Bei der Projektplanung werden die Vorgaben für das Projekt definiert und eine erste Version des Backlogs angefertigt. Die Erstellung des ersten Backlogs kann vor dem eigentlichen Scrum-Prozess erfolgen. Alternativ wird es vom Scrum-Team im Rahmen eines ersten Sprints gemeinsam erarbeitet.
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:
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.
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.
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:
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«:
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.
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