SlideShare ist ein Scribd-Unternehmen logo
1 von 45
Downloaden Sie, um offline zu lesen
Relatives Schätzen
Agile Breakfast Bern / 31. Mai 2017
Fabian Kiss / @fbnkss
Senior Project Manager
Deep Impact AG / Winterthur
10 Jahre Erfahrung in der agilen Softwareentwicklung
als Softwareentwickler, Scrum Master, Product Owner, Agile Coach, PL
Aufwandsschätzungen im agilen Projektkontext
Forecast zur Zeit- und Kostenplanung
Product Backlog als Ausgangsbasis
 Herausforderungen…
Picture by Pim Stouten / CC BY-NC 2.0
Eiligkeit von Aufwandsschätzungen
Picture by Jalil Arfaoui / CC BY-NC 2.0
Möglichst genaue
Aufwandsschätzungen
Picture by Tiago Daniel / CC BY-NC-ND 2.0
Planning Poker zu aufwändig
bei grossem Product Backlog
Picture by Jacob Bøtter / CC BY 2.0
Kein schätzbereites Product Backlog
Was ist relatives Schätzen?
Komplexität von Product Backlog Items werden zunächst
ausschliesslich relativ zueinander geschätzt
Item X < Item Y
Item X = Item Y
Item X > Item Y
Umrechnung (Triangulation) der relativen Komplexitätsgrössen
in Story Points (SP) oder Personentagen (PT)
über Werteskala und Referenzwert(e)
Allgemeine Regeln
Es schätzt das Entwicklungsteam, das das Projekt auch umsetzen wird.
Jeder aus dem Team schätzt mit.
Der Product Owner nimmt ebenso teil (stellt Items vor).
Der Product Owner schätzt aber nicht mit.
Es gibt einen Organisator/Moderator (muss nicht der Product Owner sein).
Es gibt keine Zwischengrössen (ein Item X kann nicht ein «bisschen komplexer» sein als Item Y).
Vorteile
sehr gut geeignet um eine grosse Anzahl Items zu schätzen
sehr gut geeignet um Items mit einem niedrigen Detailgrad (Epics) zu schätzen
vertretbarer Zeitaufwand (max. 2 h mit allen Teammitgliedern)
Techniken
Team Estimation Game
http://transferio.at/agile-coach/effizient-schaetzen-mit-dem-team-estimation-game/
Magic Estimation
http://organisationsgestalter.blogspot.ch/2013/04/agile-schatzverfahren-im-vergleich-zu.html
…
Merkmale der verschiedenen Techniken
Wie stark strukturiert ist der Schätzablauf?
"Spielrunden" vs. unkoordiniertes Vorgehen
Merkmale der verschiedenen Techniken
Wie stark strukturiert ist der Schätzablauf?
"Spielrunden" vs. unkoordiniertes Vorgehen
BEST PRACTICE
«Spielrunden» bei neuen
Teams / zurückhaltenden
Teammitgliedern
Merkmale der verschiedenen Techniken
Welche Werteskala zur Umrechnung?
linear vs. nicht-linear
Merkmale der verschiedenen Techniken
Welche Werteskala zur Umrechnung?
linear vs. nicht-linear
BEST PRACTICE
Abwägung:
je komplexer Projektumfeld,
desto eher nicht-linear
BEST PRACTICE
T-Shirt-Grössen-Skala:
keine «Algebra-Diskussionen»
/ Flexibilität linear vs. nicht-
linear
Merkmale der verschiedenen Techniken
Welche Referenzwerte zur Umrechnung?
Ist-Aufwände aus Vergleichsprojekten vs. selektive Detailschätzungen
Merkmale der verschiedenen Techniken
Welche Referenzwerte zur Umrechnung?
Ist-Aufwände aus Vergleichsprojekten vs. selektive Detailschätzungen
BEST PRACTICE
Detailschätzung eines Item
Abdeckung des Projektumfangs
Abdeckung des Projektumfangs
Vollständige Abdeckung des Projektumfangs
Abdeckung des Projektumfangs
Unvollständige Abdeckung des Projektumfangs
Detailgrad der Items
Detailgrad der Items
Kaum Unterschiede im Detailgrad
Detailgrad der Items
Grosse Unterschiede im Detailgrad
 Items «normalisieren»
Idealfall
Mindestens 1 Item mit zusätzlichen Detailanforderungen
Hilfsmittel
Wand & Post-Its zum einfachen Verschieben von Items
Keine virtuellen Tools (JIRA o.ä.)!
Hilfsmittel
BEST PRACTICE
Stattys eignen sich besser
zum Verschieben als
konventionelle Post-Its
Hilfsmittel
BEST PRACTICE
Alternative:
Ausdrucke (bspw. aus JIRA) &
Zuordnung per Buchstabe
Hilfsmittel
BEST PRACTICE
Alternative:
Ausdrucke (bspw. aus JIRA) &
Zuordnung per Buchstabe
Vorbereitung
Skala an Wand platzieren
Vorbereitung
Auswahl eines Referenz-Item
Vorbereitung
Auswahl eines Referenz-Item
BEST PRACTICE
Kein «extremes» Item
auswählen (extrem einfach
oder extrem komplex)
BEST PRACTICE
Ein Item auswählen, das
«kritisch» für den
Projekterfolg ist
Vorbereitung
Detailschätzung des Referenz-Item
Falls noch nicht geschehen:
Zerlegung des Item in einzelne Detailanforderungen
(Dekomposition)
Vorbereitung
Detailschätzung des Referenz-Item
Falls noch nicht geschehen:
Zerlegung des Item in einzelne Detailanforderungen
(Dekomposition)
BEST PRACTICE
Schätzung der
Detailanforderungen in SP
oder PT per Planning Poker &
Summe bilden
Team Estimation Game
Initiale Platzierung des Referenz-Item durch ersten Schätzer in der Spielrunde
Platzierung ist temporär!
Team Estimation Game
Ablauf pro Spielrunde
Der nächste Schätzer in der Runde hat drei Wahlmöglichkeiten:
a) Neues Item schätzen
b) Item umschätzen
c) Runde aussetzen
Spielende: wenn alle Schätzer in der Runde aussetzen
Team Estimation Game
1. Schätzer nimmt ungeschätztes Item
2. Optional: Vorstellung / Rückfragen Item
3. Schätzer hängt Item an entsprechender
Stelle an Wand (wortlos)
Ablauf neues Item schätzen
Team Estimation Game
1. Schätzer hängt geschätztes Item an
entsprechender Stelle an Wand um
2. Optional: Schätzer begründet seine
Umschätzung (ohne Diskussion)
Ablauf Item umschätzen
Umrechnung
BEST PRACTICE
Lineare Umrechnung
von T-Shirt-Grössen
über kleinste verwendete T-
Shirt-Grösse
Umrechnung
BEST PRACTICE
Lineare Umrechnung
von T-Shirt-Grössen
über kleinste verwendete T-
Shirt-Grösse
Umrechnung
BEST PRACTICE
Lineare Umrechnung
von T-Shirt-Grössen
über kleinste verwendete T-
Shirt-Grösse
Umrechnung
BEST PRACTICE
Lineare Umrechnung
von T-Shirt-Grössen
über kleinste verwendete T-
Shirt-Grösse
Umrechnung
BEST PRACTICE
Lineare Umrechnung
von T-Shirt-Grössen
über kleinste verwendete T-
Shirt-Grösse
96 PT
120 PT
64 PT
72 PT
48 PT
16 PT
Umrechnung
BEST PRACTICE
Lineare Umrechnung
von T-Shirt-Grössen
über kleinste verwendete T-
Shirt-Grösse
96 PT
120 PT
64 PT
72 PT
48 PT
16 PT
416 PT
Fazit
Relative Schätztechniken führen sehr schnell zu validen Aufwandsschätzungen
Keine Zeitersparnis für Product Owner
(Erstellung von grob schätzbarem Product Backlog)
Gesamtergebnis sehr gut geeignet für erstmaligen Forecast
Detailschätzungen im Projektverlauf nach wie vor notwendig
(Sprint Planning / Backlog Refinement)
Best Practices sind organisations-, projekt- und teamspezifisch
Eigene Best Practices erarbeiten!
!MPACT yourself, contact us.
Rychenbergstrasse 67 - 8400 Winterthur, Switzerland
+41 52 551 07 07
fabian.kiss@deep-impact.ch

Weitere ähnliche Inhalte

Mehr von Fabian Kiss

BDD in open source projects - Is it really beneficial?
BDD in open source projects - Is it really beneficial?BDD in open source projects - Is it really beneficial?
BDD in open source projects - Is it really beneficial?Fabian Kiss
 
Collocation in Distributed Scrum Teams - Lessons Learned
Collocation in Distributed Scrum Teams - Lessons LearnedCollocation in Distributed Scrum Teams - Lessons Learned
Collocation in Distributed Scrum Teams - Lessons LearnedFabian Kiss
 
Web Acceptance Testing with Behat
Web Acceptance Testing with BehatWeb Acceptance Testing with Behat
Web Acceptance Testing with BehatFabian Kiss
 
The concept of Behavior-Driven Development
The concept of Behavior-Driven DevelopmentThe concept of Behavior-Driven Development
The concept of Behavior-Driven DevelopmentFabian Kiss
 
Documentation for Program Comprehension in Agile Software Development
Documentation for Program Comprehension in Agile Software DevelopmentDocumentation for Program Comprehension in Agile Software Development
Documentation for Program Comprehension in Agile Software DevelopmentFabian Kiss
 
Documentation in the agile software development process
Documentation in the agile software development processDocumentation in the agile software development process
Documentation in the agile software development processFabian Kiss
 

Mehr von Fabian Kiss (6)

BDD in open source projects - Is it really beneficial?
BDD in open source projects - Is it really beneficial?BDD in open source projects - Is it really beneficial?
BDD in open source projects - Is it really beneficial?
 
Collocation in Distributed Scrum Teams - Lessons Learned
Collocation in Distributed Scrum Teams - Lessons LearnedCollocation in Distributed Scrum Teams - Lessons Learned
Collocation in Distributed Scrum Teams - Lessons Learned
 
Web Acceptance Testing with Behat
Web Acceptance Testing with BehatWeb Acceptance Testing with Behat
Web Acceptance Testing with Behat
 
The concept of Behavior-Driven Development
The concept of Behavior-Driven DevelopmentThe concept of Behavior-Driven Development
The concept of Behavior-Driven Development
 
Documentation for Program Comprehension in Agile Software Development
Documentation for Program Comprehension in Agile Software DevelopmentDocumentation for Program Comprehension in Agile Software Development
Documentation for Program Comprehension in Agile Software Development
 
Documentation in the agile software development process
Documentation in the agile software development processDocumentation in the agile software development process
Documentation in the agile software development process
 

Relatives Schätzen - SwissICT Agile Breakfast Bern