4.8 5 Votes
Artikel-Rating

Das Sprint Planning ist der erste Scrum Event jedes Sprints. Am Ende dieses gemeinsamen Workshops kann jedes Mitglied Deines Scrum Teams beantworten, warum der nächste Sprint wichtig ist, was getan werden muss, um das Sprintziel zu erreichen und wie Ihr dieses Ziel erreichen wollt.

In diesem Artikel zeige ich Dir, wozu das Sprint Planning dient und was genau sein Ziel ist. Darüber hinaus möchte ich Dir jedoch auch vermitteln, dass das Sprint Planning (wie alle anderen Scrum Events) einen starken kollaborativen Charakter hat, der leider von den meisten Scrum Teams übersehen wird.

Was ist das Ziel des Sprint Plannings?

Wie eingangs erwähnt, entstehen im Sprint Planning Antworten auf die drei W-Fragen Warum? Was? und Wie? Hierbei bei spielen sowohl das Scrum Artefakt Sprint Backlog als auch das Scrum Commitment Sprintziel ein besondere Rolle.

Das Sprintziel gibt die Antwort auf das “Warum”

Mit dem Sprintziel gebt Ihr eine Antwort darauf, warum das, was Euer Scrum Team im nächsten Sprint tun wird, wichtig für die Stakeholder Eures Produktes ist.

Dabei kann das Sprintziel recht unterschiedliche Formen annehmen. Angefangen bei einem konkreten Zustand, den Euer Produkt zum Ende des kommenden Sprints haben wird, bis hin zu einer Hypothese, mit deren Hilfe Ihr überprüfen möchtet, ob das, was Ihr tut, auch wirklich den gewünschten Effekt erzielt.

Wie auch immer Euer Sprintziel exakt lautet, sollte es für die Entwickler ausreichend Freiraum bieten, es zu erreichen.
0
Entgegen der landläufigen Meinung ist das Sprintziel kein optionaler Bonus, sondern fester Bestandteil jeden Sprints. Wie gut gelingt es Dir & Deinem Team, eines zu formulieren?x

Das Sprint Backlog gibt die Antwort auf das “Was” und “Wie”

Am Ende des Sprint Plannings ist das Sprint Backlog Deines Scrum Teams mit User Stories und Aufgaben gefüllt, die erklären, was Ihr tun müsst, um Euer Sprintziel zu erreichen.

Zum einen überführt Ihr alle notwendigen User Stories vom Product Backlog ins Sprint Backlog.

Zum anderen haltet Ihr Aufgaben oder Tasks fest, die notwendig sind, um jede User Story umzusetzen. Während also die User Stories im Sprint Backlog das Was angeben, spiegeln Eure Aufgaben das Wie wider.

Übergang der Verantwortung im Sprint Planning

Falls Du Dich bereits ein wenig mit dem Scrum Framework beschäftigt hast, weißt Du vielleicht bereits, dass sowohl das Product Backlog als auch das Sprint Backlog an die Scrum Rollen des Product Owners beziehungsweise Entwickler “gekoppelt” sind. Deshalb findet während des Sprint Plannings auch eine Verantwortungsübergabe statt.

Jede User Story oder Aufgabe, die während Eures Sprint Plannings vom Product Backlog ins Sprint Backlog wandert, geht auch von der Verantwortung des Product Owners in die Verantwortung der Entwickler Eures Scrum Teams über.

Die Reihenfolge ist zweitranging

Auch wenn es sehr sinnvoll ist, Euer Sprint Planning mit der Formulierung eines Sprintziels zu beginnen und Euch erst danach mit dem Was und Wie des kommenden Sprints zu beschäftigen, gibt Euch der Scrum Guide die genaue Reihenfolge nicht vor. Es ist durchaus denkbar (und möglich), zwischen allen drei Themen des Sprint Plannings zu wechseln.

Das gilt besonders für den Fall, wenn Ihr bereits ein Sprintziel formuliert habt, dann aber bei der Ausarbeitung bemerkt, dass es für einen einzigen Sprint doch etwas zu groß ist und daher umformuliert werden muss.

Darf man den Sprint ohne ein fertiges Sprint Backlog beginnen?

Nicht immer wird es Euch möglich sein, Euren nächsten Sprint perfekt zu planen. Beispielsweise wenn Ihr in der vorangegangenen Sprint Review eine vielversprechende Möglichkeit entdeckt habt, aber noch nicht klar ist, wie diese verwirklicht werden kann.

Glücklicherweise ist es gar nicht zwingend notwendig, einen exakten Plan im Sprint Planning zu entwerfen. Ihr müsst Euch lediglich auf ein Sprintziel einigen und dafür sorgen, dass jedes Teammitglied ausreichend (geplante) Arbeit für die ersten zwei bis drei Tage des kommenden Sprints hat. Die restlichen Aufgaben und ToDo’s könnt Ihr dann im weiteren Verlauf des Sprints weiter ausarbeiten.

  • Allerdings sollte diese Situation die Ausnahme darstellen und nur im Notfall so umgesetzt werden. Falls Ihr regelmäßig mit sehr viel Unklarheit in den nächsten Sprint startet, solltet Ihr spätestens in Eurer Sprint Retrospektive die Ursachen und Gründe dafür ermitteln.

Wer nimmt am Sprint Planning teil?

Am Sprint Planning nehmen alle Mitglieder Eures Scrum Teams teil; also Product Owner, Entwickler und Scrum Master. Darüber hinaus ist es möglich, dass Dein Scrum Team Kollegen aus anderen Fachbereichen zum Sprint Planning einlädt, wenn Ihr bei der genaueren Ausarbeitung Eures Plans auf Unterstützung angewiesen seid.

Wie lange dauert ein Sprint Planning?

Wie alle anderen Scrum Events ist auch das Sprint Planning timeboxed. (Das heißt, es sollte eine maximale Zeit nicht überschreiten.) Bei einem einmonatigen Sprint darf Euer Sprint Planning nicht länger als 8 Stunden dauern. Ist die Sprintlänge kürzer – beispielsweise 2 Wochen – dann verkürzt sich die Dauer des Scrum Events entsprechend auf 4 Stunden.

  • Ausufernde Sprint Plannings sind häufig ein gutes Zeichen dafür, dass Ihr zu wenig Zeit ins Product Backlog Refinement investiert und dadurch mit zu viel Unklarheit den nächsten Sprint planen müsst.

Das Sprint Planning ist ein kollaboratives Meeting

In vielen Blogartikeln über das Sprint Planning kannst Du lesen, dass der Product Owner ein Sprintziel “mitbringt” und die relevanten Product Backlog Items vorgibt, die im kommenden Sprint umgesetzt werden sollen. (Beispielsweise findest Du das so im Beitrag von me & company.)

Auch wenn dieses Vorgehen eine (leider) weit verbreitete Praxis ist, verfehlt es den Kern eines gelungenen Sprint Plannings.

Das Sprint Planning ist ein kollaborativer Workshop Deines gesamten Teams.
0
Warst Du Dir des kollaborativen Charakters des Sprint Plannings bewusst? Wie gut gelingt es Eurem Scrum Team, diesen Aspekt im Planning umzusetzen?x

Im Scrum Guide findest Du dazu drei sehr häufig überlesene Stellen:

Das gesamte Scrum Team entwirft einen gemeinsamen Plan

Erstens entwirft Euer gesamtes Scrum Team einen gemeinsamen Plan. Im Scrum Guide heißt es dazu:

This resulting plan is created by the collaborative work of the entire Scrum Team.

Das gesamte Scrum Team definiert das Sprintziel

Zweitens kommt Eurem Product Owner während des Sprint Plannings zwar eine besondere Rolle zu, allerdings ist es nicht so, dass er Euch einfach ein Sprintziel (oder sogar Aufgaben) vorgibt. Auch hierzu findest Du im Scrum Guide eine wichtige Stelle:

The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.

Die Aufgabe Eures Product Owners ist es deshalb vielmehr, mit einer guten Idee beziehungsweise einem Vorschlag zum Sprint Planning zu kommen, um dann im Austausch mit den anderen Teammitgliedern ein Sprintziel (und einen Plan) festzuhalten.

Die Entwickler wählen die passenden Backlog Items aus

Drittens gibt Euer Product Owner auch nicht einfach vor, welche Product Backlog Items erledigt werden sollen. Vielmehr ist es so, dass die Entwickler Eures Teams im Austausch mit dem Product Owner diejenigen User Stories auswählen, die zur Erreichung Eures Sprintziels notwendig sind.

Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint.

Das bedeutet weit mehr, als dass die Developer irgendwann weitere User Stories ablehnen, weil der Sprint “voll” ist.

Kollaborative Sprint-Planung mit der Team Alignment Map

Glücklicherweise existiert mittlerweile ein sehr hilfreiches Tool, um den kollaborativen Charakter des Sprint Plannings einzuüben und gemeinsam zu verinnerlichen.

Die Team Alignment Map von Stefano Mastrogiacomo ist ein einfach anzuwendendes Canvas, das Euch dabei unterstützt, gemeinsame Ziele zu formulieren und kollaborativ Euren nächsten Sprint zu planen.

Die Rolle der Definition of Done im Sprint Planning

Scrum lebt davon, dass Euer Team sich nicht mehr Arbeit vornimmt als es bewältigen kann. Außerdem soll am Ende Eures kommenden Sprints ein nutzbares Increment entstanden sein, das fertig ist. Damit jedoch jedes Teammitglied weiß, wann etwas fertig ist, benötigt Ihr eine Definition of Done.

Der Definition of Done kommt daher in Eurem Sprint Planning eine wichtige Rolle zu. Denn sie hilft Euch dabei, abzuschätzen, ob das, was Ihr Euch vorgenommen habt, auch wirklich innerhalb des kommenden Sprints fertig werden kann.

Story Points & Velocity

An dieser Stelle kommen die von agilen Teams häufig genutzten Story Points in Spiel. Denn im besten Fall schätzt Ihr die Aufwände für einzelne User Stories auf Basis Eurer Definition of Done. Mit Hilfe Eurer bisherigen Sprint Velocity könnt Ihr damit gut abschätzen, wieviel Aufwand Ihr im nächsten Sprint bewältigen könnt.

Fazit zum Sprint Planning

Ich hoffe, meine Artikel hat Dir dabei geholfen, das Sprint Planning und seinen kollaborativen Charakter besser zu verstehen. Hast Du noch Fragen, Kritik, Anregungen oder Ideen zu meinem Beitrag? Dann schreib mir gerne einen Kommentar hier unten auf der Seite!