Wie funktioniert eigentlich Scrum?
Jan 01 1970

Wie funktioniert eigentlich Scrum?

Scrum - Was ist das und wie funktionierts?

Die Mehrheit der Unternehmen in Deutschland setzt inzwischen auf agile Methoden. 9 von 10 verwenden dabei Scrum. Der Grund dafür? Scrum ermöglicht es, die Arbeit in einem Team so effizient zu koordinieren, dass auch komplexe Produkte innerhalb kürzester Zeit entwickelt werden können. Im Gegensatz zu anderen klassischen Projektmanagementmethoden ist es allerdings darauf ausgerichtet, dass der Kunde nicht erst am Ende sieht, wie sich das Produkt entwickelt hat: Auch im Verlauf des Entwicklungsprozesses kann der Kunde mitbestimmen und auch neue Kenntnisse rund um Zielgruppen und notwendige Funktionen jederzeit einbringen. Und genau das macht die Extraportion Flexibilität aus, die es Scrum Teams ermöglicht, das optimale Produkt für jeden Kunden zu entwickeln.

Wie das in der Praxis aussieht? Wir haben die wichtigsten Informationen rund um Aufgaben und Abläufe im Scrum Team für Sie zusammengestellt.

Was ist Scrum?

Ursprünglich stammt Scrum aus der Softwareentwicklung, doch inzwischen findet diese Methode auch in vielen anderen Bereichen Anwendung. Sie gilt als agil, weil sie den Projektverlauf nicht strikt vorschreibt, sondern dem Expertenteam ausreichend Freiräume gibt, um sich immer wieder neu auf das Projekt einzustellen und so kontinuierliche Prozessoptimierung zu betreiben.

Hierfür nutzt Scrum neben der Selbstorganisation des Teams vor allem Feedback-Loops. Indem es seine Fortschritte im Projektverlaufs regelmäßig evaluiert, kann das Team Erfolge und Misserfolge frühzeitig identifizieren und das so gewonnene Wissen in den weiteren Verlauf einfließen lassen.

Wie funktioniert Scrum?

Wörtlich aus dem Englischen übersetzt, bedeutet „scrum“ so viel wie „Gedränge“ – und genau so funktioniert die Methode auch: Sowohl in der zeitlichen Abfolge als auch in der Organisationsstruktur arbeiten alle eng Beteiligten zusammen, sodass innerhalb kürzester Zeit das bestmögliche Ergebnis entstehen kann.

Vision und Product Backlog

Scrum - Vision und Product Backlog

Um ein mit solcher Intensität durchgeführtes Projekt auf Kurs zu halten, ist gründliche Vorbereitung unerlässlich. Am Anfang eines Scrum-Prozesses steht daher stets die sogenannte Vision: Was soll das das fertige Produkt leisten, welchen Bedürfnissen und Ansprüchen des Kunden muss es gerecht werden? Auf Grundlage dieser Vision entwickelt der Product Owner dann das sogenannte Product Backlog. Dabei handelt es sich um eine Art von Produktskizze, die eine umfassende Liste der notwendigen Eigenschaften und Funktionen enthält, mit denen das Produkt ausgestattet werden soll.

Auch das Product Backlog ist im ständigen Wandel: Zu Beginn eines Sprints muss es nicht vollständig definiert sein, sondern nur so viele Punkte umfassen, dass die Entwickler mit der Arbeit am Projekt beginnen kann. Ergeben sich im Verlauf des Sprints Änderungen, können diese jederzeit ins Product Backlog aufgenommen werden.

Sprints und Daily Scrum

Sprints und Daily mit Scrum

Ist das Ziel klar konturiert, kann die eigentliche Projektarbeit beginnen. Diese gliedert sich bei Scrum in sogenannte Sprints. Ein Sprint dauert typischerweise 1-4 Wochen und ist auf ein Etappenziel in der Produktentwicklung ausgerichtet. Jeder dieser Sprints wird mit dem ganzen Team zusammen geplant. Dabei wird das Sprint-Ziel bestimmt, der Aufwand abgeschätzt und geprüft, ob sich in diesem Sprint vielleicht noch weitere Etappenziele aus dem Product Backlog umsetzen lassen. Am Ende eines Sprints steht stets ein sogenanntes Increment, ein Teilergebnis, das für sich genommen bereits funktional wäre.

Den Rahmen für die Arbeit im Sprint bildet dabei das sogenannte Sprint Backlog. Darin enthalten sind alle Funktionen, die im Verlauf des jeweiligen Sprints umgesetzt werden sollen. Sie wandern also aus dem Product Backlog in das von den Entwicklern selbst verwaltete Sprint Backlog. Diese Trennung stellt sicher, dass das Team selbstbestimmt arbeiten kann – denn das Sprint Backlog kann der Project Owner nicht verändern oder ergänzen, ohne die Zustimmung der Entwickler einzuholen.

Hat ein Sprint erst einmal begonnen, wird außerdem das Daily Scrum zum festen Bestandteil des Arbeitstages. Diese kurze Teambesprechung von 10-15 Minuten dient dazu, allen einen Überblick über den Status Quo zu verschaffen. Jedes Teammitglied berichtet hier kurz, was es seit dem letzten Daily Scrum geschafft hat, was es bis zur nächsten Besprechung schaffen will, und ob es Hindernisse gibt, die behoben werden sollten. Indem es die offene Kommunikation im Team fördert, trägt das Daily Scrum dazu bei, eventuelle Hindernisse auf dem Weg zum Sprint-Ziel frühzeitig zu erkennen – und zu beheben.

Review, Refinement und Retrospektive

Scrum - Review, Refinement und Retrospektive

Ist ein Sprint abgeschlossen, folgt direkt die sogenannte Sprint-Review. Sie dient dazu, das Increment – also das Teilprodukt, das im Sprint erarbeitet wurde – den Stakeholdern vorzustellen und zu prüfen, ob diese Teillieferung des Produkts den an sie gestellten Anforderungen von Seiten der Kunden entspricht.

Zumeist übernimmt der Product Owner stellvertretend für den eigentlichen Kunden die Rolle des Stakeholders. Je nachdem, wie intensiv und breit gefächert das Feedback ausfallen soll, können allerdings auch weitere Stakeholder in die Sprint Review einbezogen werden. Diese Rolle können sowohl Auftraggeber als auch Führungskräfte aus dem eigenen Unternehmen und auch User übernehmen, da sie alle Ansprüche an das Produkt des Scrum-Projekts stellen.

Die Ergebnisse der Sprint Review gehen wiederum in den Prozess des Product Backlog Refinements ein. Diese kontinuierliche Pflege und Verfeinerung des Project Backlogs ist Aufgabe des Product Owners und ermöglicht es, anhand der Ergebnisse des jeweils vorhergehenden Sprints Planung und Durchführung des nächsten zu streamlinen.

Ergänzend zur Sprint Review führt das Scrum Team zudem eine Sprint-Retrospektive durch. Sie dient dazu, den Verlauf des Sprints Revue passieren zu lassen und Prozessoptimierung an der eigenen Arbeitsweise zu betreiben. Daher kommen in der Retrospektive vor allem Kommunikation und Zusammenarbeit im Scrum Team zur Sprache.

Welche Rollen gibt es in einem Scrum Team?

Rollen in einem Scrum Team

Was Scrum als Methode auszeichnet und auch von anderen Methoden des Projektmanagements unterscheidet, ist die Organisation innerhalb des Teams. Im Scrum gibt es drei aktive Rollen: Den Product Owner, den Scrum Master und die Entwickler. Der Product Owner und der Scrum Master schaffen dabei die richtigen Rahmenbedingungen dafür, dass sich das Entwicklungsteam voll und ganz darauf konzentrieren kann, das Projekt voranzutreiben.

Umgangssprachlich wird zumeist zwischen dem Scrum Team und dem Entwicklungsteam unterschieden. Das Scrum Team umfasst dabei Product Owner, Scrum Master und Entwickler, während das Entwicklungsteam nur die Entwickler und den Scrum Master enthält, da sich der Product Owner während der Sprints eher zurückhält und aus einer eher passiven Beobachterrolle heraus das Product Backlog Refinement betreibt.

Was macht ein Product Owner?

Der Product Owner ist für das Projekt als solches verantwortlich. Seine Aufgabe besteht darin, die Wünsche und Bedürfnisse des Auftraggebers und/oder des künftigen Users zu erfassen und das Projekt darauf auszurichten, dass genau dieses Ziel erreicht wird. Aus diesem Grund bestimmt er die Anforderungen an das fertige Produkt, setzt innerhalb des Product Backlogs die Prioritäten und legt damit die Zielsetzungen für die einzelnen Etappen (Sprints) fest. Auch das projektbegleitende Product Backlog Refinement ist seine Aufgabe.

Im Gegensatz zum Scrum Master und den Teammitgliedern, die sich projektintern fokussieren, nimmt der Product Owner dabei jedoch die Perspektive der Kunden und User auf das entstehende Produkt ein. Im Feedback während der Sprint Reviews agiert er daher als Stellvertreter der Stakeholder.

Was macht ein Scrum Master?

Der Scrum Master trägt die Verantwortung für die Methodik: Er macht das Team mit Scrum vertraut und sorgt dafür, dass die einzelnen Arbeitsabläufe sicher umgesetzt werden. Das bedeutet, dass der Scrum Master keine Führungskraft im traditionellen Sinne ist. Er koordiniert, dokumentiert und gibt bei Bedarf durchaus auch Hilfestellung, doch beschränkt er sich dabei auf organisatorische Aspekte und auf die Kommunikation im Team. Grob vereinfacht ist er für alles zuständig, das dazu beiträgt, dass sich der Product Owner und das Entwicklungsteam voll und ganz auf ihren jeweiligen Aufgabenbereich konzentrieren können.

Wie arbeitet das Entwicklungsteam?

Idealerweise ist ein Entwicklungsteam genau so groß, dass die Entwickler eng zusammenarbeiten und ihre Aufgaben selbst untereinander aufteilen können, ohne dass es zu Missverständnissen oder zeitintensiven Abstimmungsprozessen kommt. In der Softwareentwicklung hat sich hierfür beispielsweise eine Gruppenstärke von 3–9 Personen als besonders produktiv erwiesen.

Das Entwicklungsteam verwendet das Product Backlog als Basis für sein eigenes Sprint Backlog. Die Planung der Sprints, deren Aufteilung in Einzelaufgaben (Tasks) sowie die Umsetzung übernimmt das Team dabei selbst. Hilfe von außen ist nicht vorgesehen. Je nach Branche und Projekt gilt es daher, in der Zusammensetzung eines Scrum Teams die richtige Kombination an Skills für alle notwendigen Arbeitsschritte zu finden. Zumeist bedeutet das Team, in dem zwar jeder Entwickler Spezialist ist, bei Bedarf aber auch andere Aufgabenbereiche übernehmen kann.

Was macht Scrum als Methode so anpassungsfähig?

Scrum als Methode - Anpassungsfähigkeit

Sprint abgeschlossen, Backlog aktualisiert – und dann? Ganz einfach: Dann beginnt alles von vorn, denn Scrum verläuft in Zyklen. Die Abfolge der einzelnen Arbeitsschritte ist dabei immer gleich Vorbereitung, Sprint, Review und Retrospektive. Sobald ein Sprint ausgewertet ist, können auch schon die Vorbereitungen für den nächsten beginnen.

Erst dadurch, dass die Ergebnisse eines Sprints immer in die Gestaltung des nachfolgenden einfließen, kommt der agile Charakter der Methode vollständig zum Tragen: Anstatt den kompletten Projektverlauf bis ins Detail zu planen, arbeitet ein Scrum Team in Etappen, die aufeinander aufbauen und es durch ständige Selbstreflexion ermöglichen, jeden Schritt ein wenig präziser durchzuführen als den zuvor. So entsteht in jedem Sprint mit dem Increment ein Teilergebnis, das im Grunde sogar schon einsatzfähig ist – wenn auch in eingeschränktem Lieferumfang – und das mit jeder Wiederholung des Kreislaufs aus Vorbereitung, Sprint und Reflexion weiter ausgebaut und präziser auf die Bedürfnisse des Kunden ausgerichtet wird.

In diesem Punkt unterscheidet sich Scrum wesentlich von klassischen, linear ausgerichteten Methoden des Projektmanegements. Anstatt eines Produkts, das erst nach Abschluss aller Teilprozesse benutzbar ist, erhält der Kunde bereits nach jedem Sprint ein voll funktionsfähiges Increment. Das bedeutet, dass es keine unliebsamen Überraschungen geben kann, weil die Entwicklung im stillen Kämmerlein geschehen ist und der Kunde bis zuletzt nicht sehen konnte, wie das Produkt aussieht und was es kann. Vor allem aber ermöglicht der agile Prozess die flexible Anpassung an veränderte Kundenwünsche oder Bedürfnisse.

Bauen wir nach einer linearen Methode ein Auto, dann fangen wir mit dem Motor an, bauen drumherum eine Karosserie, dazu ein Lenkrad – und wenn wir alles beisammen haben, ist das Projekt abgeschlossen und das Auto fertig. Die große Schwäche dieses Vorgehens? Erklärt der Kunde sich auf halber Strecke durch den Entwicklungsprozess, dass die Zielgruppenanalyse ergeben hat, dass mehr PS sich besser verkaufen, ist es schon zu spät, um den Motor noch zu verändern.

Ein Scrum Team geht hingegen so vor, dass es im ersten Sprint ein Skateboard entwickelt, um etwas auszutesten. Dann entwickelt es das weiter, erst zu einem Roller, dann zu einem Fahrrad, einem Motorrad. Fällt dem Kunden auf, dass er mehr PS braucht, kommen die einfach im nächsten Sprint dazu. Und vielleicht entsteht so Increment für Increment ein Auto. Vielleicht gefällt dem Kunden aber auch schon das Motorrad so gut, dass das Projekt hier abgeschlossen wird. Oder das Scrum Team arbeitet weiter und entwickelt aus dem Skateboard ein Fahrzeug, das es so noch nie gab. Ganz in Anpassung an die Wünsche des Kunden.