Für all diejenigen unter Euch, denen Scrum bisher ein Fremdwort oder zu verwirrend war, denen manche Fachbegriffe einfach nichts sagen oder die einfach noch mal etwas nachlesen möchten, folgt hier eine Zusammenfassung von Scrum.
Mit Scrum sollen komplexe Prozesse, die einer gewissen Unsicherheit unterliegen, in den Griff bekommen werden und stellt im Grunde ein Rahmenwerk zum Team-Management von Arbeit dar. Ständiges Lernen, Verbesserung und Feedback sind zentrale Aspekte bei der Durchführung.
Fun Fact: „Scrum“ kommt aus dem Rugby, bedeutet „Gedränge“ und beschreibt eine Situation, in der das Team stark zusammenrückt und durch eine einheitliche Bewegung versucht, wieder in Ballbesitz zu kommen. Üblicherweise wird diese Ausgangsstellung eingesetzt, um nach einer Unterbrechung oder eines Regelverstoßes das Spiel für das Team sinnvoll neu zu starten.
Es beinhaltet die Vision über das Produkt des Product Owners (PO). Die Funktionen oder Ideen zu möglichen Produktinkrementen sind dort priorisiert und mit einigen Details aufgelistet z. B. anhand von Product Backlog Items (PBI) – Anforderungen aus Sicht eines Nutzers, die zur Diskussion anregen. Das Product Backlog wird ständig aktualisiert, erweitert und ausdifferenziert; es wächst mit dem Produkt und ist daher nie vollständig. PBIs werden gern in User Stories formuliert, um eine Einladung zu einem gemeinsamen Gespräch zu erzeugen.
Hier wird vom Team ein konkreter Plan über die Erreichung des Sprint Ziels erstellt. Das Sprint Backlog gilt immer für den aktuellen Sprint, in dem sich das Team befindet. Es wird nach jedem Sprint auf Null gesetzt und im Sprint Planning erneut erstellt.
Auch Abgekürzt als PSI (Potentially Shipable Product Increment). Es soll Qualitäten eines vollständigen Produktes aufweisen. Ferner sollte es bereit für die Produktion sein und von Nutzern getestet werden können. Außerdem beinhaltet ein Produktinkrement alle vorherigen Inkremente.
Wie der Name schon sagt, ist der PO Besitzer des Produktes und für den geschäftlichen Erfolg verantwortlich. Außerdem trifft er die Entscheidungen und definiert die Produkteigenschaften, die vom Team erstellt werden sollen – nicht aber, wie das geschehen soll! Eine weitere wichtige Aufgabe ist die Priorisierung der Anforderungen an das Team, was anhand des Product Backlogs passiert. Die Pflege des Product Backlogs gehört zum Aufgabenfeld des PO (Product Backlog Refinement, früher Backlog Grooming). Sinnvoller Weise bindet der Product Owner Kund*innen und Teammitglieder in das Refinement ein.
Das Entwicklungs-Team ist für die Umsetzung bzw. Realisierung der vom PO priorisierten Anforderung zuständig. Das Team handelt selbstorganisiert und eigenverantwortlich daran, wie das Ziel erreicht und die Qualität sichergestellt werden kann. Um am Ende ein funktionierendes Produktinkrement vorzeigen zu können, darf das Entwicklungs-Team weder zu groß noch zu klein sein. Empfohlen ist eine Größe von 3-7 Mitgliedern, die in der Lage sein müssen, gemeinsam das Sprint Backlog umzusetzen.
Er arbeitet als Teamcoach und ist dazu da, Hindernisse (Impediments) sichtbar zu machen, indem er alle Beteiligten dabei unterstützt, zu lernen und die Regeln & Werte von Scrum einzuhalten. Dadurch kann das Scrum Team besonders effektiv & effizient arbeiten. Der Scrum Master ist außerdem für die Kommunikation bezüglich des Scrum Frameworks und seinen Effekten verantwortlich und hilft der Organisation dabei, mit den Veränderungen die durch Scrum entstehen, zurecht zu kommen.
Ein Sprint ist die Zeitspanne in der ein Produktinkrement fertiggestellt werden soll und umfasst maximal einen Monat. Dazu gehören die Sprint Planung, die Daily Scrums, das Sprint Review und die Sprint Retrospektive von denen jedes Ereignis eine individuelle Timebox (zeitliche Begrenzung) hat.
Zu Beginn des Sprintes wird hier das Sprint Ziel festgelegt (aus dem Product Backlog). Dabei entscheidet das Team, wie viel in diesem Sprint realistisch zu schaffen ist. Für Schätzungen verwenden Scrum Teams gerne das sogenannte Planningpoker (Spielkarten werden mit verschiedenen Werten versehen, die den Entwicklungsaufwand darstellen und für die Product Backlog Items durchgespielt werden). Die für den aktuellen Sprint ausgewählten Product Backlog Items bilden das Sprint Backlog. Dafür sind bei einem vierwöchigen Sprint maximal 8 Stunden vorgesehen. Früher wurde die Planungsphase in zwei Teile geteilt (Planung 1: Funktionsanalyse einer Story und Planung 2: Ausformulierung der Umsetzungsschritte der Backlog Items). Im neuen Scrum Guide ist diese Unterteilung nur noch semantisch beschrieben, so dass die Teams selbst entscheiden können, wie sie ihr Planning gestalten.
Im Daily Scrum werden die nächsten 24 Stunden der Arbeit besprochen und es wird auf die letzten 24 Stunden kurz zurückgeblickt. Es sollen Probleme aufgedeckt und aktuelle Herausforderungen des Sprint Backlogs nachvollziehbar werden. Mit einem Burndown-Chart visualisieren manche Scrum Teams ihren Fortschritt im Sprint. Für das Daily Scrum sind maximal 15 Minuten vorgesehen.
Am Ende eines Sprints stellt das Scrum Team das fertiggestellte Produktinkrement den Stakeholdern (Kunden & Interessensvertretern) vor und erhält wertvolles Feedback. Der PO modifiziert daraufhin das Product Backlog. Durch das Review entwickelt sich das Product Backlog weiter.
Das Sprint Review nimmt in einem vierwöchigen Sprint maximal 4 Stunden in Anspruch.
Hier wird der letzte Sprint innerhalb des Scrum Teams betrachtet, um den folgenden Sprint zu verbessern und konkrete Maßnahmen zu identifizieren, die in der nächsten Sprint Planung von Bedeutung sind (in maximal 3 Stunden). Es ist notwendig, dass die Reihenfolge Review – Retro – Planung (des neuen Sprints) eingehalten und auch keines der Meetings übersprungen wird. Durch die Retrospektive entstehen Prozess- und Teamverbesserungen. Im Allgemeinen nennt man die Verbesserung eines Prozesses oder Produktes durch bewusste Wiederholung einer Feedbackschleife auch Iteration.
Mit diesen Werten ist eine gute Basis gelegt, aber es ist immer zu empfehlen, das Gespräch mit dem Team zu suchen und individuell andere wichtige Werte zu ergänzen. Zum Beispiel Ehrlichkeit oder Klarheit…
Teamwerte verkommen oft zu guten Vorsätzen, die einfach irgendwo auf der Wand kleben. Sie sollten jedoch in jedem Ereignis von Scrum explizit aufgegriffen werden und die Zusammenarbeit mit Hilfe der Werte überprüft werden. Keiner der Werte ist trivial und braucht daher wiederkehrendes Training und ein gemeinsames Verständnis.
Es muss eine gemeinsame Sprache und einheitliche Definitionen von der Fertigstellung von Aufgaben geben. Besonders das Verständnis eines fertigen Produktinkrementes sollte daher geteilt und diskutiert werden. Durch Transparenz werden Hindernisse und Herausforderungen für die Produktentwicklung sichtbar. Sie ermöglicht die Überprüfung und Anpassung aller Situationen und Ergebnisse.
Eine ständige Überprüfung der Aufgaben auf das Ziel und seinen Fokus ist essentiell. Aufgaben, die durch neue Gegebenheiten für die Zielerreichung nicht mehr relevant sind, sollten nicht weiterverfolgt werden. Außerdem soll die Prüfung des Produktinkrements wiederkehrend und möglichst von Angesicht zu Angesicht geschehen.
Eine Anpassung des Prozesses oder des Produktes – sollte eine Unstimmigkeit gefunden worden sein – muss so schnell wie möglich passieren. Das gesamte Scrum Team sollte sich hierzu austauschen und im Bilde sein.
Ich hoffe mit diesem Überblick, fällt es Euch leichter, Gesprächen über Scrum zu folgen und die Welt der agilen Arbeit besser zu verstehen. Achtet auf die genaue Umsetzung aller Scrum Elemente, denn Scrum ist leicht zu verstehen, aber schwer zu meistern!