Wie sieht eine „ideale“ Sprintplanung aus?

JIN-YOUNG LEE

SCRUM in der Anwendung– Sprint Planung –

OKTOBER 2015

2

Scrum in der Anwendung – Product BacklogZiele und Inhalte des Tutorials

» Mit Hilfe dieses Tutorials soll Product Ownern / Scrum Teams vorgestellt werden, wie man einen „idealen“ Sprintablauf planen kann.

» Das Tutorial beschäftigt sich mit den folgenden Punkten:1. Wie plant man einen Sprint?2. Wie plane man ein Release?

» Die Erkenntnisse aus diesem Tutorial sind Best Practice Methoden, die im Rahmen der Kundenprojekten gewonnen und eingesetzt wurden.

3

Scrum in der Anwendung – Sprint Planung

Sprintplanung

4

Scrum in der Anwendung – Product BacklogScrum in a nutshell

» Scrum ist ein Framework für das Managen komplexer Projekte

» Der Ansatz von Scrum ist empirisch, inkrementell und iterativ

» Bei Scrum gibt es:» definierte Rollen (Product Owner,

Scrum Master, Team)» einen geregelten Sprint-Ablauf

(Grooming, Sprint Planning, Daily Stand-Up, Review, Retrospective)

» Definierte Artefakte (Product Backlog, Sprint Backlog, Scrum Board)

Der Erfolg eines Scrum-Projekts hängt von einem idealen Zusammenspiel der genannten Faktoren für das jeweilige Scrum-Team ab

2. Der „ideale“ Sprint-Ablauf

Sprint n-1 Sprint n Sprint n+1

Product Owner Aus Requirements Epics

ableiten (fachlich) Abnahme des Epics durch

Stakeholder

Architekt Aus Requirements Epics

ableiten (technisch)

Entwickler Kein ToDo

Tester Kein ToDo

Product Owner / Architekt User Stories inkl.

Akzeptanzkriterien erstellen Vorstellung der Stories für

Grooming/Estimation Klärung von Fragen

Team Estimation der User Stories im

Product Backlog Anbringen von Fragen

Tester Erstellung der Testszenarien für

geschätzte User Stories (fachlich)

Product Owner Abnahme der erledigten User

Stories im Sprint-Review

Team Ableiten der Subtasks pro User

Story

Entwickler Umsetzung der User Stories Code Review

Tester Testfallerstellung und

Testdurchführung (nur, wenn Test Teil der Definition of Done einer User Story ist)

* Sofern unterschiedliche Rollen (z.B. Architekt, Entwickler, Tester) im Scrum-Team vorhanden sind, sollten die Aufgaben auch unterschieden werden.

5

3. Positive Effekte eines „idealen“ Sprint-Ablaufs

» Wenn das Team im Laufe der Zeit eingespielt ist und der Sprint (nahezu) ideal abläuft, hat das folgende Einflüsse auf die Effektivität des Teams:» Im Product Backlog gibt es geschätzte User Stories, die sich die Entwickler

nehmen können, sobald sich im laufenden Sprint „nichts mehr zu tun“ haben.

» Der Product Owner kann anhand der Velocity genau einschätzen, wie viele User Stories bzw. Story Points das Team in den folgenden Sprints umsetzen kann. Er hat somit eine Planungssicherheit und kann auch zum Management hin, besser argumentieren.

» Das Sprint Planning 1 kann innerhalb kürzester Zeit abgehandelt warden, da bereits alle User Stories besprochen und geschätzt vorliegen. Der Product Owner muss nur noch die Priorisierung festlegen und das Team sich dazu committen. Anschließend kann das Team unmittelbar mit dem Erstellen der Tasks (Sprint Planning 2) beginnen.

6

Scrum in der Anwendung – Sprint Planung

7

Releaseplanung

Releaseplanung vs. Sprintplanung

» Nach der reinen Scrum-Lehre soll am Ende jedes Sprints ein „potentiell auslieferbares Artefakt“ erstellt werden.

» Im Normalfall ist das jedoch nicht der Fall. Es gibt weiterhin eine übergreifende Releaseplanung. » D.h. über eine Zeitdauer von mehreren Sprints werden die für das nächste

Release benötigten Features (in Form von User Stories) umgesetzt.» Anschließend wird ein Release (also ein „auslieferbares Artefakt“) gebaut

und ausgeliefert.

8

Releaseplanung vs. Sprintplanung

Entwicklung R1Entwicklung R1

Entwicklung R1Release 1 *

Test R1Go Live R1

Entwicklung R2Entwicklung R2

…

Planung R2

Release

Sprint

Entwicklungs-Stop R1

…

* Release beinhaltet u.a. das Bauen eines Release, das Deployment, ein Smoke Test sowie die Bereitstellung aller benötigen Dokumentationen

9

10

Scrum in der Anwendung – Sprint Planung

Zusammenfassung

11

Scrum in der Anwendung – Product BacklogZusammenfassung

» Jedes Team steht einmal am Anfang. Bis es den für das jeweilige Scrum-Team idealen Sprintablauf findet, kann einige Zeit vergehen (Forming, Storming, Norming, Performing)

» Es gibt auch Teams, wo es nie zu einem regelmäßigen Sprint-Ablauf kommt und diese nur von Sprint zu Sprint arbeiten. Dies ist jedoch kein wünschenswerter Zustand und sollte von allen Teammitgliedern (insbesondere vom Product Owner) verhindert werden.

» In beiden Fällen dient das Retrospektive-Meeting als Chance, die Zusammenarbeit besser und effektiver zu gestalten. Während der Meetings wird die Zusammenarbeit kritisch betrachtet und Maßnahmen dazu abgeleitet.

Unsere Standorte

Niederlassung DarmstadtKasinostraße 6064293 DarmstadtTel +49 61 51 – 78 90 0Fax +49 61 51 – 78 90 23 0

Hauptsitz BonnKurfürstenallee 553177 BonnTel +49 228 – 76 36 31 0Fax +49 228 –76 36 31 3

Niederlassung BernBridelstrasse 373008 BernTel +41 31 – 534 07 06Fax +41 31 – 536 69 78

Niederlassung NeussHammfelddamm 641460 NeussTel +49 228 – 76 36 31 0Fax +49 228 –76 36 31 3

Vielen Dank!