Scrum

Scrum ist ein einfaches Framework zur Lösung komplexer Probleme, wie z.B. Produkt- und Software-Entwicklungen. Das Framework umfasst drei Rollen, drei Artefakte und fünf Zeremonien, insgesamt also elf Bestandteile und ist somit eines der schlanksten Prozess-Frameworks. Scrum baut auf dem Agile Manifesto und den entsprechenden Prinzipien auf.

 

Scrum Framework

 

Die einzelnen Bestandteile werden weiter unten ausführlicher beschrieben. Zuvor aber ein paar Worte zum Fundament von Scrum.

 

Empirische Prozesskontrolle

Scrum baut auf empirischer Prozesskontrolle auf: Transparenz – Inspektion – Adaption
  • Es wird Transparenz über den aktuellen Zustand  geschaffen
  • Davon ausgehend wird eine Situation untersucht (Inspektion)
  • Aufgrund der Ergebnisse dieser Inspektion wird das weitere Vorgehen angepasst (Adaption)
Scrum weist also einen geschlossenen Lernzyklus auf. Dieser macht das Framework sehr mächtig, da konsequent und in sinnvollen Zyklen Transparenz über eine aktuelle Situation geschaffen und das weitere Vorgehen darauf aufbauend angepasst wird. Somit kann rasch auf veränderte Gegebenheiten reagiert werden.
Die feste Kadenz ist sehr wichtig: Die Kadenz reduziert die Komplexität in der sich das Team bewegt und fördert die Transparenz, da immer das gleich grosse Zeitfenster betrachtet wird.

 

Scrum-Werte

Neben der Basis der empirischen Prozesskontrolle baut Scrum auf fünf Werten auf:
Scrum Values
Diese Werte sind wichtig, da sie letztendlich das gegenseitige Vertrauen im Scrum-Team fördern. Vertrauen ist entscheidend für den Erfolg eines Teams.

 

Bestandteile von Scrum

Rollen

Scrum Master

Die Aufgabe des Scrum Masters ist es, das Befolgen der Scrum-Regeln zu fördern. Dabei arbeitet der Scrum Master eng mit dem Team und der Organisation zusammen. Insbesondere ist er/sie auch für das Entfernen von Hindernissen (Impediments) des Teams in der Organisation zuständig.

 

Product Owner

Die Rolle des Product Owners wird, wie jene des Scrum Masters, von einer Person besetzt. Seine/ihre Aufgabe ist es, mit den Stakeholdern und Team zusammenzuarbeiten, um das Product Backlog aktuell und auf die Produktvision ausgerichtet zu halten.

Die Priorisierung der Arbeit im Product Backlog ist einzig die Aufgabe des Product Owners. Ziel der Priorisierung ist, durch den Einsatz des Teams möglichst viel Wert zu schaffen.

 

Entwicklungsteam

Das Entwicklungsteams (oder kurz: Teams) setzt sich aus 3-9 Personen zusammen. Dabei sind alle Disziplinen im Team vertreten, die benötigt werden, um aus einem Backlogitem ein Produktinkrement zu schaffen. In Scrum werden Teams etabliert, die über mehrere Sprints stabil bleiben.

Aufgabe des Teams ist es, innerhalb eines Sprints entlang der Prioritäten des Product Owners ein Produktinkrement zu schaffen. Dabei müssen die erledigten Arbeiten der „Definition of Done“ genügen, damit von einer einheitlichen Qualität der erledigten Arbeiten ausgegangen werden kann.

Wichtig ist, dass ein Produktinkrement eine Release fähige Qualität aufweist (d.h. zum Beispiel auch getestet und in das Gesamtsystem integriert wurde). Dies ist notwendig, damit die für die empirische Prozesskontrolle notwendige Transparenz entstehen kann.

Selbstorganisation ist ein wichtiges Prinzip von Scrum. Deshalb ist es auch die Aufgabe des Entwicklungsteams, die eigenen Hindernisse innerhalb des Teams selbst zu lösen.

 

Artefakte

Product Backlog

Das Product Backlog ist eine priorisierte Liste an Arbeit für die Entwicklung eines Produktes. Es ist die „Single Source“ für Arbeit des Teams. Darin liegt der grosse Wert des Product Backlogs: Alle Arbeit des Teams ist an einem Ort festgehalten und transparent.

Ein Product Backlog ist ein lebendiges Artefakt, d.h. die enthaltenen Items werden konstant verfeinert, repriorisiert, entfernt oder neue Items werden ins Backlog aufgenommen.

 

Sprint Backlog

Während des Sprint-Planning entscheidet das Team, in Rücksprache mit dem Product Owner, welche Items aus dem Product Backlog im nächsten Sprint bearbeitet werden. Diese Items werden im Sprint Backlog dargestellt und kontinuierlich abgearbeitet. Wie die Lösungsfindung erfolgt liegt im Ermessen des selbst-organisierten Teams.

 

Produktinkrement

Ziel eines Sprints ist die Erschaffung eines Produktinkrements. Dieses sollte eine „releasefähige“ Qualität aufweisen, d.h. spätestens nach dem Sprint Review auf Entscheid des Product Owners hin für den Markt freigegeben werden können.

Dieser Grad an Qualität ist notwendig, um spätere, unvorhersehbare Nacharbeiten zu vermeiden. So ist der Zustand des Produktes jederzeit transparent, was notwendig ist für den Erfolg der empirischen Prozesskontrolle (und somit des Teams).

 

Zeremonien

Sprint

Ein Sprint ist die Kadenz, in der das Scrum-Team plant und arbeitet. Dabei ist ein Sprint höchstens vier Wochen lang, wobei eine kürzere Dauer bevorzugt wird. Unmittelbar nach Ende eines Sprints folgt der Beginn des folgenden Sprints.

 

Sprint-Planung

Die Sprint-Planung dient dazu, einen Forecast über die Arbeiten des kommenden Sprints zu machen. Dabei arbeitet das Team eng mit dem Product Owner, um die höchst priorisierten Items zu identifizieren und danach deren Lösung zu planen. Eine Sprint-Planung dauert maximal 8 Stunden bei einem 4-wöchigen Sprint (bei kürzeren Sprints entsprechend kürzer).

Während der Sprint-Planung wird das Sprint-Ziel festgelegt. Dieses gibt dem Team während dem Sprint Flexibilität in der Lösungsfindung, und gleichzeitig Sicherheit in Form von Leitplanken vor.

 

Sprint-Review

Am Sprint-Review wird das während dem Sprint erstellte Produktinkrement vom Team, Product Owner und Stakeholdern untersucht bzw. inspiziert. Insofern spielt der Sprint-Review eine wichtige Rolle in der empirischen Prozesskontrolle. Das Ergebnis der Inspektion wird im Backlog und/oder der nächsten Sprint-Planung berücksichtigt. Die Timebox für den Sprint-Review ist 4h für einen 4-Wochen-Sprint (entsprechend kürzer bei kürzeren Sprints).

 

Sprint-Retrospektive

An der Sprint-Retrospektive wird die Zusammenarbeit des Teams untersucht und notwendige Anpassungen identifiziert. Dabei arbeitet das Team eng mit Product Owner und Scrum Master zusammen. Beispielsweise identifiziert das Team Anpassungsbedarf bei der „Definition of Done“, um die Produktqualität weiter zu steigern.

Die Timebox der Sprint-Retrospektive ist 3h für einen 4-wöchigen Sprint (entsprechend kürzer bei kürzeren Sprints).

 

Daily Scrum

Der Daily Scrum dient der Förderung der Transparenz während eines Sprints. Es handelt sich um ein tägliches Treffen des Teams mit einer Timebox von 15 Minuten. Diese Zeit nutzt das Team um sich über den Stand der Arbeiten im Hinblick auf das Erreichen des Sprint-Ziels zu informieren und allfällige Hindernisse zu identifizieren.

 

Unterstützende Elemente

Zusätzlich zu diesen im Scrum-Guide beschriebenen Elementen können folgende Elemente und Praktiken bei der Verwendung von Scrum hilfreich sein:
  • User Stories
  • Visualisierung von Arbeit
  • XP Praktiken
  • Test Driven Development

Autor

Ari Byland, Managing Partner FlowSphere

Ari Byland ist Professional Scrum Trainer (PST) bei Scrum.org und SAFe Program Consultant (SPC 4). Er unterstützt seit mehreren Jahren Unternehmen und Scrum-Teams in ihrer Scrum Anwendung.

Fragen Sie ihn für eine unverbindliche Info-Session zu Scrum an.

 

 

 

Unsere Scrum-Trainings