Foliensatz zum Vortrag "Lean Forecasting / Beyond Estimation" bei der PMI Agile CoP am 16. März 2015.

1. Lean Forecasting, Beyond Estimation
@ PMI Agile CoP Hamburg,
16. März 2015
Susanne Bartel
http://flow.hamburg

2. Inhalt
• Teil 1
• Warum das große Interesse am Thema?
• Was ist Lean Forecasting / Beyond Estimation?
• Kleine Statistik-Auffrischung :)
• Teil 2
• Lego Flow Game (und kurze Pause)
• Teil 3
• Konkrete Fragestellungen - Theorie und Praxis
1. Wie lange dauert die Umsetzung von Anforderungen?
2. Wann ist das erwartete Projektende?
3. Weiterführende Fragen
• Zu guter letzt…

4. WARUM?

5. Häufig schwache Korrelation zwischen
Story Points und Aufwand oder Durchlaufzeit
Hohe Aufwände für Schätzungen
und Planungen
Vielfach durch Studien belegt, wie
schlecht wir im Schätzen in der Software-
Industrie sind.

6. 0,00#
5,00#
10,00#
15,00#
20,00#
25,00#
30,00#
35,00#
40,00#
0# 1# 2# 3# 4# 5# 6#
Story&Points&zu&Lead&1me&[d]&
Lead#.me#[d]#
Faktor: 0,3
1,0$
10,0$
100,0$
1000,0$
10000,0$
0$ 2$ 4$ 6$ 8$ 10$ 12$ 14$ 16$
Aufwand$(Stunden)$ Linear$(Aufwand$(Stunden))$ Linear$(Aufwand$(Stunden))$
Faktor:0,36
Beispiel-Korrelationen
0"
20"
40"
60"
80"
100"
120"
0" 1" 2" 3" 4" 5" 6"
Story&Punkte&zu&Aufwand& Faktor:0,2

7. LEAN FORECASTING

8. Lean / „Probabilistic“ Forecasting
Projektion historischer Daten in die Zukunft zur
Beantwortung planerischer Fragen
Unter Beachtung von Wahrscheinlichkeiten
Unter Nutzung von Modellen
„Klassische“ Planung: Schätzen zukünftiger Ereignisse

9. Vorteile
• Wahrscheinlichkeitsbasierte Prognosen:
• Schnell
• Billig
• Zuverlässig
• Entlasten die „echt“ wertschöpfenden
Mitglieder im Team

10. Beyond
Estimation
#NoEstimation
Lean Forecasting zur Prognose
von Durchlaufzeiten und
Durchsätzen
Macht die Verwendung von
Story Points überflüssig
Angewendete Praktik besonders
in reifen agilen
Teams

11. STATISTIK VORWEG

12. Aufwärmen
Teil 1
Würfelt mit einem
6er-Würfel.
Sagt eure
Ergebnisse laut an!

13. Aufwärmen
Teil 2
Würfelt mit zwei
6er-Würfeln.
Sagt die Summen
beider Würfel laut
an!

14. Monte Carlo
Simuation
Ein stochastisches Verfahren
Sehr häufig durchgeführte
Zufallsexperimente
Häufig genutzt zur Nachbildung
komplexer Prozesse

15. Übung
„Bereiche“
Teilt euch in 3
Gruppen auf.
Bestimmt einen
Würfler, dieser darf
die Würfel den anderen
nicht zeigen.

16. Die Situation
Ihr nehmt Stichproben,
um einen Bereich zu
ermitteln.
D.h. wir suchen die
MIN und MAX Werte

17. Schritt 1
Würfelt 3 mal und
schreibt die
Summen beider
Würfel
untereinander

18. Schritt 2
Sortiert die Zahlen
nach ihrer Größe.
Mit welcher % liegt
die vierte Zahl in
diesem Bereich?

19. Schritt 3
Würfelt noch 8
mal und notiert
eure Ergebnisse.
Was ist MIN und
MAX?

20. Schritt 4
Vergleicht euer MIN
und MAX mit den
tatsächlichen Werten
anhand der Würfel.
Beobachtungen?

21. Vorhersagewahr-
scheinlichkeit
abhängig von
Probenzahl
(Keine Duplikate, gleich
verteilt, zufällige Proben)
Anzahl vorhandener
Proben
Wahrscheinlichkeit, dass nächste
Probe innerhalb des Bereichs
liegt
3 50 %
4 67 %
5 75 %
6 80 %
7 83 %
8 86 %
9 88 %
10 89 %
11 90 %
12 91 %
13 92 %
14 92 %
15 93 %
16 93 %
17 94 %
18 94 %
19 94 %
20 95 %
Die benötigte Stichprobengröße
ist deutlich kleiner als wir denken
Wahrscheinlichkeit = 1-
1
k −1
⎛
⎝⎜
⎞
⎠⎟ * 100

22. –Troy Magennis
„Wenn ein Messwert sich über die Zeit
ändert oder bei jeder Messung anders ist,
ist es eine Verteilung.“
VERTEILUNG
(DISTRIBUTION)

23. Histogramm =
visualisierte Verteilung

24. nach Karl Scotland, http://availagility.co.uk/lego-flow-game/
LEGO FLOW GAME

25. Euer Ziel
• Setzt so viele Lego-Figuren wie
möglich anhand der Anleitung
zusammen und liefert sie!
• In der gegebenen Reihenfolge
• Arbeitet als Team zusammen

26. Workflow
• Analysieren
• Beschaffen
• Bauen
• Prüfen
• Geliefert

27. Analysieren
1. Finde die richtige Tür.
2. Nimm eine Karteikarte.
3. Schreibe die Nummer der Tür auf die Karte.
4. Lege die Tür auf die Karte, Instruktionen
oben.

28. Analysieren
10
Zahl
Tür auf Karte

29. Beschaffen
1. Notiere die Zeit.
2. Finde das Beutelchen mit den
passenden Teilen.
3. Hefte es mit der Büroklammer an die
Tür.

30. Beschaffen
10
Tüte auf Karte
1:201:20
Zeitstempel

31. Bauen
Baue die Lego-Figur entsprechend der
Anleitung auf der Tür.

32. Bauen
Bau es :)

33. Prüfen
1. Überprüfe dass die Figur
• GENAU dem Bild entspricht
• ROBUST ist
2. Wenn ja, dann akzeptiere
• Notiere die Zeit!
• LIEFERE zum Marktplatz!
3. Wenn nicht, zurück an die entsprechende Station

34. Prüfen
?
10
1:20 3:50
Zweiter Zeit-
Stempel

35. Manager
1. Auf die Zeit achten
2. Auf die Prozesseinhaltung achten
3. Daten sammeln
• Wie viele Figuren je Status
• Zählen und alle 30s aufschreiben

36. Manager
00:30 01:00 01:30 2:00 2:30 3:00 3:30 4:00 4:30 5:00 5:30 6:00
Analysis
2 1
Supply
3 2
Build
5 6
Accept
1 2
Done
2 4
Alle 30s zählen je
Arbeitsstation
„Done“ sollte niemals
weniger werden, muss
ansteigen

37. Flussbasierte Arbeit
• Besprecht euch als Team.
• Markiert eure Arbeitsstationen
• Ihr arbeitet kontinuierlich, wir unterbrechen gelegentlich
für Systemverbesserungen (Inspect & Adapt)
• Start!
5 min Timebox

38. Debrief Lego Flow
• Beobachtungen? Überraschungen?
• Seid ihr „in den Fluss“ gekommen? Wann?
• Begriffe:
• Durchlaufzeit (lead time)
• WIP (Work In Progress)
• Durchsatz (throughput)

40. „Anforderung“ benutzt als
Epic / User Story / Feature / MMF
die „Abarbeitungseinheit“ im System

41. –Troy Magennis
„Prognosen sind Antworten auf Fragen zu
Ereignissen, die noch nicht eingetreten sind.“
PROGNOSE
(Forecast)

42. Frage 1:
Wie lange dauert die
Umsetzung von
Anforderungen?

43. Durchlaufzeit, „Lead Time“
• In Kanban: Die Zeitdauer, in der eine Anforderung von der
ersten limitierten Spalte („Zusagepunkt“) bis zur letzten
Spalte „wandert“
• Lego Flow: Beginn „Liefern“ bis zur erfolgreichen Abnahme
• Differenz zwischen 2 Zeitstempeln
• In Software-Entwicklungs-Teams typischerweise Start der
Implementierung bis „Done“ oder Release
• i.d.R. OHNE Analyse / Konzipierung

44. Beispiel: Durchlaufzeiten-
Verteilung in Lego Flow Game
Beobachtungen?
00:30:00$ 01:00:00$ 01:30:00$ 02:00:00$ 02:30:00$ 03:00:00$ 03:30:00$ 04:00:00$ 04:30:00$ 05:00:00$ 03:40:00$
00:00:00$ 00:30:00$ 01:00:00$ 01:30:00$ 02:00:00$ 02:30:00$ 03:00:00$ 03:30:00$ 04:00:00$ 04:30:00$ 05:00:00$
SUMME$ 1$ 5$ 5$ 4$ 8$ 5$ 2$ 3$ 1$ 1$ 0$
0$
1$
2$
3$
4$
5$
6$
7$
8$
9$
Lego%Flow%Lead%Times%Histogramm%

45. Durchschnitt
50% der
möglichen
Ergebnisse
50% der
möglichen
Ergebnisse
50%

46. Beware of this animal!
Durchschnitt, Mittelwert
Average, Mean

47. Frage
• Wie sieht eine typische Verteilung von
Durchlaufzeiten in Software-
Entwicklungsprojekten aus?
• Und wie bei IT Operations Teams?

48. Gleichbleibende Verteilung,
nicht gleich groß!

49. Weibull
Lead Time Verteilungen
Typische Verteilungen in SW-Projekten (Magennis)
siehe auch Lead Time Forecasting Cards von Alexei Zheglov

50. Mode:
an was sich
Leute
gut erinnern
(Achtung!
üblicherweise
nur 18-28%
Wahrscheinlichkeit!)
Median:
zur kontinuierlichen
Überprüfung des
Vorhersage-Modells
Control Limit:
für SLA’s
80% percentile:
4 von 5 Items
dauern max. so lange
-> Planung
Durchschnitt:
üblicherweise
über dem Median
(bis zu 50% kleiner
in Operations)
Weibull
Lead Time Verteilungen
Typische Verteilungen in SW-Projekten (Magennis)
siehe auch Lead Time Forecasting Cards von Alexei Zheglov

51. Voraussetzungen
• Stabiles System - wir glauben die
Verteilung der Anforderungen bleibt in etwa
stabil
• In der Verteilung gibt es nur eine
„Spitze“ (Modus, engl. mode)

52. Praktische
Tipps
Durchlaufzeit = Differenz zweier
Zeitstempel
Auf physischen Boards:
Datumsstempel benutzen
Excel: Histogramme über den
Umweg von Klassen bauen:
Intervalle bilden, ZÄHLENWENN()

53. Wert Percen(le
10
% 1:19
20
% 1:46
30
% 2:03
40
% 2:12
50
% 2:25
60
% 2:44
70
% 2:57
80
% 3:24
90
% 3:52
100
% 4:51
1. Werte
sortieren
1:22
2:21
3:05
4:51
3:45
2:29
1:12
3:38
1:55
2:58
2:56
0:57
1:12
1:22
1:41
1:55
2:03
2:11
2:13
2:21
2:29
2:41
2:56
2:58
3:05
3:38
3:45
4:10
4:51
Berechnung von
„Percentile“
(Perzentil, Quantil)
=QUANTIL(Bereich;%Wert)

54. Beispiele
0"
1"
2"
3"
4"
5"
6"
7"
8"
2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32" 200"
0" 2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32"
Bugs%&%Stories%(addi0v)%
Bugs"
Durchlaufzeit (Tage von/bis)
AnzahlVorkommen

55. 0"
1"
2"
3"
4"
5"
6"
7"
8"
2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32" 200"
0" 2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32"
Bugs%&%Stories%(addi0v)%
Bugs"
Durchlaufzeit (Tage
Anzahl
Beispiele
0"
1"
2"
3"
4"
5"
6"
7"
2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32" 200"
0" 2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32"
Anzahl'Vorkommen'
Lead'Time'in'Tagen'
Bugs'
Bu
0"
1"
2"
3"
4"
5"
6"
2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32" 200"
0" 2" 4" 6" 8" 10" 12" 14" 16" 18" 20" 22" 24" 26" 28" 30" 32"
Anzahl'Vorkommen'
Lead'0me'in'Tagen'
Stories'

56. Recap: Durchlaufzeiten-Prognose
• Erlaubt die Prognose auf z.B. Story- oder Task-Ebene
• Vorteile:
• Leicht zu sammelnde Messwerte
• Nutzt historische Daten (komplett oder
Stichproben)
• Folgt bekannten Verteilungsmustern
• Nutzen: Zusagen für einzelne Anforderungen.
Termingerechter Start der Implementierung. Analyse
(z.B. Ausreißer etc.). Basis für weitere Berechnungen.

57. Frage 2:
Wann ist das erwartete
Projektende?
Einfach!

58. Beispiel: Projektdauer
Projektdauer=
Anzahl der Anforderungen(*)
Durchsatz
Wir haben Daten über den Durchsatz unseres Teams „P“:
7, 8, 2, 11, 7, 12 Anforderungen pro Woche.
Wann werden die verbleibenden 100 Anforderungen
umgesetzt sein?
Projektdauer =
100 Anforderungen
7 Anforderungen / Woche
Projektdauer = 100 Wochen / 7
Projektdauer = 15 Wochen
16,70
% 12
33,40
% 11
50,10
% 8
66,80
% 7
83,50
% 7
100,20
% 2
Achtung!
Umgekehrte Reihenfolge
(*) Batch Size

59. Durchsatz-Prognose mit Monte Carlo Simulation
basierend auf den Daten der vorherigen Folie

60. Praktische
Tipps
Trick: Durchsatz aus z.B. Jira:
=KALENDERWOCHE(DateClosed)
dann pivotieren oder Zählenwenn()
Troy Magennis’ Sheet für Monte
Carlo Throughput Forecasting:
http://focusedobjective.com/free-
tools-resources/

61. Phase im Projekt beachten -> S-Curve

62. S-Curve
Quelle:
Project Planning using Little's Law (Dimitar
Bakardzhiev)

63. Ausblick
Weiterführende
Fragen

64. Wieviel Kapazität für welchen
Arbeitstyp?
Wie hoch ist der Durchsatz?
Auswirkungen von
Verbesserungen der
Durchlaufzeit
Wie viele Teams brauchen wir?

65. Was wir benötigen
1. Lead Time Verteilung:
• Ist bekannt
• Single Mode - in Klassen unterteilt (s.u.)
• Wir glauben die Verteilung bleibt stabil
2. Anforderungen sind identifiziert und
klassifiziert

66. • längerfristig stabile Durchschnittswerte!
• Voraussetzungen:
• Durchschnittliche Output-Rate = durchschnittliche Input-Rate
• Alle angefangene Arbeit wird schließlich beendet und verlässt das System
• Die Menge angefangener Arbeit sollte zu Beginn und Ende des gewählten
Zeitintervalls etwa gleich sein
• Die durchschnittliche Menge angefangener Arbeit (WIP) ist stabil
• In der Berechnung müssen konsistente Einheiten genutzt werden
• siehe auch „Little’s Flaw“ (Dave Vacanti)
Little’s Law
Lieferrate =
WIP
Durchlaufzeit
throughput =
WIP
lead time

67. Mit auf den Weg….

68. Brauche ich dazu ein Kanban-System?
• Nein, all diese Techniken können auch von agilen oder
„klassischen“ Teams angewendet werden.
• Aber: Ein Kanban-System hilft, die
Vorhersagegenauigkeit (predictability) zu verbessern:
• Verschiedene Arbeitstypen / Serviceklassen, um
mehrere Modes zu vermeiden
• Ist Hilfsmittel für kontinuierliche Verbesserung
(Zuverlässigkeit, Durchsatz, etc.)

69. –George E. P. Box
„Essentially, all models are wrong, but
some are useful“

70. Kontinuierliche Anpassung, aktives Steuern
Prognose
erstellen
Modell aufstellen /
anpassen
Kontinuierliche Überprüfung der Gültigkeit des Modells mit
Anpassung der Vorhersage— ermöglicht aktives Steuern!
Überprüfung der
Hypothesen
historische
Daten

71. Danke für eure Aufmerksamkeit!
• Susanne Bartel
Susanne@flow.hamburg
• Twitter @projectzone
• http://flow.hamburg

72. Credits und Referenzen
• Basiert auf der Arbeit von Troy Magennis, David J. Anderson, Alexei Zheglov,
and Dan Brown in diesem Bereich. Siehe auch deren Blogs.
• German Tanks: http://www.spiegel.de/wissenschaft/mensch/rechentrick-
der-alliierten-wie-seriennummern-die-nazi-industrie-verrieten-a-728211.html
• Für mehr:
• Twitter: #noestimates
• noestimatesbook.com
• Blogs of the above
• Limited WIP Society

73. Bilder
• Würfel: https://www.flickr.com/photos/dskley/6196133034
• fliegende Würfel: https://www.flickr.com/photos/dskley/6195620885
• Pause: <a href="https://www.flickr.com/photos/finklez/3059185823"
title="Pause - ‫השהיה‬ by Eran Finkle, on Flickr"><img src="https://
farm4.staticflickr.com/3190/3059185823_ce8570bdd2_s.jpg" width="75"
height="75" alt="Pause - ‫/<>“השהיה‬a>
• Wall: https://www.flickr.com/photos/dg_pics/3937990893/
• Umbrella: https://www.flickr.com/photos/dskley/9666364180
• Fragezeichen: https://www.flickr.com/photos/eleaf/2536358399
• Mind the gap: https://www.flickr.com/photos/simone_brunozzi/2643200238/
• Easy: https://www.flickr.com/photos/catharticflux/2484317019/
• Monkey bento: https://www.flickr.com/photos/buzzymelibee/8598689804

74. Backup

75. Flusseffizienz
Flusseffizienz =
Arbeitszeit
(Arbeitszeit +Wartezeit)
Story&/&Feature&Incep0on&
5&Days&
Wai0ng&in&Backlog&
25&days&
System&Regression&Tes0ng&&&Staging&&
5&Days&
Wai0ng&for&Release&Window&
5&Days&
“Ac0ve&Development”&
30&days&
Total&Cycle&Time&
Pa.ern:&Total&Cycle&Time&
In Software-
Entwicklungs-
Projekten
liegt die Flusseffizienz
in der Regel bei
max. 15%-20%.