Scrum kompakt erklärt: Methode, Rollen, Events und Artefakte

Was ist Scrum?

Vor dem Produkt- und Projektmanagement mit Scrum dominierten sogenannte Wasserfall-Modelle. Projekte wurden zu Beginn detailliert geplant und die entsprechenden Aufgaben dann planmäßig abgearbeitet. Raum für neue Erkenntnisse oder sich ändernde Umstände während des Entwicklungsprozesses gibt es bei diesem Vorgehen kaum.

‍

Scrum entstand als Gegenentwurf zu solch starren Vorgehensmodellen. Gerade in der Digitalbranche und Softwareentwicklung ändern sich Umstände, Technologien und Nutzerverhalten rasant. Gleichzeitig ist es möglich, durch die Auswertung von Nutzerdaten und Tests mittels Prototypen frühzeitig Feedback zu sammeln und diese Erkenntnisse mit in die Produktentwicklung einfließen zu lassen. 

‍

Scrum setzt nicht auf detaillierte Vorabplanung, sondern schafft einen Rahmen für regelmäßigen Austausch und Iterationen gemäß dem Leitsatz: Wir wissen am Anfang nicht, was die richtige Lösung ist. Komplexe Projekte werden deshalb auf einzelne Teilaufgaben heruntergebrochen. Diese Teilaufgaben gilt es in kurzen Sprints von 1 bis 4 Wochen zu erledigen. Sollten sich dabei neue Erkenntnisse ergeben, wird die weitere Planung angepasst und der nächste Sprint entsprechend neu ausgerichtet. 

Rollen und Aufbau von Scrum Teams

Scrum ist demnach kein Rezept, das einen detaillierten Ablaufplan vorgibt. Vielmehr handelt es sich bei der Scrum Methode um einen Rahmen. Dieser zielt nicht darauf ab, jede Handlung im Voraus festzulegen, sondern eine Umgebung zu schaffen, in der Teams selbständig und verantwortungsvoll arbeiten können. Wie dieser Rahmen gefüllt wird, entscheiden Teams selbst. 

‍

Damit diese Rahmenbedingungen jederzeit gewährleistet sind, definiert das Scrum Framework einige feste Rollen und Werkzeuge. Wichtig dabei: Die Rollen in Scrum sind nicht hierarchisch gemeint, sondern funktional. Die Rolle definiert somit keine Position in der Unternehmenshierarchie, sondern lediglich einen Verantwortungsbereich. 

‍

Scrum Master: Verantwortung für den Prozess

Der Scrum Master ist so etwas wie der Coach oder Moderator im Team. Er ist dafür verantwortlich, dass alle Regeln eingehalten werden und schafft ein Umfeld, in dem das Team selbstorganisiert und kontinuierlich besser arbeiten kann. Dazu gehört auch, dass er Hindernisse beseitigt und dafür sorgt, dass Meetings sinnvoll ablaufen. 

‍

Beispiel: Das Management des Unternehmens möchte dem Team kurzfristig zusätzliche Aufgaben geben. Der Scrum Master erklärt die Auswirkungen auf den Sprint und schützt das Team vor ungeplanten Eingriffen.

‍

Product Owner: Verantwortung für den Wert

Der Product Owner verantwortet, dass die Features und Produkte priorisiert werden, die den größtmöglichen Wert für die Organisation und den Kunden liefern. Sein zentrales Werkzeug ist das Product Backlog. Dabei handelt es sich um eine priorisierte, fortlaufend gepflegte Liste aller Anforderungen, Funktionen und Verbesserungen für ein Produkt. 

‍

Beispiel: In einem Gespräch mit Stakeholdern lehnt er eine gewünschte Funktion ab, weil sie keinen ausreichenden Nutzen bringt. Seine Entscheidung begründet er mit Daten aus einer aktuellen Nutzerbefragung. 

‍

Development: Verantwortung für die Umsetzung

Das Entwicklungsteam, oft auch als Development oder Product Engineering bezeichnet, ist für die konkrete Umsetzung der Aufgaben verantwortlich. Es entscheidet selbst, wie die Arbeit organisiert wird und wie die technischen Lösungen aussehen. Das Team teilt im Sprint Planning die Aufgaben untereinander auf und legt gemeinsam fest, wer welche Teile übernimmt.

‍

Beispiel: Während des Sprints entdeckt das Team einen Qualitätsmangel und entscheidet selbstständig, zusätzliche Tests einzubauen, auch wenn das mehr Aufwand bedeutet.

‍

Artefakte und Werkzeuge

Neben den genannten Rollen stellt das Scrum Framework verschiedene Werkzeuge zur Verfügung. Diese werden im Scrum auch als Artefakte bezeichnet und dienen dazu, Arbeit transparent zu machen, über Fortschritte zu informieren und eine gemeinsame Grundlage für Planung und Abstimmung zu schaffen.

‍

Product Backlog

Dabei handelt es sich um eine priorisierte Liste aller Anforderungen an ein Produkt. Ziel ist es, dass die Priorisierung, der aktuelle Stand und Ziele für alle Beteiligten jederzeit transparent sind. Verantwortlich für die Pflege ist der Product Owner. In seinen Aufgabenbereich fällt auch das sogenannte Refinement, also das Vorbereiten und Anpassen der Aufgaben im Team für künftige Sprints. 

‍

Einzelne Aufgaben werden als User Stories formuliert, also als einfache Anforderungen aus der Sicht von Nutzer:innen. Jede User Story verfügt über Akzeptanzkriterien, die erfüllt sein müssen, damit eine Anforderung als abgeschlossen gilt. Entsprechend dem Aufwand erhält zudem jede User Story eine bestimmte Menge an Story Points.

‍

Sprint Backlog

Das Sprint Backlog umfasst diejenigen Aufgaben, die innerhalb des aktuellen Sprints umgesetzt werden sollen. Welche Aufgaben das sind, wird im Rahmen des Sprint Plannings im Team ausgehandelt. 

‍

Inkrement

Das Inkrement ist das fertiggestellte Endergebnis eines Sprints. Es handelt sich um ein funktionierendes Teilstück des Endprodukts und macht die Arbeit damit überprüfbar. Typisches Beispiel für ein solches Teilergebnis ist eine voll funktionsfähige Registrierungsseite mit Anmeldung und korrekter Speicherung der Daten. 

‍

Scrum Board

Backlog und Inkrement sind offizielle Artefakte im Scrum Guide. Daneben haben sich jedoch weitere Werkzeuge etabliert, die Scrum Teams häufig nutzen. Zu den bekanntesten zählt das Scrum Board, auch als Taskboard bezeichnet. 

Es zeigt den Arbeitsstand des aktuellen Sprints und besteht aus drei Spalten: To Do, In Progress und Done. In diese drei Spalten werden dann Karten mit User Stories eingeordnet. So bekommt jeder im Team einen transparenten Überblick über den aktuellen Arbeitsstand. 

‍

Burndown Chart

Das Burndown Chart ist ein Diagramm, das zeigt, wie viel Arbeit bis zum Ende des Sprints noch zu erledigen ist. So zeigt die X-Achse die noch verfügbare Zeit, die Y-Achse die noch zu erledigende Restarbeit, beispielsweise in Story Points. 

‍

Scrum Events

Eine dritte Kategorie neben Rollen und Artefakten innerhalb der Scrum Methode sind Events. Diese definieren regelmäßig stattfindende Meetings. Sie dienen zur Abstimmung, Transparenz und Strukturierung von Aufgaben. Dabei lassen sich folgende Scrum Events unterscheiden:

‍

• Sprint: Der Sprint ist der feste Arbeitszyklus von 1 bis 4 Wochen. Innerhalb dieser Zeit gilt es, die vereinbarten Aufgaben in Form von User Stories zu erledigen und am Ende ein funktionsfähiges Inkrement zu liefern, also eine Teilfunktion des Gesamtprojekts.
• Sprint Planning: Dabei handelt es sich um ein Event zu Beginn eines jeden Sprints. Darin werden Ziele definiert und festgelegt, welche Backlog-Einträge umgesetzt werden sollen. 
• Daily Scrum: Oft auch einfach als Daily bezeichnet, handelt es sich hierbei um ein tägliches Meeting von maximal 15 Minuten, in dem die nächsten 24 Stunden geplant werden. Als visuelle Unterstützung dient hier das Scrum Board. 
• Sprint Review: Dieses findet am Ende des Sprints statt und dient dazu, Ergebnisse zu bewerten und Feedback von Stakeholdern einzuholen. ‍
• Retrospektive: Nach dem Review findet zusätzlich noch ein weiteres Event statt. Innerhalb von maximal 3 Stunden geht es darum, die Zusammenarbeit zu reflektieren und Verbesserungspotenziale abzuleiten.

Agiles Arbeiten: Scrum vs. Kanban

Ein weiteres bekanntes Framework im Produkt- und Projektmanagement ist Kanban. Wie bei Scrum auch handelt es sich um eine Methode agilen Arbeitens. Beide bilden somit einen Gegenentwurf zu starren Wasserfall-Modellen und fokussieren stattdessen Transparenz, Iterationen und kontinuierliches Lernen. 

‍

Eine weitere Gemeinsamkeit ist, dass sowohl Scrum als auch Kanban oft Boards und Karten zur Visualisierung des Arbeitsfortschritts nutzen. Wohl auch deshalb werden sie häufig in einen Topf geworfen. Bei genauerer Betrachtung handelt es sich jedoch um Frameworks, die sich deutlich unterscheiden. 

‍

Kanban beispielsweise verzichtet auf feste Arbeitszyklen in Form von Sprints. Es ist darauf ausgelegt, die Planung jederzeit anzupassen. Somit gibt es auch keine festen Planungspunkte, wie sie durch Events im Scrum vorgegeben werden. Dabei lassen sich beide Methoden durchaus auch kombinieren. 

‍

Arbeiten in Scrum: Zertifizierung und Voraussetzungen

Grundsätzlich sind für die Arbeit in Scrum keine formalen Zertifizierungen verpflichtend. Dennoch spielen sie eine wichtige Rolle, insbesondere für Rollen wie Product Owner oder Scrum Master. Gegenüber potenziellen Arbeitgeber:innen lässt sich so nachweisen, dass Bewerber:innen über entsprechendes Grundlagenwissen verfügen. 

‍

Als AZAV-zertifizierter Bildungsträger bietet unsere Digitale Leute School eine anerkannte Weiterbildung für Product Owner und Product Manager. Unsere Kurse sind dabei methodologisch offen. Das bedeutet, dass wir nicht nur Scrum, sondern auch Kanban und andere Formen agilen Arbeitens in unsere Lerninhalte einfließen lassen. Damit stellen sich Absolvent:innen breit am Arbeitsmarkt auf und ebnen ihren Weg für den Einstieg in die Tech-Branche.