SlideShare ist ein Scribd-Unternehmen logo
1 von 36
Metrics we can gain from our (Kanban)
System and what we can learn from it…
Martin Putz | Agile Coach | martin.putz0@gmail.com
Metriken
Effective measurement and visualization provide better
insight.
Better insight leads to better decisions.
Better decisions lead to better outcomes.
Larry Maccherone
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
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 .
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?“
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
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.
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?
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?“
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
Produktivität| “Velocity”
Metrik: Velocity („Points per Week“).
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.
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?“
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.
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.
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.
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?“
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
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
Continuous Forecasting
Forecasting is about answering the right questions, to a
transparent degree of certainty, with as little effort as
possible.
Troy Magennis
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?
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%
Continuous Forecasting (3)
Scope = 146
Observed values = {2, 2, 5, 15,
8, 2, 7}
Min = 2
Mean = 5.85
Max = 15
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
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! 
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)
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.
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)
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).
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
Forecast Agile Project or Feature Spreadsheet (Troy Magennis).
http://focusedobjective.com/forecast_agile_project_spreadsheet/
~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
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
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%
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.
Fragen?
Martin Putz | Agile Coach | martin.putz0@gmail.com

Weitere ähnliche Inhalte

Ähnlich wie Metrics we can gain from our (Kanban) system and what we can learn from ..

Scrum Workshop
Scrum WorkshopScrum Workshop
Scrum Workshopmrdoubleb
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererTobias Schlüter
 
So bestimmen Sie den Reifegrad Ihres PMO, Projekt- und Ressourcenmanagements
So bestimmen Sie den Reifegrad Ihres PMO, Projekt- und RessourcenmanagementsSo bestimmen Sie den Reifegrad Ihres PMO, Projekt- und Ressourcenmanagements
So bestimmen Sie den Reifegrad Ihres PMO, Projekt- und RessourcenmanagementsAnnaPauels
 
Exploratives Testen – ein Überblick und Praxisbeispiele
Exploratives Testen – ein Überblick und PraxisbeispieleExploratives Testen – ein Überblick und Praxisbeispiele
Exploratives Testen – ein Überblick und PraxisbeispieleSven Schirmer
 
Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - ...
Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - ...Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - ...
Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - ...QAware GmbH
 
Wie steigere ich die Effizienz und Zufriedenheit meiner Mitarbeiter
Wie steigere ich die Effizienz und Zufriedenheit meiner MitarbeiterWie steigere ich die Effizienz und Zufriedenheit meiner Mitarbeiter
Wie steigere ich die Effizienz und Zufriedenheit meiner MitarbeiterThomas Jenewein
 
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördernAgile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördernSascha Böhr
 
20191113 dev ops und continuous delivery_testautomatisierung ist trumpf
20191113 dev ops und continuous delivery_testautomatisierung ist trumpf20191113 dev ops und continuous delivery_testautomatisierung ist trumpf
20191113 dev ops und continuous delivery_testautomatisierung ist trumpfStefan Jobst
 
Projektportfoliomanagement: So steuern Sie Ihr Portfolio richtig mit Berichte...
Projektportfoliomanagement: So steuern Sie Ihr Portfolio richtig mit Berichte...Projektportfoliomanagement: So steuern Sie Ihr Portfolio richtig mit Berichte...
Projektportfoliomanagement: So steuern Sie Ihr Portfolio richtig mit Berichte...AnnaPauels
 
Projektmanagement 200420
Projektmanagement 200420Projektmanagement 200420
Projektmanagement 200420Claus Brell
 
DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes QAware GmbH
 
Lean and Agile Coffee Nov. 2015
Lean and Agile Coffee Nov. 2015Lean and Agile Coffee Nov. 2015
Lean and Agile Coffee Nov. 2015Michael Rumpler
 
Software-Tests in PHP-Anwendungen
Software-Tests in PHP-AnwendungenSoftware-Tests in PHP-Anwendungen
Software-Tests in PHP-AnwendungenGjero Krsteski
 
MURCS - Wir machen jetzt Scrum (OOP 2017)
MURCS - Wir machen jetzt Scrum (OOP 2017)MURCS - Wir machen jetzt Scrum (OOP 2017)
MURCS - Wir machen jetzt Scrum (OOP 2017)Ulf Mewe
 
OptaPlanner hilft bei verteilten Schulstandorten
OptaPlanner hilft bei verteilten SchulstandortenOptaPlanner hilft bei verteilten Schulstandorten
OptaPlanner hilft bei verteilten SchulstandortenTorsten Fink
 
Scrum in Zahlen
Scrum in ZahlenScrum in Zahlen
Scrum in ZahlenSonja Uhl
 

Ähnlich wie Metrics we can gain from our (Kanban) system and what we can learn from .. (20)

Scrum Workshop
Scrum WorkshopScrum Workshop
Scrum Workshop
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für Programmierer
 
So bestimmen Sie den Reifegrad Ihres PMO, Projekt- und Ressourcenmanagements
So bestimmen Sie den Reifegrad Ihres PMO, Projekt- und RessourcenmanagementsSo bestimmen Sie den Reifegrad Ihres PMO, Projekt- und Ressourcenmanagements
So bestimmen Sie den Reifegrad Ihres PMO, Projekt- und Ressourcenmanagements
 
Exploratives Testen – ein Überblick und Praxisbeispiele
Exploratives Testen – ein Überblick und PraxisbeispieleExploratives Testen – ein Überblick und Praxisbeispiele
Exploratives Testen – ein Überblick und Praxisbeispiele
 
Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - ...
Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - ...Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - ...
Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - ...
 
Wie steigere ich die Effizienz und Zufriedenheit meiner Mitarbeiter
Wie steigere ich die Effizienz und Zufriedenheit meiner MitarbeiterWie steigere ich die Effizienz und Zufriedenheit meiner Mitarbeiter
Wie steigere ich die Effizienz und Zufriedenheit meiner Mitarbeiter
 
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördernAgile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
 
20191113 dev ops und continuous delivery_testautomatisierung ist trumpf
20191113 dev ops und continuous delivery_testautomatisierung ist trumpf20191113 dev ops und continuous delivery_testautomatisierung ist trumpf
20191113 dev ops und continuous delivery_testautomatisierung ist trumpf
 
Projektportfoliomanagement: So steuern Sie Ihr Portfolio richtig mit Berichte...
Projektportfoliomanagement: So steuern Sie Ihr Portfolio richtig mit Berichte...Projektportfoliomanagement: So steuern Sie Ihr Portfolio richtig mit Berichte...
Projektportfoliomanagement: So steuern Sie Ihr Portfolio richtig mit Berichte...
 
OE Award 2010
OE Award 2010OE Award 2010
OE Award 2010
 
Murcs
MurcsMurcs
Murcs
 
Projektmanagement 200420
Projektmanagement 200420Projektmanagement 200420
Projektmanagement 200420
 
DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes
 
Lean and Agile Coffee Nov. 2015
Lean and Agile Coffee Nov. 2015Lean and Agile Coffee Nov. 2015
Lean and Agile Coffee Nov. 2015
 
Software-Tests in PHP-Anwendungen
Software-Tests in PHP-AnwendungenSoftware-Tests in PHP-Anwendungen
Software-Tests in PHP-Anwendungen
 
OOP2017: Scrum statt Murcs - Agile Software-Entwicklung
OOP2017: Scrum statt Murcs - Agile Software-EntwicklungOOP2017: Scrum statt Murcs - Agile Software-Entwicklung
OOP2017: Scrum statt Murcs - Agile Software-Entwicklung
 
MURCS - Wir machen jetzt Scrum (OOP 2017)
MURCS - Wir machen jetzt Scrum (OOP 2017)MURCS - Wir machen jetzt Scrum (OOP 2017)
MURCS - Wir machen jetzt Scrum (OOP 2017)
 
Definition of Ready
Definition of ReadyDefinition of Ready
Definition of Ready
 
OptaPlanner hilft bei verteilten Schulstandorten
OptaPlanner hilft bei verteilten SchulstandortenOptaPlanner hilft bei verteilten Schulstandorten
OptaPlanner hilft bei verteilten Schulstandorten
 
Scrum in Zahlen
Scrum in ZahlenScrum in Zahlen
Scrum in Zahlen
 

Metrics we can gain from our (Kanban) system and what we can learn from ..

  • 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
  • 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

Hinweis der Redaktion

  1. CFDA cumulative flow diagram is a tool used in queuing theory. It is an area graph that depicts the quantity of work in a given state, showing arrivals, time in queue, quantity in queue, and departure. Der Work in Progress ist der beste Indikator dafür, wie stabil ein System ist. Fehlende Stabilität ist nämlich im Großteil der Fälle das vordringlichste Problem, gleichzeitig ist Stabilität aber auch die Voraussetzung für das Forecasting. Jede Schätzung ist für die sprichwörtlichen Fische, wenn ständig neue Arbeit begonnen wird, wenn die ursprüngliche Arbeit noch nicht abgeschlossen ist. Und zweitens steigt die Durchlaufzeit und sinkt der Durchsatz, wenn zu viel Arbeit ins System gelassen wird. TODO Eine der wichtigsten Voraussetzungen für ein stabiles System ist, dass der Work in Progress limitiert ist.