Schätzung in XP

Menschen sind schlecht darin, absolute Zeit zu schätzen. „Das dauert 3 Tage" ist fast immer falsch. Wir unterschätzen Komplexität und überschätzen unsere Produktivität.

Aber Menschen sind gut im relativen Vergleich. „Diese Story ist etwa doppelt so groß wie jene" ist etwas, das wir zuverlässig einschätzen können.

XP verwendet relative Schätzung. Statt Stunden zu schätzen, schätzen wir Größe. Eine Story könnte eine „2" oder eine „5" oder eine „13" sein. Diese Zahlen bedeuten keine Stunden oder Tage – sie bedeuten relative Größe im Vergleich zu anderen Stories.

Warum relativ funktioniert:

• Wir vergleichen Dinge, die wir verstehen (Story zu Story, nicht Story zu Zeit)
• Es ist schneller (man braucht keine detaillierten Aufgliederungen)
• Es ist ehrlicher (keine falsche Präzision)
• Es korrigiert sich selbst durch Velocity-Tracking

Story Points sind die gängigste Einheit für relative Schätzung.

Points repräsentieren Aufwand, Komplexität und Unsicherheit kombiniert – nicht Zeit. Eine 5-Punkte-Story ist ungefähr doppelt so aufwändig wie eine 2-Punkte-Story (in etwa), aber nicht unbedingt doppelt so viele Stunden.

Gängige Punkteskalen:

• Fibonacci: 1, 2, 3, 5, 8, 13, 21, ? (Lücken zwingen zur Entscheidung)
• Zweierpotenzen: 1, 2, 4, 8, 16 (einfache Verdopplung)
• T-Shirt-Größen: XS, S, M, L, XL (nicht-numerisch, gut für High-Level-Planung)

Tipps zum Schätzen von Stories:

• Vergleiche mit Referenz-Stories („Ist das größer oder kleiner als Story X?")
• Denk nicht zu viel nach (Points sind absichtlich unscharf)
• Beziehe Unsicherheit in die Schätzung ein (unbekannt = größer)
• Schätze neu, wenn du etwas lernst, das dein Verständnis ändert

Planning Poker ist eine Technik, um im Team Konsens über Schätzungen zu erreichen.

So funktioniert es:

1. Der Product Owner liest eine Story vor
2. Teammitglieder stellen klärende Fragen
3. Jeder wählt privat eine Schätzkarte
4. Alle Karten werden gleichzeitig aufgedeckt
5. Höchste und niedrigste Schätzer erklären ihre Begründung
6. Das Team diskutiert und stimmt bei Bedarf erneut ab
7. Konsens entsteht (oder der Durchschnitt wird genommen)

Warum gleichzeitiges Aufdecken? Um Ankereffekte zu vermeiden. Wenn der Senior-Entwickler zuerst „5" sagt, passen sich alle anderen Richtung 5 an. Gleichzeitiges Aufdecken erfasst unabhängige Meinungen.

Warum Ausreißer diskutieren? Die Person, die „13" sagte, weiß vielleicht etwas, das andere nicht wissen („das erfordert Datenbankmigration"). Die Person, die „2" sagte, hat vielleicht einen einfacheren Ansatz. Beide Sichtweisen verbessern die Schätzung.

Planning Poker dient genauso sehr dem Aufbau gemeinsamen Verständnisses wie dem Ermitteln einer Zahl. Die Diskussion bringt Annahmen, Risiken und Designentscheidungen ans Licht.

Velocity ist, wie viele Points das Team pro Iteration abschließt. Sie ist der Schlüssel, um relative Schätzungen in Prognosen zu verwandeln.

Wenn das Team letzte Iteration 30 Points abgeschlossen hat, wird es wahrscheinlich etwa 30 Points in der nächsten Iteration abschließen. Das nennt man das Wetter von gestern – der beste Prädiktor für das Wetter von morgen ist das Wetter von heute.

Velocity nutzen:

• Wenn du 100 Points Arbeit hast und eine Velocity von 20, erwarte etwa 5 Iterationen
• Wenn der Kunde in 3 Iterationen ausliefern will, kannst du etwa 60 Points Arbeit schaffen
• Velocity schwankt; verwende einen gleitenden Durchschnitt (letzte 3–5 Iterationen)

Was Velocity beeinflusst:

• Teamzusammensetzung (Urlaub, neue Mitglieder)
• Technische Umgebung (neues Framework, Infrastrukturänderungen)
• Arbeitstyp (neues Feature vs. Bugfixes)
• Teamfokus (Unterbrechungen töten Velocity)

Manipuliere Velocity nicht. Sie ist keine Produktivitätsmetrik – sie ist ein Planungswerkzeug. Points aufzublähen oder Abkürzungen zu nehmen, um „Velocity zu erhöhen", verfehlt den Zweck.

Schätzungen sind Vermutungen. Sie werden falsch sein. XP erkennt das an und baut Anpassungsfähigkeit ein.

Häufige Schätzfehler:

• Unbekannte Unbekannte: Unvorhergesehene Komplexität taucht auf
• Abhängigkeiten: Externe Teams oder Systeme verursachen Verzögerungen
• Scope Creep: Die Story wächst während der Umsetzung
• Technical Debt: Bestehender Code ist schwerer zu ändern als erwartet

Was tun, wenn man vom Kurs abkommt:

1. Sofort ansprechen (Transparenz)
2. Neu schätzen basierend auf neuem Verständnis
3. Mit dem Product Owner besprechen
4. Bei Bedarf Scope verhandeln (kleineres Inkrement, Features verschieben)

Verstecke es nicht. Arbeite keine Überstunden, um eine schlechte Schätzung zu erreichen. Der ganze Sinn von Schätzung ist Planung – wenn der Plan falsch ist, ändere ihn.

Mit der Zeit verbessern sich Schätzungen. Wenn das Team Erfahrung mit der Codebasis und miteinander gewinnt, nimmt Unsicherheit ab. Aber sie werden nie perfekt sein – deshalb betont XP Anpassung statt Vorhersage.