Blogbeitrag
Der Scrum Prozess
Im folgenden Beitrag möchte ich den Scrum Prozess grob erklären und auf die wichtigsten Eckdaten dazu eingehen. Alle einzelnen Events und Artefakte werden in einem der nächsten Beiträge noch sehr detailliert behandelt.
Die folgende Darstellung soll erst einmal einen groben Überblick vermitteln und Zusammenhänge zwischen den Events und den Artefakten beschreiben:
Im Scrum gibt es insgesamt fünf Scrum Events:
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospektive
- Backlog Refinement
Des Weiteren haben wir drei Scrum Artefakte:
- Product Backlog
- Sprint Backlog
- Sprint Inkrement
Um Transparenz und Fokus auf den Fortschritt eines jeden Artefakts zu bringen gibt es die Commitments. Für das Product Backlog ist dies das Product Goal, für das Sprint Backlog das Sprint Goal und für das Increment die Definition of Done.
Der Scrum Sprint ist ein wiederholbarer und regelmäßiger Arbeitszyklus innerhalb von Scrum, in dem Arbeit erledigt und zur Überprüfung bereitgehalten wird. Er ist zeitgesteuert und geschützt vor Änderungen.
Im Scrum wird von drei Rollen gesprochen: die Rolle des Product Owners, die Rolle des Scrum Masters und die Rolle der Entwickler. Da die Stakeholder, also die Kunden, Interessenten und Nutzer des zu entwickelnden Produktes, ebenfalls eine wichtige Rolle im Scrum Prozess spielen, werden sie in der Abbildung ebenfalls aufgeführt.
Am Anfang steht die Produkt Vision, also eine grobe Vorstellung eines Produktes oder Ergebnisses. Dies kann zum einen ein komplett neues Projekt oder Produkt sein, welches z.B. ein neuer Auftraggeber mitbringt. Oder aber der Kunde ist mit seinem aktuellen Produkt nicht mehr zufrieden und möchte seine neuen Anforderungen und Wünsche umgesetzt haben, weil die Konkurrenz ihn überholt hat. Bestehende Produkte können aber auch in ihrer Fehleranfälligkeit oder Dynamik verbessert werden. Ebenso können neue gesetzliche Anforderungen zu einem neuen Scrum Projekt werden.
In unserem Scrum Prozess befinden wir uns nun an der Stelle oben links.
1. Product Vision
Der Product Owner mit seiner Produkt Vision muss nun die Anforderungen für das Projekt ermitteln und in User Storys oder Story Cards festhalten. Dafür muss er Funktionen und Merkmale beschreiben, Lösungen erarbeiten, welche entwickelt werden sollen und die Anforderungen, Erwartungen und Wünsche in User Stories verpacken. User Stories werden ggf. zusammen mit den Stakeholdern erfasst. Aus allen Informationen kann man schließen, welche Qualifikationen man im Entwicklerteam benötigt und eine grobe Schätzung des Aufwands für die Entwicklung ist ebenfalls schon möglich.
2. Product Backlog
All diese Funktionen und Merkmale werden dann im Product-Backlog gesammelt. Dort werden sie auch als Backlog-Items bezeichnet. Die User Stories existieren noch nicht detailliert – Teilaufgaben mit mehr Details müssen daraus noch erstellt werden. Dies geschieht alles fortlaufend. Immer wieder wird mit Stakeholdern und dem Team kommuniziert.
Nachdem die Prioritäten für die Backlog-Items vergeben wurden, wird der Ablauf des Projekts betrachtet, aber auch Rahmenbedingungen abgesteckt, ein gemeinsames Verständnis vom Produkt und von den Aufgaben entwickelt und der zeitlicher Ablauf geklärt. Diese Ablaufplanung wird nur ganz grob aufgestellt – es gibt noch keine Detailplanung. Wichtig ist nur, dass Meilensteine, wichtige Ziele und KO Kriterien bekannt sind.
3. Product Backlog Refinement
Im anschließenden Product Backlog Refinement, welches in der Abbildung innerhalb des Sprintes dargestellt wird, da es ein immer wiederkehrendes Scrum Event ist und nicht nur zu Beginn des Scrum Prozesses durchgeführt wird, wird der Entwicklungsaufwand der User Storys für den nächsten Sprint mit Story Points bewertet. Diese stellen die Komplexität für die Realisierung dar und werden durch das Planning Poker ermittelt. Teilnehmer sind Product Owner, Scrum Master und die Entwickler. Das Refinement sollte die Zeit von 1-4 Stunden nicht überschreiten.
4. Sprint Planning und Sprint Backlog
Im folgenden Sprint Planning werden einzelne Aufgaben bestimmt. Dabei klärt das Scrum Team, welche Items aus dem Product Backlog in Einzel- oder Teilaufgaben – den sogenannten Tasks – zerlegt werden. Für den kommenden Sprint wird das Sprint Backlog mit Stories und Tasks gefüllt, welche für den Sprint und die Developers schaffbar sind.
Das Sprint Planning sollte nicht mehr als 2-8 Stunden in Anspruch nehmen – abhängig davon, wie lang der Sprint Zyklus gewählt wurde. Teilnehmer sind das komplette Scrum Team und eventuell die Stakeholder.
5. Sprint Board
Die Entwickler arbeiten innerhalb des Sprints an ihren Aufgaben und erledigen sie. Der Aufgabendurchlauf wird durch das Scrum oder Kanban Board gesteuert. Dieses Visualisiert den Durchlauf der Story Cards innerhalb des Boards und zeigt an welcher Stelle bzw. in welcher Phase sich die Aufgabe momentan befindet.
6. Daily Scrum
Im Daily Scrum werden regelmäßig Lösungen besprochen. Das Daily Scrum ist ein 15 minütiges Treffen der Entwickler und des Scrum Masters – der Product Owners muss nicht zwingendermaßen dabei sein. Gibt es Probleme oder Hindernisse bei der Bewältigung der Aufgaben, so werden sie besprochen und versucht zu klären. Der Scrum Master nimmt sich derer an. Der Arbeitsfortschritt wird während dieses täglichen Meetings eingeschätzt und der geschätzte mit dem tatsächlichen Aufwand verglichen. Auf möglichen ungeplanten Aufwand wird eingegangen.
7. Sprint Review und Inkrement
Wenn der Sprint abgeschlossen wurde, werden die Lösungen im 1-4 stündigen Sprint-Review-Meeting vorgestellt. Dabei werden die Ergebnisse aus dem Sprint – genannt das Product Increment – dem Team und den Stakeholdern präsentiert. Das Inkrement wird mit der Definition of Done verglichen. Der PO und die Stakeholder entscheiden, ob die User Story abgenommen wird oder Verbesserungen durchgeführt werden müssen.
8. Sprint Retrospektive
In der abschließenden Sprint Retrospektive, die maximal 1-3 Stunden veranschlagen sollte, wird die Zusammenarbeit im Team überprüft und besprochen, was verbessert werden kann. Das komplette Scrum Team nimmt daran teil. Fragen wie “Was lief gut?”, “was lief nicht gut?” und “was kann man besser machen?” werden geklärt.
Danach folgt der nächste Sprint.
Wenn ein komplettes Projekt abgeschlossen ist, und keine Sprints mehr folgen, wird ein Projekt Review durchgeführt. Dabei wird das Produkt vom Product Owner vorgestellt. Alle vom Nutzer bzw. Stakeholder gegebenen Anforderungen inklusive der gewünschten Änderungen während der Projektlaufzeit werden überprüft und die Prioritäten beachtet. Das Projekt Review ist sozusagen ähnlich dem Sprint Review nur über das komplette Projekt hinweg.