Was ist Scrum?

Scrum ist eine agile Projektmanagement Methode, welche im Gegensatz zu linearen PM-Methoden sich weniger auf umfangreiche Planung fokussiert und mehr in Richtung Agilität und Flexibilität geht. Vor allem bei kleineren Softwareentwicklungs-Projekten ist Scrum sehr sinnvoll.

Wie funktioniert Scrum?

Der Prozess beginnt damit, dass das Projektteam in einem Meeting die Anforderungen an das Produkt definiert und eine „Prioritätenliste“ erstellt. Diese Liste, auch Product Backlog genannt, enthält alle Anforderungen an das Produkt, die von hoher bis niedriger Priorität geordnet sind.

In jeder Iteration, die als Sprint bezeichnet wird, wählt das Team eine Anzahl von Anforderungen aus dem Product Backlog aus und plant, wie diese in der nächsten Iteration entwickelt werden sollen. Während eines Sprints arbeitet das Team täglich, um den Fortschritt zu überwachen und Hindernisse zu identifizieren bzw. beseitigen.

Am Ende des Sprints präsentiert das Team das fertige Produktinkrement in einem Sprint Review-Meeting. Dabei wird der Fortschritt besprochen und welche Änderungen im nächsten Sprint vorgenommen werden müssen, um das Produkt zu optimieren.

Während des gesamten Prozesses arbeitet das Projektteam in kurzen Zeitblöcken, um schnell Kundenfeedback zu erhalten und Änderungen vorzunehmen.

Scrum ist eine agile Projektmanagement-Methode, welche für schnelle und flexible Entwicklung von Software konzipiert wurde. Es ermöglicht Teams, ihre Arbeit in kurzen, iterativen Abläufen zu planen, verfolgen und anzupassen, um kontinuierlich hochwertige Ergebnisse zu liefern. Der Prozess beginnt damit, dass das Projektteam in einem Meeting die Anforderungen an das Produkt definiert und eine „Prioritätenliste“ erstellt. Diese Liste, auch Product Backlog genannt, enthält alle Anforderungen an das Produkt, die von hoher bis niedriger Priorität geordnet sind.

Während des gesamten Prozesses arbeitet das Projektteam in kurzen Zeitblöcken, um schnell Kundenfeedback zu erhalten und Änderungen vorzunehmen.

AGILE PROJEKTENTWICKLUNG

Von der Planung bis zum Produkt:
Der Scrum-Prozess in fünf Schritten

Produkt Backlog
Sprint Planning
Sprint Backlog
Sprint Review
Sprint Retrospective

Ereignisse

Am Anfang eines jeden Projektes hat der Auftraggeber eine Vision bzw. Vorstellung des Produktes (Product Vision). Natürlich sollte das Produkt auch einen Nutzen für den Kunden haben. Diese Vorstellung ist im Scrum der Projektauftrag. Die Vision wird in User Stories aufgeteilt. Diese beschreiben aus Sicht des Anwenders die Funktionen des Produkts.

Product Backlog

Diese User Stories bilden gemeinsam den Product Backlog. Am Anfang eines jeden Projektes ist der Backlog meistens sehr grob, doch mit der Zeit wird er immer genauer und präziser. Innerhalb des Backlogs wird ebenfalls sortiert und jeder Userstory eine Priorität zugewiesen. Eine hohe Priorität erhalten Storys mit den wichtigsten Funktionen sowie welche, mit denen dem Anwender eine hohe Zufriedenheit sichergestellt wird.

Sprint Planning

Ein Scrum Projekt setzt sich aus mehreren Sprints zusammen. Es erfolgen so viele Sprints, bis das Produkt fertiggestellt ist. Jeder Sprint dauert in der Regel zwischen 2 und 3 Wochen. Um sich auf den Sprint vorzubereiten, gibt es das Sprint Planning. In dieser Phase stellt man sich die Fragen:

• Welche User Stories werden im nächsten Sprint behandelt?
• Wie setzen wir die geplanten Aufgaben um?

Das Ergebnis dieser Phase ist ein Sprint Backlog. Das Ganze besteht aus Einträgen, welche im bevorstehenden Sprint behandelt werden sollen. Wann die Aufgabe als erledigt gilt oder nicht, wird in der Definition of Done festgelegt. Die Mitarbeiter suchen sich selbst ihre User Stories aus und arbeiten sie bis zur Definition of Done ab.

Daily Scrum

Der Sprint läuft und jedes Mitglied arbeitet an seinen/ihren Aufträgen. Während des Sprints gibt es jeden Tag um dieselbe Uhrzeit, meistens kurz nach Arbeitsbeginn, das Daily Scrum. In diesem Meeting berichtet jedes Teammitglied essenziell über drei Sachen.

• Was hat er/sie seit dem letzten Daily gemacht?
• An welchen Aufgaben will ich heute arbeiten?
• Wie soll die Aufgabe gehen?

Bei der letzten Frage kommt der Scrum Master ins Spiel. Die Aufgabe des Scrum Masters ist es unter anderem, Hindernisse zu beseitigen, um den Projektmitarbeitern und -mitarbeiterinnen ein sauberes Arbeiten zu ermöglichen. Alle Probleme werden in der von ihm geführten Impediment List festgehalten.

Sprint Review

Nach jedem Sprint folgt ein Sprint-Review. In diesem werden die Ergebnisse des Sprints vorgestellt. Der Product Owner prüft, ob die erfüllten abgeschlossenen Aufgaben mit der Definition of Done übereinstimmen. Am Ende eines jeden Sprints muss es ein Product Increment geben. Ein Product Increment ist ein releasefähiges Ergebnis, welches dem Kunden nach einem Sprint, in einer realistischen Systemumgebung, sowohl gezeigt als auch, von ihm getestet werden kann. Damit erhält der Auftraggeber die Möglichkeit, Wünsche oder Kritik zu äußern und somit sein Produkt nach seinen Vorstellungen zu verändern. Durch diese ständige Einbeziehung des Kunden wird eine Verfehlung verhindert und spart immense Kosten.

Sprint Retrospektive

Die letzte Iteration, auch Sprint Retrospektive genannt, ermöglicht es zusammen mit dem Team einen Rückblick auf das abgeschlossene Sprint zu werfen. Es dient als Lernprozess, indem besprochen wird, was schlecht gelaufen ist und welche Verbesserungsvorschläge/Maßnahmen es gibt. Die Retrospektive wird vom Scrum Master organisiert und moderiert.

Artefakte

Artefakte, auch Schlüsselkomponenten genannt, sind Dokumente in Form von Listen, welche für einen reibungslosen Ablauf und eine erhöhte Transparenz sorgen. Mithilfe dieser Artefakte werden der Arbeitsfortschritt dokumentiert und repräsentiert sowie die Ziele dargestellt.

Product Backlog

Product Backlog, das erste der 3 Artefakte, ist eine Liste mit allen Produktanforderungen. Alle darin enthaltenen User Stories werden vom Product Owner regelmäßig sortiert und priorisiert. Im Laufe der Zeit wird der Product Backlog immer präziser und dient als Basis für die Auswahl der im nächsten Sprint zu erledigenden User Stories, welche im Sprint Backlog festgelegt werden.

Sprint Backlog

Nun zum Sprint Backlog, welcher alle User Stories, die für den nächsten Sprint bestimmt wurden, in Form einer Liste festhält. Der Product Owner hat die Verantwortung den Status der Aufgaben zu überprüfen, sodass am Ende des Sprints alle User Stories fertig und getestet sind. Die am häufigsten verwendete Methode, den Sprint Backlog darzustellen, wäre ein Kanban Board.

Nun zum Sprint Backlog, welcher alle Aufgaben, die für den nächsten Sprint bestimmt wurden, in Form einer Liste festhält. Das Projektteam hat die Verantwortung alle, im Sprint Backlog, vorhandenen User Stories fertigzustellen, sodass am Ende des Sprints alle User Stories getestet werden können. Die am häufigsten verwendete Methode, den Sprint Backlog darzustellen, wäre ein Kanban Board.

Product Increment

Nach jedem Sprint erfolgt die Präsentation des sogenannten Product Increments. Das Team – inklusive Product Owner und Scrum Master – präsentiert dem Kunden, die im Sprint abgeschlossenen User Stories, welche der Defintion of Done entsprechen müssen. Durch die Kundenmiteinbeziehung können Wünsche bzw. Änderungen am Produkt/Projekt frühzeitig vorgenommen werden.

Agiles Schätzen

Bevor das Arbeiten im agilen Projektmanagement beginnt, muss der Product Backlog sauber sein. Das Team setzt sich mit dem Produkt Owner zusammen, um die Komplexität jeder Userstory zu bewerten.

Um besser Schätzen zu können und damit das Risiko einer Über-/Unterschätzung zu minimieren, wird häufig die Fibonacci-Reihe als Referenz verwendet.

Fibonacci Reihe: 0,1,2,3,5,8,11,21,34,55,89 …

Der Schätzvorgang wird auch Planning Poker genannt.

Userstory Beispiel:
Als Benutzer möchte ich mich einloggen können, um mit der App bezahlen zu können.

Wie viele Story Points würdest du schätzen?

Eine richtige Antwort gibt es nicht. Der Sinn dahinter ist eine komplexe Aufgabe in mehrere kleine Userstories abgearbeitet werden kann und damit Transparenz schafft. Die Storypoints könnten folgendermaßen aussehen:

• Benutzer kann sich einloggen
• Benutzer kann Betrag zum Bezahlen auswählen
• Der Benutzer erhält nach Bezahlung eine Bestätigung der Zahlung in der App

Um die Story Points zu ermitteln, sind bereits zahlreiche Methoden vorhanden. Die am weitesten verbreitete Methode ist das Planning Poker. Jedes Projektteammitglied erhält Karten mit den Fibonacci Zahlen. Danach wird jede Userstory Runde für Runde besprochen und damit ein Wert festgelegt. Dadurch erhält jeder die Möglichkeit, seine Zahl zu begründen und die Ansichten der anderen Teammitglieder zu verstehen.

Neben den Story Points gibt es auch die Value Points. Bei den Value Points liegt der Fokus auf dem Business Value. Die Business Value setzt sich aus dem technischen und Kundennutzen zusammen. Zur Schätzung der Value Points wird, wie auch bei den Story Points, die Fibonacci Reihe verwendet.

Anschließend müssen die User Stories sortiert werden. Doch was soll man jetzt höher priorisieren? Sollen User Stories mit hohem Value, welche in der Umsetzung länger dauern anstelle, von User Stories mit wenigen Story Points bevorzugt werden. Da kommt der dritte Wert in Spiel. Der Bang-for-the-Buck-Wert gibt an, wie das Preis/Leistungs-Verhältnis ist. Die Bewertung erfolgt vom Product Owner gemeinsam mit dem Kunden.

Wie schaut das bei einer Userstory mit 5 Story Points und 34 Value Points aus?

34/5 = 6.8 ➔ Bang-for-the-Buck-Wert

Userstory mit 13 Story Points und 8 Value Points?

21/13 = 1.6 ➔ Bang-for-the-Buck-Wert

Die erste Userstory hat zwar weniger Story Points, allerdings im Vergleich zur zweiten Userstory mehr Value Points. Somit hat die erste Userstory ein besseres Preis/Leistungsverhältnis und wird somit priorisiert.

(je höher, desto besser ist das Preis/Leistungsverhältnis)

Nach jedem Sprint wird die geschaffte Anzahl an Story Points dokumentiert und als Schätzwert für die nächsten Sprints bzw. die Dauer des Backlogs verwendet. Diese Zahl wird Velocity genannt. Damit wird die Transparenz erhöht und ein Richtwert für zukünftige Projekte ist vorhanden.

Story Points : Value Points = Bang for the Buck Wert

Teamrollen

TEAM

In Scrum gibt es, genauso wie beim Wasserfallmodell, klar definierte Rollen

Product Owner
Scrum Master
Mitglied des Entwicklerteams

Product Owner

Der Visionär in Scrum, ebenfalls Product Owner genannt, bestimmt, wie das Produkt am Ende aussehen sollen. Er pflegt den Product Backlog und sorgt regelmäßig für den aktuellen Stand der User Stories, sowie Story Points bzw. Value Points. Zusätzlich trägt er die Verantwortung gegenüber dem Kunden und repräsentiert ihn (falls der Kunde keine Zeit hat) bei der Product-Increment-Vorstellung im Sprint-Review Meeting.

Scrum Master

Der Scrum Master hat die Aufgabe, den Scrum Prozess während des Projektes zu überwachen und dafür zu sorgen, dass er eingehalten wird. Zu seinen weiteren Aufgaben zählen die Organisation/Moderation der Sprint Retrospective, sowie die Beseitigung von Hindernissen, welcher in der von ihm geführten Impediment List festgehalten werden. Bei Ressourcenproblemen ist er der Ansprechpartner und dient als Schnittstelle zu Außenstehenden.

Projektmitglied

Jedes Mitglied des Entwicklerteams darf sich seine User Stories zwar selbst aussuchen, muss diese aber auch selbst organisieren. Da viele Freiheiten mit dieser Möglichkeit vorhanden sind, haben die Mitglieder eine hohe Verantwortung und sollten aus eigener Motivation arbeiten wollen.