Joachim Seibert








ScrumMaster und Agile Coach bei
//SEIBERT/MEDIA
Informatik-Background
Scrum Master (CSM), Scru...
Paul Herwarth von Bittenfeld






Seit 2003 als Projektleiter,
später als Product Owner und
aktuell als ScrumMaster be...
PROBLEMSTELLUNG

STORY POINTS
Aufwandsschätzung
Kosten-Nutzen-Verhältnis

Risikozuschläge

Ideale Tage

Backlog

Fibbonacc...
ERFAHRUNGSABFRAGE
1. Konfrontation mit Schätzgenauigkeit Wer hat schon mal auf
den Deckel bekommen, weil eine Schätzung ni...
WORLD CAFE
zum Erfahrungsaustausch
DIE METHODE









3 Tische mit unterschiedlichen Fragestellungen
Jeweils 8 Minuten Zeit zur Erörterung und
Dokument...
DIE FRAGESTELLUNGEN
Tisch 1
Aus welcher Motivation
schätzen wir als Scrum-Team?
Tisch 2
Welche Impediments
entstehen durch...
ERGEBNISPRÄSENTATION
5 Minuten pro Tisch
#1 MOTIVATION
#1 MOTIVATION
Als Motivationsgründe für das Erstellen von Schätzungen wurden Dinge genannt, die die
Teilnehmer in die Kate...
#2 Impediments
#2 Impediments
Folgende Impediments entstehen durch Schätzungen:














Abstrakte Schätzgrößen werden nic...
#3 GUTE ERFAHRUNGEN
#3 GUTE ERFAHRUNGEN
Gute Erfahrungen haben die Teilnehmer gemacht mit:
●

●

●

●
●
●

●
●
●
●
●
●

Schätzungen im Team, g...
ANREGUNGEN

Experimentieren mit:


#noEstimates



Messen statt Schätzen (Stories zählen)





Weniger Schätzgrößen ve...
LINKS




Objektspektrum-Artikel von jseibert: http://seibert.biz/agilesbeschaetzen
Ergebnisse vom World Café auf den XP...
Ergebnisse und Erfahrungsaustausch via
Twitter:
@jseibert und @pherwarth
"Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen
Nächste SlideShare
Wird geladen in …5
×

"Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen

2.169 Aufrufe

Veröffentlicht am

"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.

Veröffentlicht in: Technologie
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
2.169
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
29
Aktionen
Geteilt
0
Downloads
9
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

"Och, nicht schon wieder...!" - Über das Leiden der Entwickler bei Aufwandsschätzungen

  1. 1. Joachim Seibert     ScrumMaster und Agile Coach bei //SEIBERT/MEDIA Informatik-Background Scrum Master (CSM), Scrum Developer (CSD) und Scrum Professional (CSP) Twitter: @jseibert
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. WORLD CAFE zum Erfahrungsaustausch
  6. 6. 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
  7. 7. 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?
  8. 8. ERGEBNISPRÄSENTATION 5 Minuten pro Tisch
  9. 9. #1 MOTIVATION
  10. 10. #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
  11. 11. #2 Impediments
  12. 12. #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
  13. 13. #3 GUTE ERFAHRUNGEN
  14. 14. #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)
  15. 15. ANREGUNGEN Experimentieren mit:  #noEstimates  Messen statt Schätzen (Stories zählen)   Weniger Schätzgrößen verwenden (T-Shirt Sizes) Business Value schätzen
  16. 16. 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
  17. 17. Ergebnisse und Erfahrungsaustausch via Twitter: @jseibert und @pherwarth

×