Agile Brainfood | Allgemein | Prozess

Scrum Begriffe kurz und leicht verständlich erklärt.

Ein Scrum Glossar

Blog Titelbild

Alle reden über Scrum! Hier ein paar wichtige Begriffe einfach erklärt, so dass das Kaffeepausengespräch auch klappt.

Das Scrum Rahmenwerk hat eine sehr einfache und reduzierte Struktur, die mit drei Rollen, wenigen Artefakten und einfachen Ritualen, die in der Literatur oft Ereignisse genannt werden, auskommt. Die Einfachheit ist bestechend. Die Zusammenhänge zwischen diesen Grundelementen im Alltag als aktive Kommunikationsbeziehung sicherzustellen ist nicht selten etwas spannender. Hier eine kleine Übersicht über die wichtigsten Begriffe und ein paar Hintergrundinformationen dazu.

Die wichtigsten Scrum-Rituale, Rollen und Begriffe im Überblick

Daily Scrum (Ritual)

Das Daily Scrum ist ein kurzes Zusammentreffen des ScrumTeams, um zu sich zu synchronisieren.
Kurzer Austausch, was in den letzten 24h im Kontext des Sprintziels erreicht wurde, was in den nächsten 24h erreicht werden wird und welche Unterstützung im Team ausgetauscht werden kann. Dieses zentrale Ritual dauert 15 Minuten und findet am Taskboard des Teams statt.

Definition of Done (Artefakt)

Im Rahmen eines selbstorganisierenden ScrumTeams werden in der DoD die Aspekte gesammelt, die zum Abschluss eines Product Backlog Items erledigt sein müssen. Inhalt und Formulierung der DoD werden kontinuierlich angepasst und sind von Team zu Team unterschiedlich. Sie begleitet das Team auf dem Weg der kontinuierlichen Verbesserung der Wirkung beim Kunden.

Das Entwicklungsteam (Rolle)

Im Entwicklungsteam finden sich alle Kompetenzen, die notwendig sind, um das Produkt weiterzuentwickeln. Zusammen mit dem Product Owner und dem ScrumMaster bilden sie das ScrumTeam. Jedes Mitglied entscheidet selbst, welche Arbeiten es macht – das große Ganze aus der Vision und das Sprintziel immer im Blick. Um diese Entscheidungen treffen zu können steht das Entwicklungsteam immer im Austausch mit dem Product Owner.

Inkrement (Artefakt)

Ein Begriff aus dem lateinischen, der bei einer schrittweisen Vergrößerung den Umfang beschreibt, um welchen sich das Gesamtsystem vergrößert. Mit einem Inkrement ist also gemeint, welche Produktveränderung das Entwicklungsteam in einem Sprint leisten kann, um die Wirkung beim Kunden zu vergrößern. Es muss potentiell lieferbar sein, so dass der Product Owner entscheiden kann, dieses zur Wirkung des Kunden auszurollen. Um die gemeinsamen Erwartungen an ein Inkrement für das Team stabil zu halten, nutzen viele Teams die Definition of Done.

Inspect and Adapt

Genau wie „KVP“ steht auch Inspect and Adapt für die Absicht, die eigenen Perspektiven immer wieder mit der möglicherweise geänderten Umgebung abzugleichen. Inspect and Adapt führt einen großen Schritt weiter. In komplexen Systemen fehlen sehr oft alle Anhaltspunkte, um eine frühe und richtige Entscheidung treffen zu können. Hier müssen kleine Experimente formuliert werden, aus denen dann eine weitere Vorgehensrichtung abgeleitet werden kann.

Es ist die hohe Kunst des agilen Arbeitens, sich in hochkomplexen System mit kleinen Experimenten, Kundenbefragungen und Machbarkeitsstudien langsam nach vorne zu arbeiten.
Dabei Wirtschaftlichkeit, Kundenwirkung und Produktqualität so zu steuern, dass die gewonnenen Erkenntnisse langfristig und nachhaltig in die richtige Richtung führen ist der Schlüssel zu wertvoller Produktentwicklung.

KVP 

KVP steht für „Kontinuierlicher Verbesserungsprozess“. Das beschreibt die Fähigkeit und den Wunsch des Teams auch bei sich ändernden Situationen anpassbar und lernfähig zu bleiben. Alle Lebensbereiche sind im stetigen Wandel, da machen Kundenwünsche, Mitbewerber und technische Neuentwicklungen als Einflussvariablen im Arbeitsumfeld keine Ausnahme. Um als Team leistungsfähig und wirtschaftlich erfolgreich zu bleiben muss also eine Anpassung an die neue Umgebung erfolgen. Eine etwas detailliertere Beschreibung finden Sie hier: Artikel zu KVP

Product Backlog (Artefakt)

Das Product Backlog ist die priorisierte Liste der nächsten Dinge, die das Entwicklungsteam zur Steigerung des Kundennutzen umsetzen wird. Das ist KEINE Wunsch-, Merk- oder Ideenliste!

Sollte sich jemand im ScrumTeam die Frage stellen, an WAS als nächstes gearbeitet werden sollte, findet er die Antwort darauf im Product Backlog. Das bedeutet auch, dass es immer und für alle gut sichtbar sein muss.
Der Product Owner ist vollumfänglich für Inhalt und Reihenfolge des Product Backlogs verantwortlich. Natürlich können alle Mitglieder des Entwicklungsteams bei der Detaillierung und Ausarbeitung des Product Backlogs mitarbeiten.
Das Product Backlog sollte 2-3 Sprints bearbeitbare Stories enthalten, ungefähr 3 Monate an Stories, die gerade vom PO bearbeitet und weiter detailliert werden. Alles hinter dem 3 Monats-Horizont ist zu weit weg, es droht die Gefahr, Dinge ins Backlog aufzunehmen, die nicht gebraucht werden.

Planungstrichter

Wenn man sich an diese zeitlich Struktur des Product Backlog hält, wird sehr deutlich, dass in die oberste Story des Backlog bereits die meiste Requirements Engineering Arbeit geflossen ist. Sie ist genauer durchdacht, genauer im Team besprochen und alle haben ein klares Bild, in welcher Weise es beim Kunden Mehrwert stiftet.
Dinge am unteren Ende des Backlog sind sehr grob, ungenau und dienen zur groben Orientierung. Hier ist noch wenig Aufwand in jede einzelne Story geflossen. Dieses Phänomen wird oft als Planungstrichter bezeichnet. Es ist gut und richtig nicht genau zu wissen, was wir in 6 Monaten entwickeln. Es ist absolut notwendig ein klares Bild von dem zu haben, was das Team in 6 Tagen entwickeln darf.

Product Owner (Rolle)

Der Product Owner trägt die Verantwortung, dass das Entwicklungsteam immer an den Dingen arbeitet, die dem Kunden und Nutzer den grössten Mehrwert liefern.
Er drückt dies durch die Sortierung des Backlogs aus. Sein zentrales Werkzeug zur guten Produktentwicklung ist sein Backlog. Es ist offensichtlich, dass der Product Owner für seine Priorisierungsarbeit sehr engen Kontakt mit Kunden, Nutzern und Stakeholdern braucht.
Er hat die wirtschaftliche Verantwortung und darf entscheiden, ob ein Inkrement ausgerollt wird.
Für den Product Owner ist es unerlässlich für eine Inspect&Adapt Einstellung in der gemeinsamen Arbeitsweise begeistern zu können. Er ist im Austausch mit dem Kunden. Sehr oft weiß noch nicht mal der Kunde, was genau er will. Also hilft der Product Owner dem Kunden, in dem er mit Kunde und Entwicklungsteam kleine Experimente zu Features startet. D.h. das Team entwickelt erste Prototypen und der Kunden kann damit interagieren und ein tieferes Verständnis über dessen Anforderungen entwickeln. Sowohl die Begeisterung für das Produkt als auch für die Arbeitsweise helfen, dem Entwicklungsteam und dem Kunden auf lange Sicht erfolgreich die richtigen Features richtig zu entwickeln.
In den frühen Scrum Implementierungshilfen durfte die Rolle des Product Owners nur genau ein Mal vorkommen. Um den ganzen Anforderungen an Requirements Engineering und Kommunikation nachzukommen, gibt es mittlerweile auch einige Teams, die mit mehr als einem Product Owner arbeiten. Allerdings darf die Gesamtheit der Product Owner nur mit einer Stimme ins Team, bzw. Im Product Backlog wirken.

Produktvision (Artefakt)

Die Produktvision beschreibt vage und nur zur Ausrichtung an einem „Nordstern“ welchem Zweck das Produkt dient. Jedes Entwicklungsteam möchte gerne wissen, zu welchem Zweck es Produkte entwickelt. Welches Kundenproblem mit der Lösung behoben wird. Um hierbei ein gutes Maß an Begeisterung aufbauen zu können, hilft es, sich Gedanken darüber zu machen, was sich durch die Fertigstellung des Produkt geändert hat.
Alle Beteiligten schaffen sich also einen begeisternden und attraktiven Orientierungspunkt in der fernen Zukunft und alle kleinen Aufgaben des Alltags oder des aktuellen Sprint zahlen auf die Erreichung dieser Vision ein. Einen weiterführenden Artikel zum Thema Vision gibt es hier: Visionsartikel

Product Backlog Refinement (Ereignis)

Das Refinement ist der Prozess, mit dem die Anforderungen gesammelt und ein tieferes Verständnis über die zu lieferenden Inkrementteile geschaffen wird. Oft wird hierzu ein separates Meeting gemacht, in dem der Product Owner seine aktuellen Ideen mit dem Team bespricht und so auch die Perspektive der technischen Experten einholt. Sehr oft sind es die kleinen Gespräche zwischen allen Beteiligten, die letztlich das Bild auf das Produkt schärfen.

Scrum Master (Rolle)

Der ScrumMaster ist der ServantLeader im Scrum Team. D.h. er hilft dem Entwicklungsteam dabei, die richtige Geschwindigkeit und den richtigen Rahmen für die gemeinsame Zielerreichung zu finden. Mal bremst er den Product Owner, um den Fokus auf die Qualität zu lenken. Ein anderes Mal spornt er das Entwicklungsteam an, um die Kundenwünsche früher zu erreichen. Er bietet neben Scrum-, und Moderationswissen auch eine neutrale Perspektive im Team an, um jedweden Konflikt einer Lösung zuführen zu können. Der ScrumMaster profitiert von seinem Netzwerk aus Vertrauen und Kommunikation. So wird er das Team beim Reflektieren der eigenen Praktiken begleiten und auch individuelle Veränderung im Rahmen von Einzelgesprächen unterstützen. Er hält den kontinuierlichen Verbesserungsprozess hoch und bereichert ihn durch Methoden und Perspektiven.

Sprint (Ereignis)

Damit das Entwicklungsteam für einen gewissen Zeitraum fokussiert arbeiten kann, wird eine Zeitspanne festgelegt, in der die getroffenen Entscheidungen stabil gehalten werden. Üblicherweise liegt diese Zeitspanne zwischen zwei und vier Wochen. Sie wird als Sprint bezeichnet. Der Begriff „Sprint“ ist hier ein wenig irreführend, weil man damit sehr kurze, wenig nachhaltige Lastspitzen verbindet. Im „agilen Sprint“ sind kurze, erreichbare und sinnstiftende Zieletappen gemeint. D.h. das Team legt zu Beginn fest, welche Wirkung beim Kunden gestiftet werden soll und arbeitet dann auf dieses Ziel hin.

Sprint Backlog (Artefakt)

Im Sprint Planning entscheidet das ScrumTeam welche Anforderungen es im nächsten Sprint umzusetzen plant. Die daraus entstehende Liste ist das Sprint Backlog. Es wird am Taskboard visualisiert. Dort wird der aktuelle Stand im Daily aktuell gehalten und besprochen. Am Ende eines Sprints sollten also alle Items des Sprint Backlogs umgesetzt sein.

Sprint Planning (Ritual)

Das Sprint Planning hilft dem Scrum Team eine gemeinsame Sicht auf die nächste Iteration herzustellen. Es wird also besprochen, welche Dinge genau jetzt wichtig für den Kunden sind und welche davon umgesetzt werden. Sehr oft wird der Prozess des Planning in zwei Meetings unterteilt.

Planning eins beantwortet die Frage WAS erreicht werden wird.

Planning zwei beantwortet die Frage WIE das erreicht werden wird.

Sprint Planning 1 (Ritual)

Im Planning eins stellt der Product Owner die Backlog Items vor, die als nächstes umgesetzt werden könnten. Er stellt dar, wozu diese Veränderungen am Produkt wichtig sind und welche Kundenwirkung sie haben. Das Entwicklungsteam entscheidet, wie viele Stories es in den Sprint zieht.

Sprint Planning 2 (Ritual)

Das Planning zwei findet nach dem Planning eins statt. Das Entwicklungsteam hat verinnerlicht, welches Ziel im nächsten Sprint  erreicht werden sollen. Jetzt überlegt das Entwicklungsteam WIE dieses Ziel zu erreichen ist. Sehr oft ist der Product Owner nur noch telefonisch erreichbar während des Meetings, da die Hauptarbeit jetzt im Entwicklungsteam liegt, welches verschiedene Lösungsansätze diskutiert.

Sprint Retrospektive (Ritual)

Um Inspect and Adapt in das echte Leben zu übertragen gibt es die Retrospektive. Das Team kann jetzt Verbesserungen an Zusammenarbeit und Kommunikation oder dem Scrumprozess selbst finden und diese in die weitere Arbeit integrieren. Der ScrumMaster hilft dem Team mit einer Außenperspektive und fördert den Austausch mit offenen Fragen.

Sprint Review (Ritual)

Das Sprint Review ist der Termin mit der meisten Kundeninteraktionen. Hier stellt das Entwicklungsteam das aktuelle Inkrement vor, der Kunde interagiert mit den neuen Features gibt Rückmeldung. Der Kunde lernt also wie das Team arbeitet, das Team lernt die Wünsche des Kunden noch genauer zu verstehen. Vor einigen Jahren wurden die Abnahmen der Inkremente ebenfalls im Review gemacht. Dies wurde jedoch geändert. Die Abnahmen erfolgen im direkten Dialog mit dem Product Owner im Rahmen des Daily (oder danach). Der Reviewprozess begeistert Kunde und Team für das Produkt und die Inkremente und fördert Austausch und Begeisterung.

Sprintziel (Artefakt)

Das Sprintziel legt den Fokus des Teams für den nächsten Sprint fest. Der Product Owner kann damit klar kommunizieren, welches Thema im Fokus liegt und welche Funktionalität am wichtigsten ist. Damit kann das Team klar in diese Richtung arbeiten und sehr leicht die täglichen Arbeiten am Sprintziel ausrichten.

An dieser Stelle auch nochmal der Hinweis auf unser Scrum Cheat-Sheet, das die Zusammenhänge deutlich macht.

Bild des Autors

Armin Schubert

Agiler Coach

Nach einigen Jahren in verschiedenen Führungspositionen habe ich 2012 Scrum kennengelernt und arbeite seit dieser Zeit als ScrumMaster und Agile Coach. Seit 2013 bin ich Geschäftsführer der Emendare GmbH&Co. KG und helfe Teams, Produkten und Unternehmen beim Einsatz von agilen Werten und Methoden. Insbesondere auf der Beziehungsebene des Teams sehe ich das größte Potential um positive Kräfte zu entfesseln.

armin.schubert@emendare.de

Neueste Artikel