"och, nicht schon wieder...!" - Über das leiden der entwickler bei aufwandsschätzungen
DESCRIPTION
"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.TRANSCRIPT
![Page 1: "Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen](https://reader033.vdokument.com/reader033/viewer/2022051012/540cdf278d7f72767e8b4665/html5/thumbnails/1.jpg)
![Page 2: "Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen](https://reader033.vdokument.com/reader033/viewer/2022051012/540cdf278d7f72767e8b4665/html5/thumbnails/2.jpg)
Joachim Seibert
ScrumMaster und Agile Coach bei //SEIBERT/MEDIA
Informatik-Background
Scrum Master (CSM), Scrum Developer (CSD) und Scrum Professional (CSP)
Twitter: @jseibert
![Page 3: "Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen](https://reader033.vdokument.com/reader033/viewer/2022051012/540cdf278d7f72767e8b4665/html5/thumbnails/3.jpg)
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
![Page 4: "Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen](https://reader033.vdokument.com/reader033/viewer/2022051012/540cdf278d7f72767e8b4665/html5/thumbnails/4.jpg)
STORY POINTS
Function Points
SCHÄTZUNGSGENAUIGKEIT
KOSTENSCHÄTZUNG
Entwicklertage
Ideale Tage
Teamschätzung
Drei-Punkt-Schätzung
ExpertenschätzungStundenschätzung
Backlog
Horizontales Schneiden
Vertikales Schneiden
FeaturesSchichtenmodell
Risikozuschläge
Kosten-Nutzen-Verhältnis
Optimistische vs. Pessimistische Schätzungen
Aufwandsschätzung
Fibbonacci
Komplexität
PROBLEMSTELLUNG
#noEstimatesPlanning Poker Magic Estimation
![Page 5: "Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen](https://reader033.vdokument.com/reader033/viewer/2022051012/540cdf278d7f72767e8b4665/html5/thumbnails/5.jpg)
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
ERFAHRUNGSABFRAGE
![Page 6: "Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen](https://reader033.vdokument.com/reader033/viewer/2022051012/540cdf278d7f72767e8b4665/html5/thumbnails/6.jpg)
zum ErfahrungsaustauschWORLD CAFE
![Page 7: "Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen](https://reader033.vdokument.com/reader033/viewer/2022051012/540cdf278d7f72767e8b4665/html5/thumbnails/7.jpg)
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
![Page 8: "Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen](https://reader033.vdokument.com/reader033/viewer/2022051012/540cdf278d7f72767e8b4665/html5/thumbnails/8.jpg)
DIE FRAGESTELLUNGEN
Tisch 3Mit welchen Ansätzen habt ihr gute Erfahrungen gemacht?
Tisch 1Aus welcher Motivation schätzen wir als Scrum-Team?
Tisch 2Welche Impediments entstehen durch gemachte Schätzungen?
![Page 9: "Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen](https://reader033.vdokument.com/reader033/viewer/2022051012/540cdf278d7f72767e8b4665/html5/thumbnails/9.jpg)
5 Minuten pro TischERGEBNISPRÄSENTATION
![Page 10: "Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen](https://reader033.vdokument.com/reader033/viewer/2022051012/540cdf278d7f72767e8b4665/html5/thumbnails/10.jpg)
#1 MOTIVATION
![Page 11: "Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen](https://reader033.vdokument.com/reader033/viewer/2022051012/540cdf278d7f72767e8b4665/html5/thumbnails/11.jpg)
#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-or-
buy“)● 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: TeamSchä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
![Page 12: "Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen](https://reader033.vdokument.com/reader033/viewer/2022051012/540cdf278d7f72767e8b4665/html5/thumbnails/12.jpg)
#2 Impediments
![Page 13: "Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen](https://reader033.vdokument.com/reader033/viewer/2022051012/540cdf278d7f72767e8b4665/html5/thumbnails/13.jpg)
#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
![Page 14: "Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen](https://reader033.vdokument.com/reader033/viewer/2022051012/540cdf278d7f72767e8b4665/html5/thumbnails/14.jpg)
#3 GUTE ERFAHRUNGEN
![Page 15: "Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen](https://reader033.vdokument.com/reader033/viewer/2022051012/540cdf278d7f72767e8b4665/html5/thumbnails/15.jpg)
#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)
![Page 16: "Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen](https://reader033.vdokument.com/reader033/viewer/2022051012/540cdf278d7f72767e8b4665/html5/thumbnails/16.jpg)
Experimentieren mit:
#noEstimates
Messen statt Schätzen (Stories zählen)
Weniger Schätzgrößen verwenden (T-Shirt Sizes)
Business Value schätzen
ANREGUNGEN
![Page 17: "Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen](https://reader033.vdokument.com/reader033/viewer/2022051012/540cdf278d7f72767e8b4665/html5/thumbnails/17.jpg)
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/guidelines/agile_estimation_A4EF42B3.html
http://pm.stackexchange.com/questions/2765/why-use-story-points-instead-of-hours-for-estimating
http://alphanodes.de/schaetzen-agilen-projekten
LINKS
![Page 18: "Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen](https://reader033.vdokument.com/reader033/viewer/2022051012/540cdf278d7f72767e8b4665/html5/thumbnails/18.jpg)
Ergebnisse und Erfahrungsaustausch via Twitter:
@jseibert und @pherwarth