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