Vortrag Scrum User Group Graz vom 5.4.2017

1. #NoEstimates
...und die Zukunft
der Aufwandsschätzung
Sebastian Kübeck
Xing, LinkedIn, Twitter: @skuebeck
https://sebastiankuebeck.wordpress.com/

2. #NoEstimates?
2012: Erste Verwendung des Hastags #NoEstimates ....
Der Artikel enthält Schätzungen für überholt. Ansätze von Tracer Bullet (1999) und Lean Starup
(2011) werden vorgeschlagen.

3. Studie: Teams die nicht schätzen sind
produktiver!

4. Die Unschärferelation der Aufwandsschätzung
Zuverlässigkeit der Schätzung
Vertrautheit mit dem Problem
100%
0%
noch nie gemacht
schon oft gemacht
Effizienz
Als Softwareentwickler kann man nicht vorhersagbar
und effizient zugleich sein!
Anzahl der wiederkehrenden Tätigkeiten
https://sebastiankuebeck.wordpress.com/2017/03/07/the-estimation-uncertainty-principle/

5. #NoEstimates?
2013: Erster Versuch einer Definition...
Es ist in letzter Konsequenz nicht möglich,
ohne Schätzungen in irgend einer Art
systematisch übert die Zukunft
nachzudenken!

6. #NoEstimates?
2016: Alle relevanten Beiträge haben folgendes gemeinsam...
1) Mit Estimates ist immer Aufwandsschätzung gemeint!
2) Es existiert kein bekanntes Verfahren das zuverlässige
Aufwandsschätzungen in der Softwareentwicklung ermöglicht!
3) Es werden direktes Schätzen von Aufwand (in Stunden,
Personentagen etc.) abgelehnt und indirekte Schätzmethoden
(etwa in Story Points obwohl die nicht unumstritten sind)
vorgeschlagen.
4) Der Aufwand für die Aufwandsschätzung sollte in den Teams so
gering wie möglich gehalten werden.
Achtung! Fairer Preis aber
fragwürdige Verkaufspraktiken!

7. Die Velocity ist nicht konstant
Velocity = Story Points/Sprint
Zeit
jetzt
Sprint nSprint n-1Sprint n-2... Sprint n+1 Sprint n+2 ...
???

8. Offene Fragen
Angenommen, es gibt keine direkten Schätzungen mehr...
● Wie kommt man bei Fixpreisprojekten zu einem Angebot?
● Was kann man an einem Projekt verdienen und wie hoch ist das finanzielle Risiko?
● Wann ist mit einem Abschluss des Projektes zu rechen?

9. Story Points
...in Story Points ist das enweder 4:3 oder 8:6 oder 40:30, das wird von jedem Team individuell
festgelegt.
A B
Flächeninhalt A:B 4:3

10. Beispiel: Fixpreisprojekt
Gegeben:
● Projekt im Umfang von 50 Story Points
● Velocity-Verteilung aus der Vergangenheit
Gesucht:
● Best Case: In wievielen Sprints kann das Projekt im Optimalfall umgesetzt werden? Wie
wahrscheinlich ist dieser Fall?
● Bad Case: Wieviele Sprints muss ich verkaufen, um mit einer Wahrscheinlichkeit von 95%
keinen Verlust zu erzielen?
● Worst Case: In wievielen Sprints kann das Projekt im schlimmsten Fall umgesetzt werden?
Wie wahrscheinlich ist dieser Fall?
● Erwarteter Gewinn: Wieviele Sprints muss ich verkaufen, um mit diesem Team Geld zu
verdienen?

11. Velocity
Annahme: Velocity-Verteilung wird sich in der Zukunft nicht ändern!

12. Auswerten des Histogramms
Best Case:
Maximale Velocity: 25 Story Points
Anzahl Sprints bei maximaler Velocity: 50/25 = 2 Sprints
Wahrscheinlichkeit:
(Häufigkeit 25 StoryPoints/Anzahl Messungen)Sprints
ergibt (2/11)2
= 3,31%
Worst Case:
Minimale Velocity: 1 Story Point
Anzahl Sprints bei minimaler Velocity: 50/1 = 50 Sprints
Wahrscheinlichkeit:
(Häufigkeit 1 StoryPoints/Anzahl Messungen)Sprints
ergibt (1/11)50
= 8,5x10-51
..uninteressant da zu unwahrscheinlich!

13. Monte Carlo Methode
Generiere Zufallszahlen mit gegebener Verteilung
= simulierte Velocity = Story Points/Sprint
Summiere simulierte Velocities bis 50 Story Points
erreicht sind und notiere die Sprints

14. Burn Down Graph
Burn Down Graph für 5 mögliche Projektverläufe...

15. Monte Carlo Methode
Generieren von Zufallszahlen mit gegebener Verteilung
Numpy (Python):
numpy.random.choice(a=Werte, p=Wahrscheinlichkeiten)
https://docs.scipy.org/doc/numpy-dev/reference/generated/numpy.random.choice.html
Excel:
Michael de la Maza: Monte Carlo Planning Improves Decision Making, InfoQ 2017:
https://www.infoq.com/articles/monte-carlo-planning

16. Anzahl der benötigten Sprints
Anzahl der benötigten Sprints für 1000 Projektverläufe...

17. Histogramm der Projektverläufe
5000 simulierten Projekte später....

18. Auswerten des Histogramms
Average Case:
Geld verdienen wir ab 50% also wenn wir mindestens
3 Sprints verkaufen!
Hätten wir gleich berechnen können:
Mittlere Velocity: 18.91
Mittlere Sprintanzahl:
Story Points insgesamt/mittlere Velocity
entspricht 50/18.91 = 2.64, aufgerundet 3 Sprints!
Bad Case:
Wahrscheinlichkeit >95% entspricht 1 – 0.05%
Ablesen aus dem Histogramm: 6 Sprints (Wahrscheinlichkeit: 99.38%)
Zu erwartender Gewinn in diesem Fall: 6 – 2.64 = 3.36 Sprints

19. Interpretation
Bad Case:
● Erst wenn wir 6 Sprints verkaufen, können wir mit einer Wahrscheinlichkeit von
95% davon ausgehen, dass wir kein Geld verlieren!
Best Case:
● Wir können frühestens nach 2 Sprints fertig werden!
● Die Wahrscheinlichkeit dafür, dass uns das gelingt ist mit 3.31% relativ
gering!
Average Case:
● Erst wenn wir mindestens 3 Sprints verkaufen können wir im Durschnitt
mit einem Gewinn rechnen!
Worst Case:
● Erst nach 50 Sprints können wir uns zu 100% sicher sein, dass wir kein Geld
verlieren.
● Der Fall ist aber so unwahrscheinlich, dass wir ihn vernachlässigen können