Foliensatz zum Vortrag "Metrics we can gain from our (Kanban) system and what we can learn from ... " bei der Agile Tour Vienna 2017. Abstract des Vortrags In dieser Session wird gezeigt, wie man auf einfache Art und Weise Metriken generieren kann, welche Metriken sinnvollerweise herangezogen werden sollten, und wie diese helfen datenbasierte und somit fundiertere Entscheidungen zu treffen und wie man diese Daten verwenden kann, um das zukünftige Verhalten des Systems zu prognostizieren.

1. Metrics we can gain from our (Kanban)
System and what we can learn from it…
Martin Putz | Agile Coach | martin.putz0@gmail.com

2. Metriken
Effective measurement and visualization provide better
insight.
Better insight leads to better decisions.
Better decisions lead to better outcomes.
Larry Maccherone

3. Metriken und Kontext
2017-01-08
Ende Betriebsferien
2017-02-05
Release Version 1.0
2017-04-11
Release Version 2.0
2017-02-24
Code Review für alle
Work-Items eingeführt
2017-03-19
Bugfix Release
2017-05-14
+1 Tester im Team
2017-04-24
WIP Limits neu!
2017-05-26+
Performance
Issues
Metriken erzählen keine
komplette Story.
Daher empfiehlt es eine
Art „Logbuch“ zu führen.
 Änderungen im
Prozess, Tools, Team-
Setup
 Release-Zeitpunkte
 Besondere
Vorkommnisse

4. Konkurrierende Metriken.
Qualität
„Wie gut?“
Produktivität
„Wie viel?“
Reaktionsfreudigkeit
„Wie schnell?“
Vorhersagbarkeit
„Wie verlässlich?“
Was sind die Kernfragen, mit
denen wir uns auseinander-
setzen sollten?
 Wie gut sind wir in dem, was
wir tun?
 Wie viel davon schaffen wir
(pro Tag, Woche, Monat)?
 Wie schnell (können wir auf
Anforderungen reagieren)?
 Wie verlässlich, d.h. wie
vorhersagbar, ist unser
System?
Idee und weitere Details: Troy Magennis, Doing Team Metrics Right bzw. Larry Maccherone .

5. Konkurrierende Metriken.
Qualität – Wie gut sind wir in
dem, was wir tun?
 Bug Percentage Rate
 Geplante versus Ungeplante
Arbeit (User Stories versus
Bugs)
 Bug/Defect Frequency
Qualität
„Wie gut?“
Produktivität
„Wie viel?“
Reaktionsfreudigkeit
„Wie schnell?“
Vorhersagbarkeit
„Wie verlässlich?“

6. Qualität| Bug Percentage Rate
Metrik: Anteil (%) von
(gefixten) Bugs im Verhältnis
zu User Stories.
Mögliche Ziele:
1. Anteil an Bugs verringern
(ohne Bug-Fixes zu
verzögern/verschieben)
2. Kontinuierliches Bug-
Fixing (konstante Rate)
Mögliche “Seiten-Effekte”:
1. Responsiveness Metriken
steigen, wenn Fokus auf
Bug-Fixing
2. Anzahl Bugs steigt, wenn
Stories höher priorisiert
werden
3. Bugs werden als Stories
verkleidet

7. Qualität| Geplante versus ungeplante Arbeit
Metrik: Vergleich von gefixten
Bugs zu implementierten
Stories.
Ziel:
1. Etwaige Zusammen-hänge
zwischen neuen Features
und Ansteigen der Bugs zu
erkennen
2. Stimmt das Verhältnis
zwischen vorwärts-
gerichteter Entwicklung und
Fehlerbehebung?
Wie jede Metrik spielt auch
hier der Kontext eine Rolle,
etwa ob in den Zeitraum eine
Bug-Fixing Release fällt.

8. Qualität| Bug/Defect Frequency
Metrik: Vergleich gefixte Bugs
zu gefixten Defects.
Bugs … Fehler, die vor der Release des
Produkts gefunden wurden
Defects … Fehler, die nach Produkt-
Release (u.a. vom Kunden) gefunden
wurden.
Ziel:
1. Wie ist der Anteil an
„escaped“ Bugs?
2. Wie gut greifen unsere
Test-Mechanismen?

9. Konkurrierende Metriken.
Produktivität – Wie viele Work-
Items schaffen wir pro Tag,
Woche, Monat?
 Throughput Trend
 Velocity
 % Work-Items (User Stories,
Bugs) in n Tagen
Qualität
„Wie gut?“
Produktivität
„Wie viel?“
Reaktionsfreudigkeit
„Wie schnell?“
Vorhersagbarkeit
„Wie verlässlich?“

10. Produktivität| Throughput Trend
Metrik: Throughput (im Sinne von
Anzahl von Work-Items) pro Woche
Ziel:
1. Ein konsistent erreichbares Niveau
zu finden
2. Erhöhung des Throughputs über
die Zeit
Mögliche “Seiten-Effekte”:
1. „Vorschnelles“ Schließen von
Stories – erhöht die Bug-Frequenz
2. Mehr Arbeit wird begonnen als
fertiggestellt
3. Erhöhung durch „künstliches“
Story-Splitting

11. Produktivität| “Velocity”
Metrik: Velocity („Points per Week“).

12. Produktivität | % abgeschlossene Stories in n Tagen
Basierend auf der Lead-Time können
wir berechnen, welcher Anteil an
Work-Items (hier User Stories) in
welchem Zeitraum abgeschlossen
wurde.
Ziel: diese Metrik könnte eine Basis
für ein Service Level Agreement
darstellen.
„Mit einer Wahrscheinlichkeit von
85% wird eine Story innerhalb 13
Tagen - nachdem sie auf dem Board
erscheint - abgeschlossen“.
Erfordert eine managed Input-
Queue.

13. Konkurrierende Metriken.
Reaktionsfreudigkeit – Wie
schnell können wir reagieren?
 Cycle Time bis zur
Fertigstellung
 Lead Time (oder Cycle Time)
Histogramm
 Alter von Work-Items
Qualität
„Wie gut?“
Produktivität
„Wie viel?“
Reaktionsfreudigkeit
„Wie schnell?“
Vorhersagbarkeit
„Wie verlässlich?“

14. Responsiveness | Cycle Time bis zur Fertigstellung
Metrik: Responsiveness wird als der
Median (blaue Linie) der “Time in
Progress” über alle Work-Items, die
in einer Kalenderwoche
fertiggestellt werden, gemessen.
Minimum, die 25% bzw. 75%
Perzentilen und Maximum dienen
als Maß für die Variabilität.
Ziel:
1. Die „Time in Progress“ (= Cycle
Time) für fertiggestellte Items
zu verstehen
2. nach Wegen zu suchen, die
Cycle Time und Variabilität zu
reduzieren.

15. Responsiveness | Cycle time (Histogramm)
Metrik: Histogramm der Cycle Time
(Time in Process). Wie viele Stories
werden in wie vielen Tagen fertig.
Ziel:
1. Bild über die Time in Process zu
entwickeln
2. Basis für Analyse von
Ausreißern, um die Cycle Time
(85% Perzentile) zu reduzieren.

16. Responsiveness | Alter von Work-Items
Metrik: Alter der nicht-
abgeschlossenen Work-Items
(in Kalendertagen)
1. Wie lange sind die Work-
Items offen, d.h. wie lange
sind sie schon im Prozess?
2. Vergessen wir auf
(wichtige) Aufgaben?
Kann als Kontroll-Maß für
Lead- bzw. Cycle Time
herangezogen werden, die ja
nur die Time-in-Process für
abgeschlossene Items misst.

17. Konkurrierende Metriken.
Vorhersagbarkeit – wie
verlässlich funktioniert unser
System? Wie hoch ist die
Variabilität?
 Net Flow
 Work in Progress - Cumulative
Flow Diagram (CFD)
 Stabilität von Throughput
(CoV)*
Qualität
„Wie gut?“
Produktivität
„Wie viel?“
Reaktionsfreudigkeit
„Wie schnell?“
Vorhersagbarkeit
„Wie verlässlich?“

18. Vorhersagbarkeit – Net Flow
Metrik: Net-Flow pro Woche.
Berechnet aus der Differenz
der fertiggestellten Work-
Items und der begonnen
Work-Items.
Ziel:
1. Stop starting – start
finishing!
2. Mögliche Impediments
erkennen, die einer
Fertigstellung von Arbeit
entgegenstehen

19. Vorhersagbarkeit| Work in Progress
CFD zeigt die Anzahl an Work-item
pro Status und ist ein Indikator für
die System-Stabilität.
source: Gaetano Mazzanti

20. Continuous Forecasting
Forecasting is about answering the right questions, to a
transparent degree of certainty, with as little effort as
possible.
Troy Magennis

21. Continuous Forecasting (1)
Scope = 146
Observed values = {2, 2, 5, 15,
8, 2, 7}
Min = 2
Mean = 5.85
Max = 15
Möglicherweise würde man auf Basis
des Durchschnitts eine Prognose über
die Projektdauer anstellen.
Ist das eine gute Wahl?
Sollten wir optimistischer oder
pessimistischer sein?

22. Continuous Forecasting (2)
Alternativer Ansatz: Monte Carlo
Simulation.
Simulation: ‘Single Feature
Forecast Spreadsheet’ von Troy
Magennis.
Typischerweise gibt man zu optimistische Prognosen ab, wenn man den Mittelwert
verwendet. Auch der Median ist nur bedingt geeignet - Think in percentiles instead.
85%
50%

23. Continuous Forecasting (3)
Scope = 146
Observed values = {2, 2, 5, 15,
8, 2, 7}
Min = 2
Mean = 5.85
Max = 15

24. Continuous Forecasting (4)
Scope = 146
Observed values = {2, 2, 5, 15,
8, 2, 7, 3, 4, 4, 4}
Min = 2
Mean = 5.09 (5.85)
Max = 15

25. Continuous Forecasting (5)
Scope = 146
Observed values = {2, 2, 5, 15,
8, 2, 7, 5, 9, 7, 8}
Min = 2
Mean = 6.36 (5.85)
Max = 15
Quite a difference between these two scenarios. But, forecasting is no effort! 

26. Continuous forecasting (Velocity)(6)
Release Date 28.06.2017
Story-Count 40
Points 84
Duration 100
Throughput Points
1 1
3 2
4 11
1 1
5 9
3 5
Probability Weeks Date
90% 18 14.7
85% 17 7.7
80% 16 30.6
75% 16 30.6
Resultat (Throughput [40-42 Stories]
Resultat (Velocity [Scope 80-86])
Probability Weeks Date
90% 22 11.8
85% 21 4.8
80% 20 28.7
75% 20 28.7
Simulation Input (Daten aus vorheriger
Release)

27. Ein paar Forecasting Tipps (1)
1. In Perzentilen denken – unsere Entwicklungsprozesse verlaufen nicht linear.
2. Den organisatorischen Overhead mitberücksichtigen (Wie lange dauert es, um ein „Hello World“ zum
Kunden deployen?).
3. Besser mehr Zeit darauf verwenden, das
Team zu fragen „was kann schiefgehen?“ als
mit der Frage „wie lange wird es dauern?“.
Risiken (z.B. Performance Issues, externer
Partner liefert verspätet etc.) haben
typischerweise einen höheren Einfluss als
ungenaue Schätzparameter.

28. 4. Kein Fertigstellungsdatum forecasten, sondern besser die Dauer zu prognostizieren. Typischerweise hat man
nicht die volle Kontrolle über das tatsächliche Startdatum.
 Projekt ist noch nicht freigegeben, Stories sind noch nicht fertig
 Startdatum verschiebt sich aufgrund von Abhängigkeiten zu einem anderen Projekt, das verzögert ist
 Team ist noch nicht vollzählig bzw. es fehlen noch Rollen im Team
 Das Development Environment ist noch nicht fertig
 …
5. Parallelisierbarkeit nicht überschätzen
6. Scope-Increase berücksichtigen
 Split
 Neu-entdeckter Scope
 Zusätzliche Requirements, Features
 …
7. Welches Modell passt? Durch “Back Testing” – ein Experiment, in dem man historische Daten-Samples in das
Forecasting Model füttert und dann die Forecast Ergebnisse mit dem tatsächlich erzielten End- Datum
vergleicht.
Ein paar Forecasting Tipps (2)

29. 8. Story Points oder Throughput? It depends ;)
Ein paar Forecasting Tipps (3)
Pearson Correlation Coefficient liegt bei ca. 0,77 (bei einer
Signifikanz von < 0,000000002), d.h. es gibt eine hohe Korrelation
zwischen den Werten (und der extrem kleine F Wert sagt auch
aus, dass das nicht zufällig ist).
Pearson Correlation Coefficient liegt bei ca. 0,41
(bei einer Signifikanz von < 0,0072).

30. Forecasting & Simulation Tools
Eine kleine Auswahl …
Forecast Agile Project or Feature Spreadsheet by Troy Magennis
Free Microsoft Excel bzw. Google Sheets.
http://focusedobjective.com/forecast_agile_project_spreadsheet/
Project Planning Using Monte Carlo Simulation by Dimitar Bakardzhiev
Free Microsoft Excel Sheets.
https://de.slideshare.net/dimiterbak/noestimates-project-planning-using-monte-carlo-simulation
http://modernmanagement.bg/data/SIPs_MonteCarlo_FVR.xlsx
http://modernmanagement.bg/data/High_Level_Project_Planning.xlsx

31. Forecast Agile Project or Feature Spreadsheet (Troy Magennis).
http://focusedobjective.com/forecast_agile_project_spreadsheet/

32. ~60% Time
~90% Work ~20% Time
~5% Work
~20% Time
~5% Work
Project Planning Using Monte Carlo Simulation by Dimitar Bakardzhiev
Referenz-Klassen Forecasting für ein spezifisches Projekt

33. Project Planning Using Monte Carlo Simulation by Dimitar Bakardzhiev
Task 1
Task 2
Task 3
Task 4
Task 4
Task 6
Task 7
Task 8
T = Cycle Time [Task 1] + ∑Takt-time[Task 2…Task n]
𝑇𝑇 =
𝑇
𝑁
T … Projektlaufzeit
N … Anzahl an Work-Items
𝑇𝑇 … Takt Time

34. Project Planning Using Monte Carlo Simulation by Dimitar Bakardzhiev
https://de.slideshare.net/dimiterbak/noestimates-project-planning-using-monte-carlo-simulation
http://modernmanagement.bg/data/SIPs_MonteCarlo_FVR.xlsx
http://modernmanagement.bg/data/High_Level_Project_Planning.xlsx
N1 *
+
N2 * N3 *
+ =
85%

35. Special Thanks
My special thanks go to Troy Magennis from Focus Objective for his inspiring ideas, grand tools and
valuable resources.
About Focused Objective
“Focused Objective LLC offers tools, training and expert
advice on metrics, risk and forecasting. We have more
advanced tools to model Agile teams and projects that help
analyze staffing options and risk, and a proven track record of
positive results. We are always happy to discuss next steps
and training opportunities should this tool prove useful.“
See our website: http://www.focusedobjective.com or email
me at troy.magennis@focusedobjective.com.

36. Fragen?
Martin Putz | Agile Coach | martin.putz0@gmail.com