ScrumSo funktioniert Scrum – Regeln, Rollen, Werkzeuge

Scrum bezeichnet eine Vorgehensweise bei Entwicklungsprojekten für das Produktmanagement und beim Projektmanagement. Der Begriff stammt aus dem Rugby, wo Scrum einen dichten Haufen von Spielern meint, die sich um das Spielgerät scharen (deutsch: Gedränge). Dieses Bild wird auf das Projektmanagement übertragen.

Scrum soll ausdrücken, worum es beim Projektmanagement vor allem gehen soll:

• Flexibilität
• Dynamik und
• tägliche Meetings, in denen die Projektmitarbeiter ihre Aufgaben abstimmen.

Ursprünglich war Scrum ein Vorgehensmodell bei der Softwareentwicklung. Die Vorgehensweise und die damit verbundenen Methoden und Werkzeuge wurden auf andere Entwicklungsprojekte und allgemein auf das Projektmanagement übertragen. Daraus entwickelte sich der Begriff agiles Projektmanagement als Abgrenzung zum klassischen Projektmanagement.

Scrum ist eine besondere Philosophie und Vorgehensweise im Projektmanagement. Es wurde entwickelt, weil die Methoden und Werkzeuge im klassischen Projektmanagement nicht immer den gewünschten Erfolg zeigen. Letztlich werden mit Scrum und agilem Projektmanagement aber die gleichen Ziele verfolgt:

• Ergebnisse eines Projekts sollen den gewünschten Anforderungen entsprechen.
• Budgets sollen eingehalten werden.
• Die Ergebnisse sollen zu einem festgelegten Zeitpunkt vorliegen.

Diese generellen Projektziele werden mit Scrum ohne großen Planungsaufwand erreicht. Das spart Zeit und Geld. Dazu sollen die Projektteams flexibler, schneller und pragmatischer im Projekt arbeiten. Sie sollen agil sein.

Der Kerngedanke von Scrum und agilem Projektmanagement ist:

„Wenn alle ausgefeilten Methoden, Werkzeuge und Vorgehensweisen im klassischen Projektmanagement nicht zu den erwünschten Erfolgen führen, dann lasst das doch einfach sein. Vertraut darauf, dass ein erfahrenes Projektteam es schon schaukeln wird, wenn es die Freiheiten dazu hat.“

Wichtig ist, dass die Projektbeteiligten sich regelmäßig treffen und besprechen. Außerdem bekommen sie einfache Methoden und Werkzeuge an die Hand, die sie beim Projektverlauf unterstützen. Die Mitarbeiterinnen und Mitarbeiter im Projekt und die Produktentwickler sollen außerdem direkt mit den Kunden, den Anwendern und den Auftraggebern des Projekts sprechen.

Schon vor über dreißig Jahren wurden erste Erfahrungen mit dieser Form des Projektmanagements gemacht. Es ging zunächst darum, Produkte schneller und kundenorientierter zu entwickeln. Dabei sollte helfen: weniger Bürokratie und Planung und stattdessen engere Zusammenarbeit und häufigere Abstimmungen zwischen den Mitarbeitenden im Produktentwicklungsteam und im Projektteam.

Ganz ohne Regeln kommen Scrum und agiles Projektmanagement auch nicht aus. Doch es sollen sehr wenige und sehr einfache Regeln sein. Entscheidend ist, dass das Projektteam die gemeinsamen Ziele erreicht.

Das soll so erfolgen, dass ein Team beim agilen Projektmanagement sich selbst organisieren kann – und auch darf. Außerdem soll es interdisziplinär zusammengesetzt sein. Es gelten folgende Regeln und Prinzipien:

Zerlegung

Die Aufgabe und das Projekt werden in einzelne, gut überprüfbare Teile zerlegt. Das sind einzelne Arbeitspakete oder Module des Produkts, das entwickelt werden soll.

Transparenz

Die Projektmitarbeiter und Entwickler treffen sich jeden Tag und besprechen ihren Fortschritt und die Hindernisse oder Probleme. Die Ergebnisse werden für alle sichtbar festgehalten.

Überprüfung

In regelmäßigen Abständen werden Produktfunktionalitäten, Module oder Lösungen der jeweiligen Teilaufgaben oder Arbeitspakete geliefert und beurteilt.

Anpassung

Die Anforderungen an das Produkt oder Teilziele für das Projekt werden nicht fix festgelegt, sondern nach jeder Lieferung neu bewertet und bei Bedarf angepasst.

Wichtig sind außerdem die Rollen, die Akteure einnehmen müssen. Scrum sieht drei Rollen vor, die besetzt sein müssen:

• Produkteigner (Product Owner)
• Scrum-Master (Project Master)
• Mitglied im Projektteam oder Entwicklungsteam (Projektmitarbeiter oder Entwickler)

Alle Personen, die eine dieser Rollen einnehmen, bilden zusammen das Scrum-Team für dieses Projekt oder für die Entwicklung des Produkts. Sie haben unterschiedliche Aufgaben und Verantwortungen.

Produkteigner (Product Owner)

Der Produkteigner vertritt die Anwender des Produkts, den Auftraggeber oder die Stakeholder des Projekts. Das können alle Personen sein, die betroffen sind und ein Interesse am Erfolg des Projekts haben. Bei Scrum wird vom Customer oder User gesprochen. Sie benötigen die Projektergebnisse und das Produkt und haben dazu Anforderungen. Diese beschreiben Sie bei Scrum in Form von User Storys.

Wenn eine neue Software oder IT-Lösung im Unternehmen eingeführt wird, sind die Anwender oder Nutzer betroffen, denn sie wollen reibungslos mit ihren Programmen arbeiten. Bei Produkten sind es die Produktmanager, die Vertriebsmitarbeiter oder der Kundendienst, die als Stimme der Kunden auftreten.

Sie müssen wissen, was die Kunden erwarten und was sie besonders schätzen. Dies geben als Anforderung an den Produkteigner weiter. In einem Projekt sind die Kolleginnen und Kollegen, die mit den Projektergebnissen arbeiten oder etwas verändern sollen, auch so etwas wie Anwender, Kunden oder Stakeholder des Projekts.

Der Product Owner sammelt die Anforderungen und User Storys der Anwender und Kunden und erstellt daraus das Product Backlog. Dort sind alle Aufgaben und die Anforderungen an die zu entwickelnden Produkte aufgelistet. Der Product Owner muss dazu:

• Product-Backlog‐Einträge klar formulieren;
• die Einträge im Product Backlog so sortieren, dass Ziele erreicht werden;
• sicherstellen, dass das Product Backlog sichtbar, transparent und für alle klar ist;
• zeigen, woran das Scrum-Team als Nächstes arbeiten wird;
• sicherstellen, dass das Entwicklungsteam die Product-Backlog‐Einträge richtig versteht.

Scrum-Master (Project Master)

Der Scrum-Master ist vor allem Moderator und Dienstleister für das Projekt- oder Entwicklerteam. Er sorgt dafür, dass Hindernisse im Umfeld des Teams beseitigt werden. Er beschafft die notwendigen Ressourcen und ist Ansprechpartner für Außenstehende. Er hilft dem Team bei methodischen Problemen und stellt sicher, dass die Regeln des agilen Projektmanagements eingehalten werden.

Die Aufgaben des Scrum-Master sind insofern vielfältig, als er den Product Owner und das Entwicklerteam unterstützen muss und außerdem Scrum im Unternehmen verankert und vorantreibt. Der Scrum-Master muss dazu insbesondere:

• Techniken für die Verwaltung des Product Backlogs vermitteln und zeigen, wie die Einträge im Product Backlog verständlich und prägnant formuliert werden;
• den Product Owner bei der Sortierung der Einträge im Product Backlog unterstützen, damit die Bedeutung und die Prioritäten beachtet werden;
• das Entwicklungsteam so coachen und unterstützen, dass es sich selbst organisiert und funktionsübergreifend zusammenarbeitet;
• Hindernisse, die das Entwicklungsteam aufhalten, beseitigen;
• das Denken und Handeln nach den Regeln und Prinzipien des agilen Projektmanagements im Unternehmen, bei den Stakeholdern und Auftraggebern, beim Product Owner und beim Entwicklungsteam fördern;
• Scrum-Projekte initiieren und vorantreiben.

Projektteam oder Entwicklungsteam

Das Projektteam oder Entwicklungsteam besteht aus den Fachleuten, die es braucht, um die Projektaufgabe zu lösen oder das Produkt zu entwickeln. Sie müssen den Projektauftrag erledigen – auf der Grundlage ihres Wissens, ihres Know-hows und ihrer Erfahrungen.

Regeln für die Zusammenstellung eines Scrum-Teams:

• Das Projektteam sollte zwischen drei und neun Mitarbeiterinnen und Mitarbeiter umfassen.
• Sie organisieren alle Aufgaben selbst.
• Es gibt im Team keine Hierarchie.
• Jeder hat dieselben Rechte und Pflichten, aber unterschiedliche Kompetenzen und Aufgaben.
• Alle Fachbereiche, die zur Lösung beitragen, sollten vertreten sein.

Wichtig ist zudem, dass alle Teammitglieder freiwillig dabei sind. Sie sollten sich ihre Projekte und die Aufgaben darin selbst aussuchen können. Das setzt Vertrauen des Managements und Verantwortungsbewusstsein aller Teammitglieder voraus. Die Mitarbeiterinnen und Mitarbeiter im Team sollten die Kompetenzen mitbringen, die für das Projekt und das gewünschte Projektergebnis gebraucht werden.

Oft müssen Kompetenzen und Know-how zusammengeführt werden, die sehr unterschiedlich sind und nicht immer zusammenpassen. Es kann zu Konflikten kommen, weil Projektmitglieder aufgrund ihrer Persönlichkeit oder ihres fachlichen Hintergrunds andere Wahrnehmungen, Lösungsansätze oder Priorisierungen haben. Die wesentlichen Merkmale des Teams sind:

• Das Team organisiert sich selbst.
• Es ist interdisziplinär.
• Es gibt keine Titel oder Hierarchien; alle heißen „Entwickler“ oder „Projektmitglied“.
• Es gibt keine Untergruppen im Team.
• Das Team ist immer als Ganzes rechenschaftspflichtig.

Im Rahmen von Scrum werden oft Begriffe verwendet, die spezielle Artefakte (Elemente) oder Werkzeuge bezeichnen. Sie sind dazu da, um für das Scrum-Team maximale Transparenz und minimalen Verwaltungsaufwand zu gewährleisten. Sie helfen also, alle Informationen übersichtlich, einfach und verständlich zu vermitteln. Und sie helfen bei der Zusammenarbeit und Abstimmung im Scrum-Team.

User Storys und Story Cards

Die Nutzer (User) oder Kunden (Customer) schreiben in ihren Worten die Anforderungen, Wünsche oder Ziele an das Produkt oder die zu entwickelnde Lösung als ihre User Story auf Story Cards.

Product Backlog

Liste oder Sammlung aller Aufgaben, Funktionen und Merkmale des Produkts oder der Lösung, die aus den Story Cards abgeleitet werden. Sie können wie ein Use Case beschrieben werden.

Backlog-Item

Die einzelne Aufgabe, Funktion oder das einzelne Merkmal im Product Backlog.

Story Points

Wenn die zunächst groben Anforderungen der Nutzer oder Kunden durch den Product Owner geklärt sind, muss das Projektteam abschätzen, wie komplex eine Aufgabe, Funktion oder Merkmal ist. Daraus leitet sich der Aufwand für die Realisierung ab. Diese Schätzung wird in sogenannten Story Points ausgedrückt. Wie viele Stunden Entwicklungsaufwand mit einem Story Point verbunden sind, ergibt sich aus der Erfahrung oder aus dem Projektverlauf.

Things-That-Matter-Matrix

Tabelle, die Beziehungen zwischen Anforderungen der User oder Customer einerseits und den Backlog-Items andererseits darstellt.

Definition of Done

Im Vorfeld muss sich das Scrum-Team darüber verständigen, wann ein Projekt- oder Entwicklungsergebnis als „fertig“ oder „erledigt“ bezeichnet werden kann. Dazu werden Indikatoren, Funktionen oder Tests benannt, die nach der Entwicklung des Ergebnisses durchgeführt werden und bestätigen, dass es funktioniert.

Sprint

Einzelner Arbeitszyklus (Teilschritt oder Phase) im Projekt, in dem jeder Projektmitarbeiter die von ihm ausgewählte Teilaufgabe (Sprint-Task) bearbeitet und eine fertige Lösung für diesen Task liefert.

Time Box

Für einen Sprint wird eine feste Zeitdauer vorgegeben, die nicht überschritten werden darf. Dieser Zeitrahmen wird als Time Box bezeichnet. Er beträgt meistens zwischen einer und vier Wochen.

Sprint-Task (Ticket)

Teilaufgabe, die von einem Projektmitarbeiter bearbeitet wird und deren Ergebnis ein Baustein (Teillösung, Funktion, Feature) für das Produkt oder das Gesamtprojekt ist.

Sprint-Backlog

Liste aller Sprint-Tasks; Maßnahmenplan für den nächsten Sprint.

Sprint-Taskboard

Eine Art Plantafel oder Tabelle, auf der alle Teilaufgaben eines Sprints aufgeführt sind. Sie ist für alle Projektmitarbeiter jederzeit sichtbar. Die Teilaufgaben werden dort nach Bearbeitungsstand sortiert.

Daily Scrum

Tägliches Zusammenkommen aller Mitarbeiterinnen und Mitarbeiter im Scrum-Team, um den Arbeitsfortschritt zu besprechen.

Impediment Backlog

Liste aller Probleme und Hindernisse, die während eines Sprints aufgetaucht sind und die beseitigt werden müssen.

Burn-Down-Chart

Grafik oder Diagramm, das den Verbrauch der Ressourcen darstellt, indem der geplante Aufwand dem tatsächlichen Aufwand gegenübergestellt wird. Es gibt ein Burn-Down-Chart für die Budgetüberwachung in einem Scrum-Zyklus sowie ein Burn-Down-Chart für das Gesamtprojekt; für das Gesamtprojekt wird gelegentlich auch ein Burn-Up-Chart verwendet.

Sprint-Review-Meeting

Nach einem Sprint stellen die Projektmitarbeiter ihre Lösungen des Sprints dem Produkteigner und den Kunden und Nutzern vor. Diese müssen die Lösung abnehmen und akzeptieren, wenn das gewünschte Ergebnis erzielt ist. Ansonsten wird nachgearbeitet.

Product Increment

Ein Teilprodukt oder Teilergebnis, das im Rahmen eines Sprints entwickelt oder erzielt wird, ist ein Product Increment. Es ist insoweit vollständig, als es vom Anwender und Product Owner geprüft und abgenommen werden kann.

Velocity

Ist die Geschwindigkeit, mit der das Projekt- und Entwicklerteam in den Sprints vorankommt. Sie zeigt, welche Arbeitsmenge geschafft und wie viele Story Points in den einzelnen Sprints erfüllt oder erledigt werden. Dies ist im Velocity-Chart visualisiert.

Sprint-Retrospective

In dieser gesonderten Besprechung wird die Zusammenarbeit während eines Sprints beleuchtet. Probleme werden angesprochen und Lösungen für die Prozessverbesserung werden gesucht.