Große Projekte haben hohes Risiko, geringe Flexibilität und sind schwer zu steuern. Wie zerlegt man Großprojekte in kleinere Teile, die dann stückchenweise lieferbar sind? Diese Präsentation beschreibt das Herangehen in einer komplexen klassischen Projektorganisation, um ein agiles Portfolio-Management zu ermöglichen.

1. Projekte schneiden
Nutzen und Ansatz
Michael Küsters
oder: Wie man ein Projekt in Epics zerlegt

2. Warum sollte man Projekte schneiden?
2
Wir brauchen ein neues
Kundenpflege-System.
Hier ist die Anforderung.
Wird gemacht. Ich melde
mich in 29 Jahren, wenn
es fertig ist.
Große Projekte:
1. Langwierig
2. Hohe Kosten
3. Später Nutzen
4. Gebundene
Kapazitäten
5. Hohes Risiko

3. Was bringt das Schneiden von Projekten?
3
Wir brauchen ein neues
Kundenpflege-System.
Bitte liefert stückweise.
Wird gemacht.
Wir planen quartalsweise,
was wir liefern.
Geschnittene
Projekte:
1. Schnelle Erfolge
2. Jederzeit Einsparungen
denkbar
3. Risikominimierung
4. Kapazitäten leicht
umplanbar
5. Früher Nutzen

4. Wie kann man Projekte schneiden?
4
Was brauchst Du,
damit Du quartalsweise
vorgehen kannst?
Das Projekt muss in einzeln
lieferbare Epics geschnitten sein,
von denen jede einzelne in einem
Quartal machbar ist!

5. Ein Projekt teilt sich in verschiedene Epics
Epic = Abstrakte High-Level Anforderung
5
Wir brauchen ein neues
Kundenpflege-System
Projekt
Ich will Kundendaten
nicht doppelt pflegen!
Ich brauche eine
einheitliche Sicht
auf den Kunden!
Ich hasse die lange
Wartezeit im
Altsystem.
Epics
Verantwortlicher Stakeholder

6. Wie komme ich an Epics?
Schritt 1: Business Epics
6
Was brauchen wir für das
neue Kundenpflege-
System?
Meeting mit Business Stakeholdern
Epic 1:
Ich will Kundendaten
nicht doppelt pflegen. Epic 2:
Ich brauche eine
einheitliche Sicht
auf den Kunden.
Epic 3: Ich hasse die
lange Wartezeit im
Altsystem.

7. Wie komme ich an Epics?
Schritt 2: Technische Enabler-Epics
7
Was ändert sich durch
das neue Kundenpflege-
System?
Enabler 1:
Wir brauchen eine
Continuous Delivery
Pipeline.
Enabler 2:
Wir brauchen eine
neue Datenbank
Enabler 3:
Wir brauchen
Microservices.

8. Enabler 1:
Wir brauchen
Continuous
Delivery
Pipeline.
Epic 3: Ich
hasse die
lange
Wartezeit im
Altsystem.
Epic 2:
Ich will
einheitliche
Sicht auf
Kunden.
Was mache ich mit den Epics?
Schritt 3: Nutzen prüfen
8
Brauchen wir das Epic
wirklich oder ist das ein
Luxus-Problem?
Epic 1:
Ich will
Kundendaten
nicht doppelt
pflegen.
Das kann weg!
Das würde mir 20k
pro Monat sparen!

9. Was mache ich mit den Epics?
Schritt 4: Aufwand schätzen
9
Epic 1:
Ich will
Kundendaten
nicht doppelt
pflegen.
Wie dick ist dieser Brocken? 10 Team-Sprints.

10. Was mache ich mit den Epics?
Schritt 5: Riesenblöcke aufteilen
10
Das dauert länger als ein
Quartal. Kann man das
sinnvoll in Teile spalten?
50
Epic 1.a:
Egal wo ich die Daten
pflege, sie werden
automatisch übergeben.
Epic 1.b:
Es gibt eine einheitliche
Eingabemaske in allen
Prozessen.
Epic 1.c:
Der Kunde kann
Daten selbst
aktualisieren.
Epic 1: (50)
Ich will
Kundendaten
nicht doppelt
pflegen.
Für die neuen Epics wiederholen wir ab Schritt 3

11. Ein Backlog aufbauen
Schritt 6: Reihenfolge festlegen
11
In welcher Reihenfolge gehen
wir das Ganze jetzt an?
E1cE2
E3
En1En2
Backlog
Offen
E1a
E1b
En3
Das Backlog besitzt eine eindeutige Reihenfolge.

12. Ein Release planen
Schritt 7: Roadmap planen
12
Das ist unser Backlog.
Damit haben wir eine
Epic-Roadmap! 12 3068
Q1
(20)
15
12
50
Q2
(20)
Q3
(20)
Später
Backlog
Die Roadmap-Planung betrifft alle verfügbaren
Entwickler-Kapazitäten und somit alle Projekte,
nicht nur ein Projekt!
Projekt
1
Projekt
2
7 25
8

13. Womit schneide ich Projekte kleiner?
13
Ich habe da ein paar
Vorschläge gesammelt …
Beim fachlichen Schnitt geht es um
Nutzen und Ziele. Dort kennen die
Anwender sich am besten aus.
Man kann auch an der Technik
entlang in machbare Blöcke
schneiden. Dabei können Leute
aus der IT helfen.

14. Technik 1: Fachlich schneiden mit
Impact Mapping
14
Beim Impact Mapping
spalte fange ich mit den
Zielen des Projekts an. (1)
Danach frage ich,
welche User dazu
beitragen, dass das
Ziel erreicht wird. (2)
Und zuletzt,
was diesen Leuten
dabei hilft. (3)
1 2 3

15. Technik 2: Fachlich schneiden mit
Story Mapping
15
Beim Story Mapping fange ich
auch mit den Zielen des
Projekts an (1).
Danach frage ich,
welche Teile zum
Ergebnis beitragen
(2).
Und zuletzt,
In welcher
Reihenfolge die
Epics benötigt
werden (3).
1
2
3
Beim Epic Mapping bekommt man weniger Kärtchen als bei
detailliertem Story Mapping - das Prinzip bleibt.

16. Technik 3: Technisch schneiden mit
technischem Splitting
16
Beim technischen Split fange
ich mit dem Zielprodukt des
Projekts an.
Dann stelle ich
nacheinander
bestimmte Fragen
zu Aspekten der
technischen
Umsetzung.
Diese Fragen können am Besten die Leute
beantworten, die sich mit der Technologie auskennen.
1
2
1
2

17. Technik 4: Technisch schneiden mit
FURPS+
17
Bei FURPS+ fange ich mit einem
zu großen fachlichen Epic an.
Die Entwickler
denken über den
technischen
Hintergrund des
Epics nach und
teilen ihn auf.
FURPS+ beschäftigt sich ausschließlich mit der Technologie.

18. 18
Danke fürs Zuhören.