Was ist Scrum? – Eine kompakte Einführung in die Scrum Methode

Scrum (engl.) ist ein Begriff aus dem Rugby und bedeutet wörtlich “angeordnetes Gedränge”. Die beiden Scrum Gründer Jeff Sutherland und Ken Schwaber haben die Scrum Methode 1995 erstmals auf einer Konferenz öffentlich vorgestellt. Seitdem wurde die Scrum Methode permanent weiterentwickelt und hat maßgeblich zu einem heutigen Verständnis agiler Arbeitsweisen beigetragen. Die beiden Scrum-Väter waren auch maßgeblich an der Formulierung des agilen Manifestes in 2001 beteiligt. 

Wenn Du die Frage “Was ist Scrum” kurz und knapp beantworten möchtest, dann finde ich die folgende Scrum Definition passend.

Scrum ist ein Rahmenwerk für die Zusammenarbeit von Teams basierend auf einer Definition von Rollen, Meetings und Werkzeugen, die einem Team Struktur und einen klar definierten Arbeitsprozess basierend auf agilen Prinzipien geben.

Dabei ist Scrum keine dogmatische Methode, sondern ein Framework, das einem Team und beteiligten Stakeholdern Leitplanken und Orientierungspunkte für ihre Zusammenarbeit und Kommunikation bietet. Die Scrum Methode wird durch www.scrum.org permanent weiterentwickelt und ist im aktuellen Scrum Guide dokumentiert. Die letzte Aktualisierung des Scrum Guides erfolgte Ende 2020. 

Bevor ich den Aufbau des Scrum Frameworks im Detail skizziere, gehe ich auf ein paar wesentliche Scrum Prinzipien ein. Denn diese wesentlichen agilen Prinzipien und Werte sind das Fundament auf dem agiles Arbeiten im Allgemeinen und Scrum im Speziellen gelingt. Das heißt, ohne eine Würdigung dieser grundlegenden Leitvorstellungen, kannst Du unmöglich erfolgreich mit der Scrum Methode arbeiten. 

• Vision: Das heißt, jedes Scrum Team folgt einem langfristigen Ziel, das als übergreifender Orientierungspunkt dient.
• Wertorientierung: Scrum Teams messen ihre Ergebnisse am erzielten Wert für Kunden und Unternehmen.
• Transparenz: Ziele, Entscheidungen und anstehende Aufgaben sind allen Beteiligten und Stakeholdern frei zugänglich und bekannt.
• Fokussierung: Eine konsequente Priorisierung der zu erledigenden Aufgaben sorgt für einen hohen Fokus.
• Autonomie: Das Scrum Team ist ein autonomes Team, das selbstbestimmt und selbstorganisiert arbeitet.
• Prozesstreue: Der Scrum Prozess ist nicht verhandelbar. Denn der Prozess gibt einem Team Sicherheit, senkt durch eine hohe Standardisierung die Overhead-Kosten und trägt gleichzeitig zu hoher Transparenz bei. 
• Feedback: Kunden, Anwender und Stakeholder werden eng und regelmäßig in den Scrum Prozess eingebunden und tragen mit ihrem Feedback zu einer kontinuierlichen Verbesserung bei. Zudem verbessert das Scrum Team seine Zusammenarbeit durch regelmäßige Retrospektiven.

Das Scrum Framework basiert im wesentlichen auf drei zentralen Eckpunkten:

Scrum Rollen - Verantwortlichkeiten der handelnden Personen:

• Product Owner
• Entwickler
• Scrum Master

Scrum Meetings und wiederkehrende Aktivitäten:

• Sprint
• Planning
• Daily
• Review
• Retro
• Refinement

Scrum Artefakte, Werkzeuge und wichtige Scrum Begriffe:

• Product Backlog
• Product Backlog Items (User Stories)
• Sprint Backlog
• Planning Poker und Schätzungen
• Definition of Ready
• Definition of Done
• Produkt Inkrement
• Sprint Goal
• Product Goal

Hier findest Du eine kurze Einführung in die unterschiedlichen Rollen im Scrum Framework. Wenn Du dich tiefer in die Materie einlesen möchtest, findest Du in diesem Beitrag eine ausführliche Erklärung der Scrum Rollen und ihrer Zusammenwirkung.

Der Product Owner (PO) oder auch Project Owner hat die Aufgabe, den Wert aus dem Produkt oder Projekt zu maximieren. Dazu balanciert er die Interessen des Unternehmens (Business Value) und der Anwender / Kunden (User Value). Der PO formuliert und kommuniziert eine langfristige Vision für das Vorhaben. Damit das gelingt, braucht der PO ein tiefgreifendes Verständnis der Kundenbedürfnisse und der strategischen Rahmenbedingungen aus Sicht des Unternehmens. 

Das wichtigste Werkzeug des Product Owners ist das Backlog und die Priorisierung der darin enthaltenen Themen. Damit stellt der PO sicher, dass das Team an den richtigen Aufgaben arbeitet und jeder im Team seine Zeit gewinnbringend im Sinne des Unternehmens und für den Kunden einsetzt. Zudem formuliert der Product Owner für jeden Sprint ein “Sprint Goal” und übergeordnete “Product Goals”. 

Mit dem Scrum Guide 2020 wurde aus dem Entwicklungsteam schlicht und ergreifend die Rolle des Entwicklers“. Damit ist schlicht und ergreifend das umsetzende Team gemeint, das autonom und selbstorganisiert an der Umsetzung der verabredeten Aufgaben arbeitet. Dazu committed sich das Team auf die in einem Sprint zu erledigenden Aufgaben. Das heißt, es werden keine Arbeitspakete durch den PO oder andere Personen zugeteilt. Stattdessen entscheidet das Team während des Plannings welche der priorisierten Aufgaben im Rahmen des Sprints erledigt werden können. Damit Teams selbstwirksam auftreten und sich auf Aufgaben verpflichten können, ist eine wichtige Voraussetzung, dass Entwicklungs- oder Projektteams interdisziplinär besetzt sind. Das heißt, dass alle notwendigen Kompetenzen und Fähigkeiten im Team vorhanden sind, um die verabredeten Aufgaben zu lösen und die Ziele des Sprints zu erreichen.

Der Scrum Master ist der Coach des Teams und des Product Owners. Das heißt, seine wichtigste Aufgabe ist es, das Team und den Product Owner darin zu befähigen, ihre Aufgaben bestmöglich zu erledigen. Dazu beseitigt er Hindernisse, trägt zu einer effizienten Umsetzung bei und unterstützt das Team in der Einhaltung des Scrum Prozesses. Zudem schützt der Scrum Master das Team vor ungewollter Einflussnahme. Dazu coacht er auch beteiligte Stakeholder und stellt sicher, dass agile Prinzipien von allen Beteiligten gelebt werden.

Der zweite wichtige Eckpunkt des Scrum Frameworks ist der Scrum Prozess bestehend aus einer wiederkehrenden Abfolge von Sprints. Jeder Sprint ist wiederum durch fest definierte Scrum Meetings gekennzeichnet. Diese klare Struktur und vor allem die Standardisierung der Scrum Meetings trägt zu einer hohen Effizienz bei. Damit reduzierst Du mit dem Scrum Prozess den organisatorischen Overhead auf ein absolutes Minimum. 

Im folgenden skizziere ich was einen Sprint auszeichnet und mit welchen Zielen und unter welchen Regeln die Scrum Meetings stattfinden. 

Der Sprint ist das oberste zentrale Ordnungsprinzip im Scrum Framework. Dabei ist ein Sprint ein fest definiertes Zeitintervall, in dem das Team an der Erledigung der vereinbarten Aufgaben und der Erreichung des Sprint-Ziels arbeitet. Dabei geben sich Sprints geben sich sprichwörtlich die Klinke in die Hand. Das heißt, das Ende des einen Sprints ist der Anfang des nächsten Sprints. Die Dauer eines Sprints beträgt typischerweise 1-4 Wochen und wird in Abhängigkeit des Produktes / Projektes festgelegt. Dabei solltest Du folgende Rahmenbedingungen berücksichtigen:

• Die Sprintdauer ist fix, d.h. alle Sprints haben die gleiche Dauer. Das gilt solange, bis Du möglicherweise feststellst, dass eine andere Sprintdauer für dein Vorhaben angemessener wäre. Dann änderst Du die Sprintdauer und bleibst dabei.
• Sprints dauern max. vier Wochen. Der relativ kurze Zyklus von vier Wochen ist der Einsicht geschuldet, dass mit zunehmender Länge eines Zyklus die Qualität der Planung sinkt. Diese Erkenntnis ist auch als “Cone of uncertainty” bekannt. 

Das ausführende Team arbeitet an der Umsetzung der vereinbarten Aufgaben. Da der PO nicht an der Umsetzung mitwirkt, hat er während des Sprints die wichtige Aufgabe das Backlog weiter zu pflegen und zu priorisieren und damit schon wieder den nächsten Sprint vorzubereiten. Dazu stimmt er sich in Refinement Meetings auch mit dem Team ab, damit Aufgaben im nächsten Planning bereits einmal durchdacht und nicht völlig neu sind. Zudem steht er dem Team auch während der Umsetzung für Rückfragen zur Verfügung bzw. priorisiert Aufgaben neu, sofern sich im Laufe der Umsetzung neue Erkenntnisse ergeben, die die ursprüngliche Planung durcheinander bringen. 

Wenn das ursprünglich formulierte Sprint Ziel keine Relevanz mehr hat, obsolet geworden ist bzw. keinen Wert mehr verspricht, kann der PO entscheiden den Sprint abzubrechen. Alternativ kann der PO entscheiden, dass die am höchsten priorisierten Aufgaben aus dem Backlog gezogen werden.  

Jeder Sprint ist durch eine Abfolge von Scrum Meetings strukturiert. Dabei hat jedes Meeting einen klaren Platz im Sprint. Dazu zählen ein fest definiertes Ziel und eine geregelte Timebox, die sich nach der Länge des Sprints richtet. Das alles trägt zu einer sehr effizienten und guten Meetingkultur bei. 

Zunächst gebe ich Dir einen kurzen Überblick und Zusammenfassung der Scrum Meetings. In den nun folgenden Abschnitten gehe ich näher auf die Ziele und den Ablauf der Scrum Meetings ein.

Bitte berücksichtige, dass sich die hier gemachten Zeitangaben auf eine Sprint Dauer von vier Wochen beziehen. Zudem geht das Scrum Framework von der idealen Voraussetzung aus, dass Teams Vollzeit an der Umsetzung arbeiten. Das heißt, wenn Du kürzere Sprints machst oder das Team mit weniger Kapazität an der Umsetzung arbeitet, passt Du die Länge der Scrum Meetings entsprechend an.

Jeder Sprint startet mit einem gemeinsamen Planning, an dem das gesamte Scrum Team (PO, Developers, Scrum Master) teilnimmt. Während des Plannings werden anstehende Aufgaben diskutiert und der erwartete Aufwand geschätzt. Erst mit der Schätzung über den erwarteten Aufwand wird der Product Owner dazu befähigt, auf Basis des erwarteten Nutzens und des erwarteten Aufwands , eine finale Entscheidung bzgl. der Priorisierung zu treffen. Sofern eine Aufgabe priorisiert ist, verpflichtet sich das umsetzende Team auf die Erledigung der Aufgaben. Dazu übernimmt das Team die priorisierten Aufgaben in sein Sprint Backlog. Während des Plannings formuliert der Product Owner ein Sprint Ziel. Bei einem vierwöchigen Sprint in dem das Team mit 100% Kapazität arbeitet, werden für das Sprint Planning 8 Stunden angesetzt.

Das Daily ist eine tägliche Synchronisation der Entwickler bzw. des umsetzenden Teams. Das heißt, der Scrum Master und der Product Owner nehmen nur optional teil. Da die Dauer auf 15 Minuten begrenzt ist, findet es oft im Stehen statt. Deswegen wird es mitunter auch “Daily Stand Up” genannt. Dabei haben das Stehen und die enge Timebox einen ganz einfachen Hintergrund. Denn statt sich in epischer Breite auszulassen, ist jedes Teammitglied eingeladen ein kurzes Update zu geben, um sich mit den Kollegen zu synchronisieren. Wo stehe ich gerade, brauche ich Hilfe, habe ich sonstige Fragen? Sollte sich daraus weiterer Gesprächsbedarf ergeben, finden im Anschluss an das Daily weiterführende Gespräche statt, anstatt das gesamte Team während des Dailys damit zu behelligen. Das Daily findet jeden Tag zu gleicher Zeit am gleichen Ort für 15 Minuten statt. 

Zum Ende des Sprints präsentiert das umsetzende Team seine erzielten Arbeitsergebnisse. Zu dieser  Review oder auch Demo werden der Product Owner, interessierte Stakeholder und gerne auch Kunden eingeladen. Das heißt, die Review bietet den Entwicklern eine Bühne, um ihre Leistung im zurückliegenden Sprint zu präsentieren. Zum anderen haben Stakeholder und Kunden die Möglichkeit Feedback zu geben und Fragen zu stellen, um damit auch auf die künftigen Planungen und Priorisierungen des Product Owners Einfluss zu nehmen. Die Entscheidung, was davon wie priorisiert wird, obliegt jedoch alleine dem Product Owner. Das heißt, die Review ist keine Abnahme oder mit einem Lenkungsausschuss zu vergleichen. Denn hier präsentiert ein autonomes Team, das auf Basis einer gemeinsamen Planung mit dem Product Owner sein bestmögliches getan hat. Weitere Aufgaben werden durch den PO priorisiert. Sofern es Anlass für eine Unzufriedenheit mit dem Ergebnis gibt, ist das ein Thema für die Retrospektive.

Schließlich endet der Sprint mit einer Retrospektive des Scrum Teams. Dazu treffen sich die Entwickler, der Product Owner und der Scrum Master, um die Zusammenarbeit zu reflektieren und basierend auf diesen Einsichten verbindliche Vereinbarungen für künftige Sprints zu treffen. Das heißt, in der Retrospektive geht es ausschließlich um den Arbeitsprozess, gar nicht um Inhalte bzw. Arbeitsergebnisse. Der Scrum Master moderiert die Retrospektive z.B. nach folgendem Muster.

• Willkommen (“Set the stage”)
• Informationen und Eindrücke sammeln (“Gather data”)
  • Was ist gut gelaufen? (Keep)
  • Was sollten wir einstellen? (Drop) 
  • Was könnten wir ausprobieren? (Try)
• Erkenntnisse verdichten (“Generate insights”) 
• ToDos für den folgenden Sprint formulieren (“Decide what to do”)
• Abschluss (“Closing”) - Wem möchte ich Danke sagen?

Besonders in der Retrospektive kommen agile Prinzipien und agile Werte zum Tragen. Denn hier braucht es Offenheit, Selbstreflektion und den Wunsch nach ständiger Verbesserung. Die Retrospektive schließt mit konkreten Vereinbarungen, die im nächsten Sprint umgesetzt werden und unter Umständen auch einen eigenen Eintrag im Sprint Backlog erhalten.

Das einzige Scrum Meeting, das keiner definierten Struktur folgt, sind Refinement Meetings. Das Ziel dieser Refinements ist, dass sich Product Owner und Entwickler im Vorfeld zu einem Sprint Planning über den Umfang, den Outcome und die Akzeptanzkriterien von anstehenden Aufgaben unterhalten. Das gibt dem Product Owner die Möglichkeit seine Anforderungen zu schärfen und den beteiligten Entwicklern die Chance schon einmal über Anforderungen nachzudenken. Dabei ist die grundlegende Idee, dass Entwickler nicht erst im Planning von einer Anforderung erfahren. Diese vorherige Synchronisation und ein gemeinsames Refinement der Aufgaben sind gerade bei sehr komplexen und umfangreichen Aufgaben wichtig, um die effiziente Durchführung des Plannings zu gewährleisten. Wenn Du also merkst, dass ihr während des Plannings nicht auf den Punkt oder zu einem guten Abschluss kommt, dann könnte ein unzureichendes Refinement eine mögliche Ursache sein. Das Refinement soll nicht mehr als 5-10 % der Zeit während eines Sprints in Anspruch nehmen.

Neben Rollen und den Aktivitäten sind die Scrum Artefakte und Werkzeuge der dritte zentrale Baustein des Scrum Frameworks. Im Folgenden werde ich die folgenden Scrum Artefakte kurz erläutern.

Das Backlog ist die Summe aller anstehenden Aufgaben. Eine angemessene deutsche Übersetzung wäre z.B. “Themenspeicher”. Das heißt, im Backlog findest Du alle Aufgabenstellungen und Ideen, von denen Du als Product Owner annimmst, dass sie Wert für das Projekt oder das Produkt schaffen oder die vielleicht nur aus formalen Anforderungen erledigt werden müssen. Das Product Backlog wird vom Product Owner z.B. in einem Kanban Board gepflegt und laufend priorisiert. Im Optimalfall ist das Product Backlog online für das Team und die beteiligten Stakeholder einsehbar. 

Einzelne Einträge und Aufgaben innerhalb des Backlogs sind “Product Backlog Items”. Das können kleine sehr konkrete ToDos sein, Ausweitungen bestehender Leistungsmerkmale, neue Features oder auch neue Epics. Von einem Epic sprichst Du immer dann, wenn neue Leistungsmerkmale eine “epische” Breite bzw. Tiefe haben und nicht mehr innerhalb eines einzelnen Sprints umgesetzt werden können. Diese Epics werden dann in bearbeitbare Product Backlog Items aufgebrochen. 

Jedes Product Backlog Item enthält den erwarteten Kundennutzen, ggf. den Mehrwert für das Unternehmen und Messgrößen zur Beurteilung der Wirksamkeit der Maßnahmen oder des Features. Zudem enthält das Backlog Item Akzeptanzkriterien, die für die Erfüllung der Aufgabe notwendig sind. Auch wenn es kein offizielles Format für Product Backlog Items gibt, haben sich User Stories als defacto Standard etabliert. 

Das Sprint Backlog enthält alle Aufgaben, die im laufenden Sprint durch die Entwickler bearbeitet werden. Während das Backlog unter der Hoheit des PO steht, gehört das Sprint Backlog einzig und allein dem umsetzenden Team. Dabei ist das Sprint Backlog ein Ergebnis des Sprint Plannings. Denn hier entscheiden der PO und das Projektteam gemeinsam, welche Backlog Items im kommenden Sprint bearbeitet werden. Sofern sich die Entwickler auf die Erledigung eines Product Backlog Items verpflichten, wird dieses in das Sprint Backlog übernommen.

Die Definition of Ready (DoR) ist kein offizieller Bestandteil des Scrum Guides, spiegelt jedoch eine wichtige konzeptionelle Idee wider. Denn damit drückt das Team sein Verständnis aus, welchen Reifegrad eine Aufgabe im Backlog erfüllen darf, um überhaupt bearbeitet werden zu können. Zum Beispiel können der erwartete Nutzen oder auch Messgrößen zur Beurteilung der Wirksamkeit Bestandteil der Definition of Ready sein. Sofern eine Aufgabe die Definition of Ready nicht erfüllt, ist der PO gefordert das Product Backlog Item weiter auszuarbeiten. Die Definition of Ready  (DoR) wird wie die Definition of Done (DoD) einer ständigen Anpassung und kritischen Überprüfung unterzogen. So kann das Team z.B. im Rahmen der Retrospektive entscheiden die Definition of Done (DoD) oder auch die Definition of Ready (DoR) anzupassen.

Die Definition of Done (DoD) ist eine Vereinbarung und das gemeinsame Verständnis des Teams, wann Arbeit erledigt ist. Das heißt, die DoD enthält allgemeingültige Regeln für die erfolgreiche Erledigung einer Aufgabe. Zum Beispiel beinhaltet  die DoD, dass  für die Erledigung einer Aufgabe alle Akzeptanzkriterien erfüllt sein müssen. Zusätzlich könnte ein Team z.B. vereinbaren, dass Arbeitsergebnisse für alle zugänglich und besprochen sein müssen, damit eine Aufgabe wirklich “done” ist. Entsprechend kann eine Aufgabe in deinem Kanban Board erst auf “Done” verschoben werden, wenn sie die Bedingungen der “Definition of Done” erfüllt. 

Wenn Du den Scrum Guide liest oder hörst, wird dir der Begriff “Produkt Inkrement” ganz sicher auffallen. Das Produkt Inkrement beschreibt die, während eines Sprints erzielten, Arbeitsergebnisse. Also das “Delta” zum Arbeitsstand vor dem letzten Sprint bzw. die neuen Leistungsaspekte, die das Team in diesem Sprint fertig gestellt hat.

Während des Sprint Plannings schätzt das umsetzende Team den Aufwand einzelner Aufgaben. Damit gibt das Team dem Product Owner ein wichtiges Feedback zu dem erwarteten Aufwand der Umsetzung. Der PO kann also seinen erwarteten Nutzen und den Aufwand direkt gegenüberstellen sowie seinen Backlog und die Aufgaben für den Sprint besser priorisieren. Der Schätzwert, den eine Aufgabe erhält, wird in Anlehnung an User Stories auch “Story Points” genannt. Wenn Du die Story Points aller Aufgaben im Sprint addierst, erhälst Du eine Maßzahl für die Leistungsfähigkeit des Teams. Damit hast Du eine Orientierung, die dir auf lange Sicht hilft besser zu planen. 

Für das Schätzen hat sich “Planning Poker” als Methode etabliert. Dabei bekommt jedes Teammitglied einen Satz Karten, der je einen Wert aus der Fibonacci Reihe (1, 2, 3, 5, 8, 13, 21 …) enthält. Nach Vorstellung einer Aufgabe spielen alle Teammitglieder ihre Karte gleichzeitig aus. Damit soll vermieden werden, dass sich Teammitglieder zu stark gegenseitig beeinflussen. Mit ihrer ausgespielten Karte schätzt jedes Teammitglied den erwarteten relativen Aufwand. Dabei handelt es sich um keine absolute Aufwandsschätzung, sondern den erwarteten Aufwand in Relation zu einer Referenzaufgabe. Denn die mit der Schätzung verbundenen Informationen sind wichtiger als der absolute Aufwand. Das heißt, wenn die Schätzungen zu weit voneinander abweichen, dann haben Entwickler scheinbar ein unterschiedliches Verständnis über den Umfang einer Aufgabe. Damit fördern das Planning Poker und Schätzen eine konstruktive Auseinandersetzung, werfen wichtige Fragen auf und helfen dem Team ein besseres Verständnis der zu erledigenden Aufgabe zu gewinnen. 

Das Sprint Goal beschreibt die Ziele des aktuellen Sprints und wird durch den Product Owner während des Plannings formuliert. Dabei hat das Sprint Goal die wichtige Aufgabe den Entwicklern nochmal eine Orientierung zu bieten, was im Rahmen des aktuellen Sprints erreicht werden soll.

Mit dem Scrum Guide 2020 wurde das “Product Goal” eingeführt. Das Product Goal ist ein Sprint-übergreifendes Ziel und vor allem dann relevant, wenn Ergebnisse eines einzelnen Sprints und deren “Increments” nur Zwischenschritte für die Fertigstellung eines neuen Features sind. Das heißt, das Product Goal wird auch über mehrer Sprints definiert und bietet dem Team eine zusätzliche Orientierung über einen einzelnen Sprint hinaus.

Mittlerweile hat das Scrum Modell über 25 Jahre Reifeprüfung und ständige Anpassung hinter sich. Dabei ist Scrum vor allem in Verbindung mit Kanban mittlerweile ein defacto Standard für die agile Produktentwicklung und agiles Projektmanagement. Dabei ist die Würdigung wesentlicher agiler Werte und Prinzipien das Fundament auf dem die Scrum Methode wirksam wird. 

Für mich als Berater ist Scrum ein unverzichtbarer Baustein beim Aufbau einer agilen Projektorganisation für die erfolgreiche Gestaltung der digitalen Transformation. Und ein gutes und sehr einfaches Mittel, um mal ein wenig an den Grundfesten der heutigen Organisation zu rütteln. Sofern auch Du mal ein wenig rütteln willst, findest Du in diesem Artikel ein paar Überlegungen, wie Du Scrum in deiner Organisation einführen kannst. 

Viel Erfolg.