"Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen - Ergebnisse aus einem World Café im Rahmen der OOP-Konferenz 2014 in München.

2. Joachim Seibert




ScrumMaster und Agile Coach bei
//SEIBERT/MEDIA
Informatik-Background
Scrum Master (CSM), Scrum Developer
(CSD) und Scrum Professional (CSP)
Twitter: @jseibert

3. Paul Herwarth von Bittenfeld



Seit 2003 als Projektleiter,
später als Product Owner und
aktuell als ScrumMaster bei
//SEIBERT/MEDIA tätig.
Scrum Product Owner (CSPO)
und Scrum Professional (CSP)
Twitter: @pherwarth

4. PROBLEMSTELLUNG
STORY POINTS
Aufwandsschätzung
Kosten-Nutzen-Verhältnis
Risikozuschläge
Ideale Tage
Backlog
Fibbonacci
Drei-Punkt-Schätzung
Vertikales Schneiden
SCHÄTZUNGSGENAUIGKEIT
Entwicklertage
Stundenschätzung
Horizontales Schneiden
Schichtenmodell
Function Points
Features
Expertenschätzung
KOSTENSCHÄTZUNG
Optimistische vs. Pessimistische Schätzungen
Planning Poker
Komplexität
#noEstimates
Teamschätzung
Magic Estimation

5. ERFAHRUNGSABFRAGE
1. Konfrontation mit Schätzgenauigkeit Wer hat schon mal auf
den Deckel bekommen, weil eine Schätzung nicht gepasst hat?
→ Antwort: Ja 75%
2. Wie viel Zeit für's Schätzen nehmen?
→ Antwort: Schnelle Schätzung: 50%, ausführliche Schätzung: 50%
3. Wer schätzt?
→ Antwort: Schätzung im Team: 50% oder durch Einzelne: 50%
4. Schätzmaß
Stundenschätzung vs. Abstraktes Schätzmaß
→ Antwort: Stundenschätzung: 50% vs abstraktes Schätzmaß: 50%
5. „#noEstimates is easy“ (Vasco Duarte)
→ Antwort: 5 Personen waren im Vortrag, 2 finden noEstimate einfach

6. WORLD CAFE
zum Erfahrungsaustausch

7. DIE METHODE




3 Tische mit unterschiedlichen Fragestellungen
Jeweils 8 Minuten Zeit zur Erörterung und
Dokumentation (auf dem Tisch)
Wechsel der Gruppe an den nächsten Tisch
Tischhost: einer bleibt und erklärt den anderen die
bisherigen Ergebnisse

8. DIE FRAGESTELLUNGEN
Tisch 1
Aus welcher Motivation
schätzen wir als Scrum-Team?
Tisch 2
Welche Impediments
entstehen durch gemachte Schätzungen?
Tisch 3
Mit welchen Ansätzen habt ihr
gute Erfahrungen gemacht?

9. ERGEBNISPRÄSENTATION
5 Minuten pro Tisch

10. #1 MOTIVATION

11. #1 MOTIVATION
Als Motivationsgründe für das Erstellen von Schätzungen wurden Dinge genannt, die die
Teilnehmer in die Kategorien „nach innen“ und „nach außen“ unterteilt haben.
Nach Außen: Kunde, Stakeholder
● Schätzungen geben Hilfestellungen bei der Kosten-Nutzen Betrachtung (ROI, „make-orbuy“)
● Sie werden verwendet für die Angebotsabgabe / Preiskalkulation
● Schätzungen helfen bei Planung und Controlling und lassen Prognosen zu (z.B. über
Fertigstellungstermine)
● für das Einschätzen eines Risikos sind Schätzungen eventuell ebenfalls hilfreich (hohe
Schätzung → hohes Risiko)
Nach Innen: Team
Schätzungen...
● helfen bei Auseinandersetzung und Einschätzung von Aufgaben.
● fördern den Informationsaustausch („warum so aufwändig?“, Auch: „Abwehrschätzung“
genannt)
● sind hilfreich für das Team, um Zusagen für den Sprintumfang zu machen (Commitment,
Schutz vor Überlastung des Teams)
● sind Basis für Velocity-Messungen, die (für interne Zwecke) zur Performancemessung
verwendet werden können

12. #2 Impediments

13. #2 Impediments
Folgende Impediments entstehen durch Schätzungen:










Abstrakte Schätzgrößen werden nicht verstanden / müssen umgerechnet werden,
was wiederum nur schwierig geht
"Schätzungen sind Kosten"; Storypoints sind Aufwandschätzungen; Schätzungen
sind Commitment (werden vom Kunden falsch verstanden bzw. als endgültig
interpretiert)
Storypoints sind Aufwandsschätzungen
Teams werden auf Basis ihrer Schätzungen verglichen (Konkurrenz)
Schätzung wird als Commitment gesehen (muss gehalten werden)
Zeitdruck ist wichtiger als Qualität (schnell fertigstellen, um Schätzung zu halten)
Schätzung wird nicht vertraut - man muss Beweise sammeln, „genauer“ schätzen
Probleme entstehen, wenn die „falschen Leute“ Schätzungen machen bzw. für
andere geschätzt wird.
Umfang der Aufgabe ändert sich -> es erfolgt aber keine Anpassung der Schätzung
Verifizierung soll/ist findet selten statt

14. #3 GUTE ERFAHRUNGEN

15. #3 GUTE ERFAHRUNGEN
Gute Erfahrungen haben die Teilnehmer gemacht mit:
●
●
●
●
●
●
●
●
●
●
●
●
Schätzungen im Team, gerade auch, wenn unterschiedliche Typen von Mitarbeitern im Team
sind (Ausgleich Optimist <-> Pessimist), aber darauf achten, dass sich alle beteiligen
(weniger Zurückhaltung)
Schätzverfahren wie Planning Poker, Magic Estimation (für viele Stories) und Abstraktes
Schätzen (Relationen: größer > kleiner)
Gemeinsames Diskutieren von Anforderungsbeschreibungen, um Knackpunkte feststellen,
Wissenstransfer zu erreichen und ein besseres Verständnis zu gewinnen (-> realistischere
Schätzung)
Erstellung von Spikes, um Machbarkeit zu testen
Annahmen treffen, die als Basis für Schätzungen definiert werden
Umstellung von Personentagen auf Story Points, aber: Für Angebote muss wieder
umgerechnet werden
Schnelles Schätzen: Aufwand reduzieren
wenige Schätzgrößen / Ranges: high, low, Medium (S, M, L)
Tasks zählen
Besserer Soll-/Ist-Vergleich durch Projektdatenbank, Erfahrungswerte sammeln
Aufschläge einrechnen (z.B. Faktor 2 oder prozentuale Aufschläge)
Gültigkeitsdauer für Schätzung definieren (danach muss neu geschätzt werden)

16. ANREGUNGEN
Experimentieren mit:

#noEstimates

Messen statt Schätzen (Stories zählen)


Weniger Schätzgrößen verwenden
(T-Shirt Sizes)
Business Value schätzen

17. LINKS


Objektspektrum-Artikel von jseibert: http://seibert.biz/agilesbeschaetzen
Ergebnisse vom World Café auf den XP Days 2013:
http://de.slideshare.net/pherwarth/20131114-och-nichtschonwiederschaetzen

https://infos.seibert-media.net/display/Websoftware/Agile+Vorhersagen

http://borisgloger.com/2013/06/07/warum-uberhaupt-schatzen/

http://agilenature.com/why-do-we-estimate/

http://blog.nayima.be/2009/04/21/why-estimate/



http://epf.eclipse.org/wikis/openup/core.mgmt.common.extend_supp/guidances/g
uidelines/agile_estimation_A4EF42B3.html
http://pm.stackexchange.com/questions/2765/why-use-story-points-instead-ofhours-for-estimating
http://alphanodes.de/schaetzen-agilen-projekten

18. Ergebnisse und Erfahrungsaustausch via
Twitter:
@jseibert und @pherwarth