Scrum Guide
Der umfassende Leitfaden zu Scrum: Events, Rollen, Artefakte und Best Practices
Agiles Schätzen in Scrum
Agiles Schätzen ist eine der wichtigsten Praktiken in Scrum, um Aufwände realistisch einzuschätzen und die Sprint-Planung effektiv zu gestalten. Statt absoluter Zeitangaben nutzen agile Teams relative Bewertungen und Story Points.
💡 Key Insight
Es fällt leichter, relative Schätzungen abzugeben als zeitliche Schätzungen. Menschen können besser vergleichen als absolute Zeiträume vorhersagen.
Podcast Episode #19: Agiles Schätzen - Die Grundlagen relativer Aufwandsbewertung
Was ist agiles Schätzen?
Kernideen des agilen Schätzens
- Schätzung entkoppelt von Zeit: Statt "das dauert 5 Tage" sagen wir "das ist 8 Story Points"
- Relativer Aufwand statt absolute Zeitangaben: Vergleiche mit bereits erledigten Items
- Bezug zur tatsächlichen Leistungsfähigkeit: Story Points werden zur Velocity des Teams in Beziehung gesetzt
Warum relatives Schätzen funktioniert
Menschen haben systematische Schwierigkeiten mit präzisen Zeitschätzungen:
- Wir unterschätzen die Komplexität unbekannter Aufgaben
- Wir vergessen Overhead und Kontextwechsel
- Wir sind zu optimistisch bei der Zeitplanung
Relatives Schätzen basiert dagegen auf Vergleichen und Erfahrungswerten. Es ist leichter zu sagen "Projekt B ist doppelt so aufwändig wie Projekt A" als "Projekt B dauert genau 12 Tage".
Techniken des agilen Schätzens
1. Sukzessive Vorgehensweise
Diese Technik eignet sich besonders für Teams, die neu mit Story Points arbeiten:
- Mit zwei Backlog Items beginnen: Wählt zwei Items unterschiedlicher Größe
- Items in Relation setzen: "Item B ist ca. 3x so aufwändig wie Item A"
- Baseline festlegen: Vergebt z.B. 3 Story Points für A und 8 für B
- Weitere Items einordnen: Alle weiteren Items im Verhältnis zu A und B schätzen
2. Planning Poker
Planning Poker ist die verbreitetste Technik für agiles Schätzen im Team. Sie fördert Diskussion und nutzt die Schwarmintelligenz des Teams:
Ablauf Planning Poker:
- Vorbereitung: Jedes Teammitglied erhält ein Set Schätzkarten (z.B. Fibonacci: 1, 2, 3, 5, 8, 13, 21)
- Item vorstellen: Product Owner erklärt das Backlog Item
- Klärungsfragen: Team stellt Verständnisfragen
- Unabhängige Schätzung: Jeder wählt verdeckt eine Karte
- Gleichzeitige Aufdeckung: Alle zeigen ihre Karten gleichzeitig
- Diskussion: Höchste und niedrigste Schätzungen begründen ihre Sicht
- Wiederholung: Bis zu drei Runden, dann Einigung auf gemeinsamen Wert
Wichtige Prinzipien beim Schätzen
- ✓Nur aktive Sprint-Teilnehmer schätzen: Die Menschen, die die Arbeit machen, schätzen den Aufwand
- ✓Product Owner schätzt nicht mit: PO klärt Fragen, beeinflusst aber nicht die Aufwandsschätzung
- ✓Ziel ist Klärung, nicht Genauigkeit: Diskussionen über unterschiedliche Schätzungen decken Missverständnisse auf
- ✓Unterschiedliche Perspektiven nutzen: Frontend, Backend, Testing - alle Sichten sind wertvoll
Zahlenreihen für Story Points
Die Wahl der Zahlenreihe ist weniger wichtig als das Prinzip dahinter:
Fibonacci-Folge
1, 2, 3, 5, 8, 13, 21
Am weitesten verbreitet. Größere Abstände bei größeren Zahlen reflektieren höhere Unsicherheit.
2er Potenzen
1, 2, 4, 8, 16, 32
Einfache Verdopplung. Verdeutlicht exponentielle Komplexitätszunahme.
Wichtig: Die Zahlenreihen sind bewusst ungenau (keine 4, 6, 7), um Scheingenauigkeit zu vermeiden. Bei großen Items (13+) sollte überlegt werden, ob das Item nicht besser aufgeteilt werden kann.
Best Practices
- ✓Früh beginnen: Startet mit agilen Schätzungen sobald ihr erste Items im Backlog habt
- ✓Gemeinsam lernen: Die ersten Schätzungen werden ungenau sein - das ist normal und verbessert sich
- ✓Velocity nutzen: Nach 2-3 Sprints wisst ihr, wie viele Story Points ihr schafft
- ✓Nicht nachschätzen: Wenn sich Anforderungen ändern, erstellt neue Items statt alte umzuschätzen
- ✓Diskussion wertschätzen: Der Austausch über unterschiedliche Einschätzungen ist wertvoller als die finale Zahl
Häufige Fehler beim agilen Schätzen
- ✗Story Points in Stunden umrechnen: "1 Story Point = 4 Stunden" macht die Vorteile zunichte
- ✗Einzelpersonen bewerten: Story Points sind Team-Metriken, keine Performance-Bewertung
- ✗Zu viel Genauigkeit erwarten: Schätzungen sind Prognosen, keine Versprechen
- ✗Externe vorgeben lassen: Management oder PO diktieren Schätzungen
- ✗Zu lange diskutieren: Nach 3 Runden Planning Poker eine Entscheidung treffen
Zusammenfassung
Agiles Schätzen ist ein Gesprächs-Werkzeug, kein Präzisions-Instrument. Die Diskussionen über unterschiedliche Einschätzungen decken Missverständnisse auf und schaffen gemeinsames Verständnis im Team.
Relative Einschätzungen mit Story Points sind präziser und ehrlicher als absolute Zeitangaben. Sie erlauben es Teams, ihre Leistungsfähigkeit über die Zeit zu messen und kontinuierlich zu verbessern.
Häufig gestellte Fragen
Was ist agiles Schätzen in Scrum?
Agiles Schätzen entkoppelt Aufwandsschätzungen von Zeit. Statt 'das dauert 5 Tage' nutzen Teams Story Points für relative Bewertungen. Die Kernideen: 1. Schätzung entkoppelt von Zeit (Story Points statt Tage), 2. Relativer Aufwand statt absolute Zeitangaben (Vergleiche mit bereits erledigten Items), 3. Bezug zur tatsächlichen Leistungsfähigkeit (Story Points werden zur Velocity des Teams in Beziehung gesetzt). Story Points reflektieren Komplexität, Aufwand und Unsicherheit zusammen.
Warum funktioniert relatives Schätzen besser als Zeitschätzungen?
Menschen haben systematische Schwierigkeiten mit präzisen Zeitschätzungen: Wir unterschätzen Komplexität unbekannter Aufgaben, vergessen Overhead und Kontextwechsel und sind zu optimistisch bei der Zeitplanung. Relatives Schätzen basiert dagegen auf Vergleichen und Erfahrungswerten. Es ist leichter zu sagen 'Projekt B ist doppelt so aufwändig wie Projekt A' als 'Projekt B dauert genau 12 Tage'. Deshalb nutzen agile Teams Story Points für relative Bewertungen statt absoluter Zeitangaben.
Wie funktioniert Planning Poker?
Planning Poker ist die verbreitetste Technik für agiles Schätzen im Team. Ablauf: 1. Vorbereitung (jedes Teammitglied erhält Schätzkarten mit Fibonacci-Zahlen: 1, 2, 3, 5, 8, 13, 21), 2. Product Owner stellt Backlog Item vor, 3. Team stellt Klärungsfragen, 4. Jeder wählt verdeckt eine Karte (unabhängige Schätzung), 5. Alle zeigen Karten gleichzeitig, 6. Höchste und niedrigste Schätzungen begründen ihre Sicht, 7. Wiederholung bis zu drei Runden, dann Einigung auf gemeinsamen Wert. Ziel ist Diskussion und gemeinsames Verständnis, nicht Genauigkeit.
Warum wird die Fibonacci-Folge für Story Points genutzt?
Die Fibonacci-Folge (1, 2, 3, 5, 8, 13, 21) ist die am weitesten verbreitete Zahlenreihe für Story Points. Größere Abstände bei größeren Zahlen reflektieren höhere Unsicherheit bei komplexeren Items. Die Zahlenreihen sind bewusst ungenau (keine 4, 6, 7), um Scheingenauigkeit zu vermeiden. Alternative: 2er Potenzen (1, 2, 4, 8, 16, 32) mit einfacher Verdopplung. Wichtig: Bei großen Items (13+) sollte überlegt werden, ob das Item nicht besser aufgeteilt werden kann. Die Wahl der Zahlenreihe ist weniger wichtig als das Prinzip dahinter.
Wer sollte beim agilen Schätzen mitwirken?
Beim agilen Schätzen gilt: Nur aktive Sprint-Teilnehmer schätzen - die Menschen, die die Arbeit machen, schätzen den Aufwand. Der Product Owner schätzt nicht mit - er klärt Fragen, beeinflusst aber nicht die Aufwandsschätzung. Wichtige Prinzipien: Ziel ist Klärung (nicht Genauigkeit), unterschiedliche Perspektiven nutzen (Frontend, Backend, Testing - alle Sichten sind wertvoll), Diskussionen über unterschiedliche Schätzungen decken Missverständnisse auf. Das Entwicklungsteam hat die volle Kontrolle über die Schätzung.
Was sind häufige Fehler beim agilen Schätzen?
Häufige Fehler beim agilen Schätzen: 1. Story Points in Stunden umrechnen ('1 Story Point = 4 Stunden' macht die Vorteile zunichte), 2. Einzelpersonen bewerten (Story Points sind Team-Metriken, keine Performance-Bewertung), 3. Zu viel Genauigkeit erwarten (Schätzungen sind Prognosen, keine Versprechen), 4. Externe vorgeben lassen (Management oder PO diktieren Schätzungen), 5. Zu lange diskutieren (nach 3 Runden Planning Poker eine Entscheidung treffen). Agiles Schätzen ist ein Gesprächs-Werkzeug, kein Präzisions-Instrument.
Wie nutzt man Story Points für Sprint-Planung?
Nach 2-3 Sprints wisst ihr, wie viele Story Points euer Team schafft - das ist eure Velocity. Best Practices für Sprint-Planung: 1. Früh beginnen (startet mit agilen Schätzungen sobald ihr erste Items im Backlog habt), 2. Gemeinsam lernen (erste Schätzungen werden ungenau sein - das ist normal und verbessert sich), 3. Velocity nutzen (Plant künftige Sprints basierend auf durchschnittlicher Velocity), 4. Nicht nachschätzen (wenn sich Anforderungen ändern, erstellt neue Items statt alte umzuschätzen), 5. Diskussion wertschätzen (Austausch über unterschiedliche Einschätzungen ist wertvoller als die finale Zahl).
🎧 Podcast-Episode zum Agilen Schätzen
#129: Scrum vs Kanban – Worauf du beim Umstieg achten musst
Scrum vs Kanban: 3 Kernunterschiede beim Umstieg (Arbeitssteuerung, Change-Ansatz, Rollen). Warum Scrum-Teams Kanban oft missverstehen und worauf du achten musst.
Scrum-Training buchen
Lerne Scrum in der Praxis kennen. Unsere zertifizierten Trainings vermitteln dir das nötige Wissen, um Scrum erfolgreich in deinem Unternehmen einzuführen.
Zu den Trainings