Zum Inhalt

Theorie "Sprint Planning"

Scrum Events

In einem Scrum-Projekt gibt es fünf Scrum Events - einige davon sind Ihnen während dieses Onlinekurses schon über den Weg gelaufen, andere werden Ihnen im weiteren Kurs begegnen. Die Scrum Events sind:

  • Sprint
  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective

Die vier Scrum Events Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospective beziehen sich auf den jeweiligen Sprint und finden im Rahmen des jeweiligen Entwicklungsintervalls statt.

Was wird im kommenden Sprint erledigt werden?

Zu Beginn jedes Sprints findet das sogenannte Sprint Planning Meeting statt. Wie der Name vermuten lässt, wird in diesem Meeting der kommende Sprint geplant, welcher die Produktentwicklung einen Schritt näher an das Product Goal bringt.

Prinzipiell gibt es drei Fragen, welche Sie sich als Teil des Scrum Teams während des Sprint Planning Meetings stellen sollten:

  • Wieso ist dieser Sprint wertvoll?
  • Was kann in diesem Sprint erledigt werden?
  • Wie sollen die ausgewählten Tasks erledigt werden?

Während des Sprint Planning Meetings werden die Einträge aus dem vorher erstellten und vom Product Owner priorisierten Product Backlog ausgewählt, welche im kommenden Sprint bearbeitet und in ein auslieferbares Increment überführt werden sollen.

Increment

Das Increment stellt ein Scrum Artefakt dar. Das dazugehörige Commitment ist die „Definition of Done". Ein Increment ist ein konkreter Schritt zur Erreichung des Product Goals und das Ziel eines jeden Sprints. Ein Increment ist ein getestetes, nutzbares bzw. verkaufsfähiges Teilprodukt. Alle Arbeiten, welche nicht der Definition of Done entsprechen, sind nicht als Increment zu betrachten.

Am Ende eines jeden Sprints werden die erzeugten Increments im Sprint Review vom Product Owner abgenommen und von ihm sowie von eventuell anwesenden Stakeholdern mit den Developern begutachtet. Es ist auch möglich, ein Increment schon vor Ablauf des Sprints an die Stakeholder auszuliefern.

Gut zu wissen

Letztendlich ergibt die Summe der Increments das finale Produkt, welches durch das Product Goal beschrieben und im Product Backlog spezifiziert wurde.

Die Definition of Done

Ein wesentlicher Aspekt bei der Bearbeitung der Sprints ist die Forderung, dass ein Sprint nur dann insgesamt erfolgreich ist, wenn alle User Stories vollständig in ein Increment umgesetzt und dann im Sprint Review präsentiert wurden. Auch wenn nicht alle User Stories umgesetzt wurden, kann der Sprint als „Done" definiert werden, wenn das Sprint Goal erfüllt wurde.

Definition of Done

Die „Definition of Done" (DoD) ist ein wichtiges agiles Werkzeug, das Teams dabei hilft, Arbeit zu planen und durchzuführen. Im Prinzip ist die DoD lediglich eine Reihe von Kriterien, die das Produkt erfüllen muss, um als fertig zu gelten.

Die Kriterien der DoD, denen alle umgesetzten User Stories im Increment entsprechen müssen, können folgende Anforderungen erfüllen:

  • Geschäfts-,
  • Funktionalitäts-,
  • Qualitäts- und
  • Nicht-Funktionale Anforderungen.

Ebenfalls können sie von den Developern nach Rücksprache mit dem Product Owner festgelegt werden.

Beispiele für „Definition of Done"-Kriterien:

  • Das Sprint Goal wurde nach Einschätzung des Scrum Teams erreicht (das kann evtl. auch dann der Fall sein, wenn nicht alle User Stories umgesetzt wurden).
  • Die Akzeptanzkriterien der umgesetzten User Stories werden erfüllt.
  • Die Release-Dokumentation ist fertiggestellt.
  • Das Increment ist getestet.
  • Bestehende Richtlinien, Standards und Normen wurden eingehalten.

Ablauf des Sprint Planning Meetings

Der Scrum Master und der Product Owner verständigen sich auf das Sprint Goal.

Sprint Goal

Um den Developern die grobe Richtung des Sprints sowie einen Ausblick vorzugeben, gibt es das sogenannte Sprint Goal. Das Sprint Goal - welches das Commitment zum Sprint Backlog darstellt - wird vom Product Owner vorgegeben und es sollte am Ende des Sprint Planning Meetings allen Teilnehmern bekannt sein. Weiteres zum Sprint Goal erfahren Sie im nächsten Kapitel, welches sich mit dem Sprint Backlog beschäftig.

Sobald das Sprint Goal festgelegt wurde, gehen die Developer durch den priorisierten Product Backlog, um Product Backlog Items für den nächsten Sprint auszuwählen. Sie beginnen von oben, d. h. mit der User Story die am höchsten priorisiert ist. Wie viele User Stories oder Product Backlog Items für den kommenden Sprint ausgewählt werden, entscheiden die Developer im Team. Es werden so viele Product Backlog Items für den nächsten Sprint mit aufgenommen, wie die Developer schätzen abarbeiten zu können.

Bei der Anzahl der im Sprint Planning zur Umsetzung ausgewählten User Stories orientieren sich die Developer an zwei Größen. Beide Stundenpools sollten in etwa gleich sein, um eine realistische Chance zu haben, die Tätigkeiten zeitgerecht zu erfüllen.

  1. Die zur Verfügung stehende Nettoarbeitszeit; hier sollte sich auch die Frage gestellt werden, wie die Developer zeitlich verfügbar sind.

  2. Die geschätzten Arbeitsstunden, welche zur Realisierung der unterschiedlichen Tasks veranschlagt wurden - hier können Sie sich auch an den beim Schätzworkshop erzielten Story Points der einzelnen User Stories orientieren. Letztendlich entscheidet das Team gemeinschaftlich nach Bauchgefühl. Auch die Velocity der vorangegangenen Sprints sollte berücksichtigt werden. Das Schätzen spielt hier eine zentrale Rolle.

... und dennoch wird häufig auf Abschätzungen verzichtet.

Ihnen ist im Verlauf dieses Kurses bestimmt schon aufgefallen, dass Sie beim Scrum-Framework nicht ums Schätzen herumkommen. Vielleicht ist Ihnen in der Praxis aber schon untergekommen, dass einige Teams genau darauf verzichten. Was sind die Gründe hierfür? Zum einen kann es sein, dass Developer keinen Mehrwert bzw. keine Erkenntnisse aus dem Schätzen (v. a. aus dem Schätzen von Stunden) ziehen können und zum anderen ist am Ende eine einzelne Person - ein Developer - für die Umsetzung eines Tasks zuständig und die Teams, die auf die Schätzung verzichten, wollen die andern Developer nicht in die Entscheidung einbinden.

Sie stehen am Anfang eines Projektes bzw. am Anfang Ihrer Karriere als Teammitglied in einem Scrum Projekt und Ihre getroffenen Abschätzungen sind weit entfernt von der Realität? Machen Sie sich nichts draus! Bei zunehmender Projektdauer und gewonnener Erfahrung werden Sie immer besser. Bei späteren Sprints kann die Velocity der vorherigen Sprints genutzt werden, um die User Stories bzw. die Story Points für den Sprint auszuwählen.

Nach dieser Vorbereitung können sich dann die Developer im Anschlussmeeting auf die Überführung der User Stories in Tasks konzentrieren. Für jede User Story werden Tasks - Aktivitäten - identifiziert und in Nettoarbeitsstunden abgeschätzt. Am Ende des Sprint Plannings einigen sich die Developer darauf, das vereinbarte Sprintziel, nämlich die Umsetzung aller gewählten User Stories, möglichst zu erreichen.

Übersicht: Sprint Planning Meeting

  • Teilnehmer: Scrum Team und evtl. Vertreter des Kunden oder Anwenders
  • Dauer: maximal 2 Stunden pro Sprint-Woche
  • Moderation: Scrum Master
  • Verantwortlich für die Ziele: Product Owner
  • Ergebnis: Zielbeschreibung und Sprint Backlog des kommenden Sprints

Was passiert mit den Tasks?

Die ausgewählten Tasks gehen in den Sprint Backlog ein. Dieses ist das Ergebnis des Sprint Planning Meetings und es gibt den Developern einen Überblick über die zu erledigenden Aufgaben, um das gewünschte Increment umzusetzen.

Zusammengefasst kann gesagt werden, dass der Product Owner seinen Wunsch zum „Was" - zur Funktionalität des Increments - äußert und die Developer verantwortlich sind, dieses „Was" zu verstehen und mit dem „Wie" zu untermauern. Die Developer entscheiden selbst, wie sie die gewünschten Vorstellungen erreichen und welche Aufgaben basierend auf den Erkenntnissen des Sprint Plannings, erledigt werden müssen, um die User Stories aus dem Product Backlog umzusetzen.

Tipp

Bei komplizierteren User Stories bzw. Epics bietet es sich gegebenenfalls an, ein zweiteiliges Sprint Planning Meeting durchzuführen, in dem der Product Backlog geprüft und aktuell priorisiert wird. Die für den nächsten Sprint in Frage kommende Einträge können in dem Meeting, falls notwendig, zerteilt und ausführlich besprochen werden.