1.
Wie sieht eine „ideale“ Sprintplanung aus?
JIN-YOUNG LEE
SCRUM in der Anwendung
– Sprint Planung –
OKTOBER 2015

2.
2
Scrum in der Anwendung – Product Backlog
Ziele 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
3
Sprintplanung

4.
4
Scrum in der Anwendung – Product Backlog
Scrum 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

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

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

7.
Scrum in der Anwendung – Sprint Planung
7
Releaseplanung

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

9.
Releaseplanung vs. Sprintplanung
Entwicklung R1
Entwicklung R1
Entwicklung R1
Release 1 *
Test R1
Go Live R1
Entwicklung R2
Entwicklung 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
10
Zusammenfassung

11.
Scrum in der Anwendung – Product Backlog
Zusammenfassung
» 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.
11

12.
Unsere Standorte
Niederlassung Darmstadt
Kasinostraße 60
64293 Darmstadt
Tel +49 61 51 – 78 90 0
Fax +49 61 51 – 78 90 23 0
Hauptsitz Bonn
Kurfürstenallee 5
53177 Bonn
Tel +49 228 – 76 36 31 0
Fax +49 228 –76 36 31 3
Niederlassung Bern
Bridelstrasse 37
3008 Bern
Tel +41 31 – 534 07 06
Fax +41 31 – 536 69 78
Niederlassung Neuss
Hammfelddamm 6
41460 Neuss
Tel +49 228 – 76 36 31 0
Fax +49 228 –76 36 31 3
Vielen Dank!