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

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…

WARUM?

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.

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

LEAN FORECASTING

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

Vorteile• Wahrscheinlichkeitsbasierte Prognosen:

• Schnell • Billig • Zuverlässig • Entlasten die „echt“ wertschöpfenden

Mitglieder im Team

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

STATISTIK VORWEG

Aufwärmen Teil 1Würfelt mit einem 6er-Würfel.

Sagt eure Ergebnisse laut an!

Aufwärmen Teil 2Würfelt mit zwei 6er-Würfeln.

Sagt die Summen beider Würfel laut an!

Monte Carlo SimuationEin stochastisches Verfahren Sehr häufig durchgeführte Zufallsexperimente Häufig genutzt zur Nachbildung komplexer Prozesse

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

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

Schritt 1

Würfelt 3 mal und schreibt die Summen beider Würfel untereinander

Schritt 2

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

Schritt 3

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

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

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- 1k −1

⎛⎝⎜

⎞⎠⎟

*100

–Troy Magennis

„Wenn ein Messwert sich über die Zeit ändert oder bei jeder Messung anders ist,

ist es eine Verteilung.“

VERTEILUNG (DISTRIBUTION)

Histogramm = visualisierte Verteilung

nach Karl Scotland, http://availagility.co.uk/lego-flow-game/

LEGO FLOW GAME

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

Workflow• Analysieren

• Beschaffen

• Bauen

• Prüfen

• Geliefert

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

Analysieren

10

Zahl

Tür auf Karte

Beschaffen

1. Notiere die Zeit.

2. Finde das Beutelchen mit den passenden Teilen.

3. Hefte es mit der Büroklammer an die Tür.

Beschaffen

10Tüte auf Karte

1:201:20

Zeitstempel

BauenBaue die Lego-Figur entsprechend der Anleitung auf der Tür.

BauenBau es :)

Prüfen1. Ü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

Prüfen

?

10

1:20 3:50

Zweiter Zeit-Stempel

Manager1. Auf die Zeit achten

2. Auf die Prozesseinhaltung achten

3. Daten sammeln • Wie viele Figuren je Status • Zählen und alle 30s aufschreiben

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

Flussbasierte Arbeit• Besprecht euch als Team.

• Markiert eure Arbeitsstationen

• Ihr arbeitet kontinuierlich, wir unterbrechen gelegentlich für Systemverbesserungen (Inspect & Adapt)

• Start!

5 min Timebox

Debrief Lego Flow• Beobachtungen? Überraschungen?

• Seid ihr „in den Fluss“ gekommen? Wann?

• Begriffe:

• Durchlaufzeit (lead time)

• WIP (Work In Progress)

• Durchsatz (throughput)

„Anforderung“ benutzt als

Epic / User Story / Feature / MMF

die „Abarbeitungseinheit“ im System

–Troy Magennis

„Prognosen sind Antworten auf Fragen zu Ereignissen, die noch nicht eingetreten sind.“

PROGNOSE (Forecast)

Frage 1: Wie lange dauert die Umsetzung von Anforderungen?

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

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%

Durchschnitt

50% dermöglichenErgebnisse

50% dermöglichenErgebnisse

50%

Beware of this animal!

Durchschnitt, Mittelwert Average, Mean

Frage• Wie sieht eine typische Verteilung von

Durchlaufzeiten in Software-Entwicklungsprojekten aus?

• Und wie bei IT Operations Teams?

Gleichbleibende Verteilung, nicht gleich groß!

Weibull Lead Time Verteilungen

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

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% kleinerin Operations)

Weibull Lead Time Verteilungen

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

Voraussetzungen• Stabiles System - wir glauben die

Verteilung der Anforderungen bleibt in etwa stabil

• In der Verteilung gibt es nur eine „Spitze“ (Modus, engl. mode)

Praktische TippsDurchlaufzeit = Differenz zweier Zeitstempel

Auf physischen Boards: Datumsstempel benutzen

Excel: Histogramme über den Umweg von Klassen bauen: Intervalle bilden, ZÄHLENWENN()

Wert Percen(le10  % 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)

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)

Anza

hl Vo

rkom

men

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

Anza

hl

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'Vorko

mmen

'

Lead'Time'in'Tagen'

Bugs'

Bugs"

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'Vorko

mmen

'

Lead'0me'in'Tagen'

Stories'

Stories"

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.

Frage 2: Wann ist das erwartete Projektende?

Einfach!

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

Durchsatz-Prognose mit Monte Carlo Simulation

basierend auf den Daten der vorherigen Folie

Praktische TippsTrick: 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/

Phase im Projekt beachten -> S-Curve

S-CurveQuelle: Project Planning using Little's Law (Dimitar Bakardzhiev)

Ausblick Weiterführende Fragen

Wieviel Kapazität für welchen Arbeitstyp?

Wie hoch ist der Durchsatz?

Auswirkungen von Verbesserungen der Durchlaufzeit

Wie viele Teams brauchen wir?

Was wir benötigen1. Lead Time Verteilung:

• Ist bekannt

• Single Mode - in Klassen unterteilt (s.u.)

• Wir glauben die Verteilung bleibt stabil

2. Anforderungen sind identifiziert und klassifiziert

• 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 = WIPDurchlaufzeit throughput = WIP

lead time

Mit auf den Weg….

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

–George E. P. Box

„Essentially, all models are wrong, but some are useful“

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

historischeDaten

Danke für eure Aufmerksamkeit!

• Susanne BartelSusanne@flow.hamburg

• Twitter @projectzone

• http://flow.hamburg

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

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

Backup

FlusseffizienzFlusseffizienz = 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&To

tal&Cycle&Tim

e&

Pa.ern:&Total&Cycle&Time&In Software- Entwicklungs- Projekten liegt die Flusseffizienz in der Regel bei max. 15%-20%.