In den letzten Jahren hat agiles Projektmanagement in immer mehr Unternehmen Einzug gefunden. Besonders die Scrum-Methode, die ursprünglich aus der Softwareentwicklung kommt, ist in aller Munde.
Doch was genau steckt eigentlich dahinter? In diesem Artikel geben wir einen Überblick.
Was ist Scrum-Projektmanagement?
Scrum ist eine Methode des agilen Projektmanagements, mit der ein gewünschtes Produkt schrittweise fertiggestellt wird. Dadurch kann das Projektteam flexibler auf wechselnde Anforderungen reagieren, als es im klassischen Projektmanagement der Fall ist. Basis dafür sind zeitlich begrenzte Sprints (Time Box), in denen ein selbstorganisiertes Entwicklungsteam potenziell lieferbare (Teil-)Produkte entwickelt.
Der Name „Scrum” kommt ursprünglich vom Rugby und bedeutet auf Deutsch so viel wie (angeordnetes) Gedränge. Während die Aufstellung für Laien lediglich als eine Art Gewimmel zu identifizieren ist, gibt es dahinter doch einen ganz genauen Plan.
Ähnlich ist es auch mit Scrum. Was auf Außenstehende manchmal wirkt wie ein unkoordiniertes Vorgehen, folgt in Wahrheit klaren Methoden und Prozessen. Definiert und beschrieben sind diese im Scrum Guide von Ken Schwaber und Jeff Sutherland, der bereits 1995 geschrieben wurde und seitdem regelmäßig aktualisiert wird.
Kern der Scrum-Methode sind drei wesentliche Eigenschaften:
Empirisch: Die gesammelten Erfahrungen vergangener Sprints fließen in die Planung und Entwicklung des Gesamtergebnisses und weiterer Sprints mit ein.
Inkrementell: Die Entwicklung erfolgt schrittweise. Am Ende jedes Sprints steht ein funktionierendes und potenziell lieferbares (Teil-)Produkt
Iterativ: Diese entstandenen (Teil-)Produkte werden immer weiter verbessert oder erweitert, bis alle gewünschten Funktionalitäten und Verbesserungen enthalten sind.
Die Scrum-Methode basiert dabei auf verhältnismäßig wenigen Regeln, die alle im Zusammenhang mit sogenannten Aktivitäten, Artefakten und Rollen stehen.
Um sicherzustellen, dass ein Projekt während der ganzen Laufzeit an den Bedürfnissen der Kunden ausgerichtet ist, finden regelmäßig Absprachen mit Kunden und Stakeholdern statt. Dort werden (Teil-)Ergebnisse präsentiert und das anschließende Feedback ausgewertet.
Zu Beginn eines Projekts steht dabei kein klares Projektziel, sondern vielmehr eine Vision davon, was am Ende des Projekts stehen soll. Die Idee dahinter ist, das Ziel möglichst unabhängig zu machen von konkreten Anforderungen und Wünschen.
Dadurch, dass sich das Scrum Team selbst organisiert, gibt es auch keinen Projektmanager, der die Aufgaben verteilt. Stattdessen haben die Teammitglieder die Möglichkeit, sich ebenso im Prozess weiterzuentwickeln und Eigenverantwortung zu übernehmen.
Damit die Scrum-Methode funktionieren kann, braucht es eine klare Rollenverteilung. Im klassischen Scrum-Prozess sind drei Rollen vorgesehen.
Der Product Owner ist verantwortlich für das Endergebnis des Projekts und behält während des gesamten Prozesses die Vision im Blick. Er übernimmt die Verwaltung und Priorisierung der fachlichen Anforderungen. Beim Product Owner liegt außerdem die Kommunikation mit den Stakeholdern, also in den meisten Fällen dem Management, dem Kunden, sowie Nutzerinnen und Nutzern des Produkts.
Der Scrum Master hat im Scrum-Prozess eine Moderatorenrolle inne. Er fungiert als Bindeglied zwischen dem Entwicklungsteam und dem Product Owner. Der Scrum Master kümmert sich in erster Linie darum, dass der Scrum-Prozess eingehalten wird, das Team während der Sprints ungestört arbeiten kann und Hindernisse möglichst schnell beseitigt werden. Darunter fällt zum Beispiel auch die Vorbereitung und Durchführung der Meetings oder die (Scrum-)Schulung von Teammitgliedern.
Das Entwicklungsteam übernimmt die eigentliche Arbeit während der Sprints. Es organisiert sich dabei selbst. Damit ein Entwicklungsteam unabhängig arbeiten kann, ist es interdisziplinär aufgestellt. Dadurch wird sichergestellt, dass sämtliche benötigte Expertise im Team vorhanden ist und keine Personen von außen hinzugezogen werden müssen.
Zusätzlich zu den Rollen gibt es drei sogenannte Scrum Artefakte.
Das Product Backlog stellt eine Sammlung sämtlicher Anforderungen (Requirements) dar, die zur Umsetzung der Projektvision nötig sind. Diese Anforderungen sind in Form von sogenannten Epics und User Stories notiert.
Eine User Story ist eine Art Mini-Projekt, das in einem Sprint umsetzbar ist. Epics sind in der Regel größere Projekte, die nicht in einem Sprint umsetzbar sind. Sobald es an die Umsetzung geht, werden sie in mehrere User Stories aufgeteilt.
User Stories (und auch Epics) sind ausgerichtet an speziellen Anwendungsfällen im Projekt. Dabei liegt der Fokus auf dem gewünschten Ergebnis. Wie genau dieses Ergebnis erreicht wird, entscheidet das Scrum-Team.
Die Verantwortung für das Product Backlog liegt beim Product Owner. Diesem obliegt die Aufgabe, die Anforderungen zu priorisieren und das Backlog bei Bedarf um neue Anforderungen zu erweitern.
Zu Beginn eines Sprints werden von Product Owner und Entwicklungsteam aus dem Product Backlog die Anforderungen ausgewählt, die in einem Sprint umgesetzt werden können. Dabei spielt vor allem die Priorität eine Rolle, aber auch die Kapazitäten des Entwicklungsteams gehen in die Planung ein. Alle daraus resultierenden Aufgaben, die in einem Sprint umgesetzt werden sollen, bilden das Sprint Backlog.
Am Ende eines jeden Sprints steht ein funktionsfähiges (Teil-)Produkt. Dieses Ergebnis wird als Produktinkrement bezeichnet.
Aktivitäten in Scrum umfassen verschiedene Scrum-Meetings, die wir im Folgenden genau charakterisieren.
Das Planungsmeeting zu Beginn eines Sprints wird Sprint Planning genannt. Hier wird das Ziel des Sprints festgelegt und entschieden, welche Anforderungen umgesetzt werden sollen. Anschließend werden die User Stories in kleinere Tasks aufgeteilt und im Sprint Backlog erfasst.
Zu Beginn jedes Arbeitstages gibt es ein kurzes (maximal 15-minütiges) Meeting. Dort erzählt jedes Teammitglied, was es am Vortag geschafft hat, welche Aufgaben als nächstes anstehen und ob es irgendwelche Hindernisse oder Probleme gibt. Um die Lösung der Probleme, die nicht direkt im Daily Scrum geklärt werden können, kümmert sich der Scrum Master.
Zum Abschluss eines Sprints stellt das Entwicklungsteam das Ergebnis dem Product Owner und gegebenenfalls weiteren Stakeholdern vor. Es wird anhand zuvor festgelegter Kriterien (Definition of Done) überprüft, ob das Sprint-Ziel erreicht wurde. Bei Bedarf (zum Beispiel aufgrund veränderter Anforderungen oder nötiger Verbesserungen) wird das Product Backlog angepasst.
Zusätzlich zum Sprint Review wird am Ende eines Sprints in der Retrospektive der Sprint im Team ausgewertet. Der Fokus liegt dabei auf dem Scrum-Prozess selbst sowie auf der Arbeit und Aufgabenverteilung im Team.
Im Product Backlog Refinement organisiert und priorisiert der Product Owner die Epics und User Stories im Product Backlog neu.
Die Scrum-Methode ermöglicht es Projektteams, schnell und flexibel auf wechselnde Anforderungen und Probleme zu reagieren. Durch die regelmäßige Kommunikation mit den beteiligten Stakeholdern wird außerdem vermieden, dass ein Projekt am Kunden vorbei umgesetzt wird.
Agiles Projektmanagement mit Scrum kann ein guter Ansatz für Projekte sein, die sich schwer von Anfang bis Ende planen lassen und ständigen Veränderungen unterworfen sind – zum Beispiel in der Software-Entwicklung. Aber auch klassische Projektmanagement-Methoden haben ihre Berechtigung. Letztlich sollte sich die Wahl der Methode immer an den Anforderungen und Zielen ausrichten.
Treten Sie in unserer Community in Kontakt mit gleichgesinnten Vertriebs- und Marketingexperten/-expertinnen.
Der Community beitreten