Auf die Plätze, fertig, Sprint
Ein neuer Sprint, also ein Zyklus innerhalb dessen wir als Team arbeiten, dauert nie länger als ein Monat. In der Regel wählen Organisationen die Dauer so, wie es für die Organisation und das Team passt – vornehmlich in Wochenzyklen. Die meisten Organisationen wählen eine Dauer zwischen zwei und vier Wochen. Dies ist auch so im Scrum Guide vorgesehen. Er würde aber bspw. nie zwei Wochen und drei Tage dauern. Angebrochene Wochen sind ungeeignet.
- Jeder Zyklus ist mit einem Sprint-Ziel, auch Sprint Goal genannt, bestückt.
- Während der vereinbarten Dauer werden keine Änderungen vorgenommen, die das Sprint-Ziel gefährden.
- Es ist wichtig, dass im definierten Zeitfenster die Qualität nicht abnimmt, sondern die Entwickler dauerhaft mit höchstem Niveau am Produkt arbeiten.
- Gemeinsam entwickelt das Team das Inkrement.
- Währenddessen arbeitet der Product Owner daran, das Product Backlog zu verfeinern, zu refinen.
- Es ist die Aufgabe des Product Owner neue Erkenntnisse über das Produkt, über die Anforderungen zu erlangen und diese bei Bedarf, sofern es nicht das Goal gefährdet, in den Sprint zu geben.
Die tatsächliche Dauer eines Sprints
Wie lange dauert ein Sprint tatsächlich? Das ist häufig eine wichtige Frage in der Praxis, auf die es keine allgemeingültige Antwort gibt.
Im Grunde genommen kann man postulieren: Je höher die Ungewissheit des zu entwickelten Produkts bzw. der Anforderungen des Kunden für das Produkt sind, umso kürzer sollten die vereinbarten Zyklen dauern. Wenn also ich ein neues Produkt auf den Markt gebracht werden soll, wenn nicht bekannt ist, wie dieses bei den Kunden ankommt, wenn noch nicht klar ist, welche Features dem Kunden welchen Nutzen, dann sollte eher mit sieben Tagen gesprintet werden – also mit der denkbar kürzesten Dauer.
Wenn man genau weiß, was man entwickeln möchte und eher den administrativen „Overhead“ durch zu viel stattfindende Scrum Events verringern möchte, so ist ein vierwöchiges Zeitfenster zu bevorzugen. Im Grunde genommen gilt die Faustregel: Je kürzer die Dauer umso stärker beschränkt man das Risiko von Kosten und drohendem Aufwand durch eine Falschentwicklung. Je sicherer man sich mit der Entwicklung ist, desto länger kann der Zeitraum gewählt werden.
Die Darstellung des Fortschritts
Innerhalb eines Sprints gibt es verschiedene Möglichkeiten den Fortschritt der Entwicklung transparent zu machen. Generell hat der Stakeholder, der in der Praxis vor allen Dingen das Interesse hat, die Entwicklung eines Projekts zu beobachten, die Möglichkeit in das Sprint Backlog – also die konkrete Aufgabenliste des Teams – hineinzuschauen. Hierfür könnte darüber hinaus weitere Praktiken wie zum Beispiel ein Burn-Down-Chart heranziehen, was den Fortschritt grafisch darstellt.
Ein Burn Down Chart besteht aus zwei Graphen in einem Koordinatensystem, wobei der eine Graph zeigt, wie weit man in dem Zeitrahmen gemäß der Planung sein sollte und der andere zeigt, wie weit das Team tatsächlich ist. Hier eine exemplarische Darstellung:
In der Praxis wird häufig das Daily Scrum als Einladung an Stakeholder genutzt, so dass diese erfahren, wie die Entwicklung voranschreitet. Das Daily Scrum bietet mit seinen 15 Minuten Rhythmus beste Voraussetzung kurz, prägnant und effizient alle darüber zu informieren, wie der konkrete Stand im aktuellen Zyklus ist. Natürlich funktioniert es nicht immer, dass die Stakeholder am Daily Scrum teilnehmen können.
Der Rhythmus eines Sprints
Ein Sprint sollte in seinem Rhythmus nicht geändert werden. An diese Vorgabe sollten sich vor allen Dingen frisch gebildete Teams halten, welche sich vielleicht erst austesten müssen. Die einmal festgelegte Dauer bleibt fix und wird nicht frühzeitig beendet.
Es ist eine absolute Ausnahme und Besonderheit, wenn ein Sprint abgebrochen bzw. beendet wird. Dies geschieht nur dann, wenn das vereinbarte Ziel obsolet wird. Die Entscheidung, ob abgebrochen und komplett neu geplant wird, obliegt dem Product Owner. Er allein hat die Autorität, den Sprint abzubrechen.
Beispiel:
Stellen Sie sich vor, Sie wollen einen Onlineshop entwickeln und sind gerade dabei, ein neues Feature zu implementieren, mit dem Kunden innerhalb des Onlineshops miteinander chatten können. Nun beschließt die Bundesregierung kurzfristig die Mehrwertsteuer auf 16% zu senken. Folglich müssen Sie aus rechtlichen Gründen die Steueränderung berücksichtigen. Damit wäre das vereinbarte Ziel obsolet und der Product Owner hat einen validen Grund, den Sprint abzubrechen.
Falls ein Abbruch erfolgt, findet unmittelbar darauf ein Sprint Review statt, gefolgt von der Retrospektive und einem Planungsmeeting für den nächsten Zyklus.
Und wie funktioniert das Sprint Planning?
Das Sprint Planning ist eine Zeremonie bzw. ein Event, das den Sprint initiiert. Dabei legt das Team fest, welche Arbeiten es erledigen will und dokumentiert dies in der gemeinsamen To-Do-Liste: dem Sprint Backlog.
In der Praxis hat es sich bewährt, das Planning in 3 Themen zu gliedern:
- Thema 1: Warum ist dieser Sprint wertvoll?
- Thema 2: Was kann in diesem Sprint getan werden?
- Thema 3: Wie wird die gewählte Arbeit erledigt werden?
Thema 1: Warum ist dieser Sprint wertvoll?
Hierbei ist es die Aufgabe des Product Owners vorzuschlagen und vorzustellen, wie das Produkt, an dem das Scrum Team arbeitet, im aktuellen Sprint seinen Wert und Nutzen steigern könnte. Das Scrum Team arbeitet gemeinsam daran, ein Sprint-Ziel zu definieren, das kommuniziert und festlegt, warum der Sprint für die Kunden und die Stakeholder wertvoll sein wird. Fertiggestellt wird es, bevor das Planning endet.
Thema 2: Was kann in diesem Sprint getan werden?
Im nächsten Schritt besprechen die Entwickler mit dem Product Owner, welche Items, welche Elemente aus dem Product Backlog in den Sprint einfließen sollen. Das Scrum Team hat nun die Möglichkeit offene Fragen mit dem Product Owner zu klären und so das „Was“ bestmöglich für den Sprint vorbereitet zu haben.
Übrigens, das Scrum Team respektive die Entwickler haben hier nicht allzu viel Mitspracherecht. Sie können lediglich den Product Owner beraten, wenn es um die Frage der Priorisierung geht. Denn, die Priorisierung des Product Backlogs und den daraus resultierenden Elementen für das Sprint Backlog obliegt weiterhin dem Product Owner. Jedoch kann es innerhalb des zweiten Teils des Sprint Planning kommen, dass die Entwickler den Product Owner auf Synergieeffekte oder logische Veränderungen der Elemente hinweisen, die der Product Owner dann mitgeben kann.
Beispiel:
Der Product Owner ist bei seiner Priorisierung der Meinung, dass zuerst die Tapete an die Wand gehängt werden muss und erst danach diese mit Kleister versehen wird. Dann könnte der Entwickler mit einer Alternativlösung einschreiten: Stopp, unser Vorschlag ist, zuerst den Kleister auf die Tapete aufzutragen und danach diese an die Wand kleben. Offensichtlich ist der Einwand berechtigt und die Arbeit logischer und einfacher zu handhaben.
Thema 3: Wie wird die gewählte Arbeit erledigt werden?
Für jedes Product Backlog Item planen die Entwickler die Arbeit, die notwendig ist, um das Inkrement, das im Grunde genommen das materialisierte Sprint-Ziel ist, zu erstellen. Wichtig hierbei ist, dass es entsprechend der Definition of Done erledigt wird. Häufig passiert es, dass die Product Backlog Elemente, welche in das Sprint Backlog übernommen wurden, in noch kleinere Arbeitsaufgaben bzw. Tasks von einer Zeitspanne von einem Tag und weniger seitens der Entwickler zerlegt werden.
Bspw. könnte die Aufgabe des Beispiels „Tapete an die Wand kleben“ in die Schritte
- Aufbau des Tapeziertisches,
- Auftragen des Kleisters,
- Tapete an die Wand kleben
aufteilt werden. Diese Unterteilung und wie dieses Product Backlog Item abgearbeitet wird, liegt allein im Ermessen der Entwickler. Nur sie legen fest, wie sie das entsprechende Product Backlog Element in der geforderten Qualität entwickeln.
In diesem Zusammenhang wird auch oft von der Technik „knowledge based decision“ gesprochen. Entscheidungen werden demnach dort getroffen, wo das Wissen vorhanden ist. Entsprechend respektiert der Product Owner die Meinung des Entwicklungsteams.
Hinweise:
Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.
Wie es nach dem Sprint Planning weitergeht, verraten Ihnen Fabian Kaiser und Arie van Bennekum in ihrem gemeinsamen Buch Scrum? Frag doch einfach! Klare Antworten aus erster Hand.
Dieser Artikel ist ein Auszug aus dem Buch.
Fabian Kaiser
Fabian Kaiser ist Autor, Coach und Unternehmer. Nach seiner Ausbildung zum Kaufmann für Versicherungen, spezialisierte sich er sich auf das Thema der Agilität. Gemeinsam mit seinem Businesspartner Roman Simschek gründete er 2017 das agile Beratungs- und Trainingsunternehmen Agile Heroes. Seither veröffentlichte Fabian Kaiser zahlreiche Fachbücher über Projektmanagement, Agilität, Scrum, OKR, Jira und agile Herangehensweisen.
Arie van Bennekum
Arie van Bennekum ist einer der 17 Co-Autoren des Agilen Manifests. Er hat 1994 begonnen, auf die „sogenannte Agile Art und Weise“ zu arbeiten und ist seitdem nie wieder in alte Gewohnheiten zurückgefallen. Im Laufe der Jahre hat er sich zu einem Experten für Agile Transformationen entwickelt und ist bekannt für seine kraftvollen Vorträge auf Konferenzen, für Führungsteams und während (agilen) Transformationen.