Was ist ein Sprint Planning?

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.

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.

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.

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.

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.

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.

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.

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 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.

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.

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

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.

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.

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.

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.

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.

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.

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!