Softwareprojekte schätzen: Agile Methoden zur Aufwandseinschätzung

Warum Softwareschätzungen so schwierig sind

**90 % aller Softwareprojekte dauern länger als geplant.** Das ist kein Versagen der Entwickler, sondern liegt in der Natur der Softwareentwicklung. Software ist komplex, Anforderungen ändern sich, und unvorhergesehene Probleme tauchen erst während der Umsetzung auf.

Die häufigsten Fehler bei Schätzungen

•Optimismus-Bias:: Wir unterschätzen den Aufwand systematisch

•Happy-Path-Denken:: Nur der ideale Weg wird geschätzt, nicht Fehlerbehandlung, Edge Cases, Testing

•Ankern:: Die erste Zahl, die genannt wird, beeinflusst alle weiteren Schätzungen

•Parkinsonsches Gesetz:: Arbeit dehnt sich auf die verfügbare Zeit aus

**Hofstadters Gesetz:** "Es dauert immer länger, als du erwartest, selbst wenn du Hofstadters Gesetz berücksichtigst."

Bewährte Schätzmethoden

Story Points statt Stunden

Statt in Stunden zu schätzen, verwenden agile Teams **Story Points** – eine relative Aufwandseinschätzung. "Ist dieses Feature größer oder kleiner als jenes?" ist leichter zu beantworten als "Wie viele Stunden braucht dieses Feature?"

Die **Fibonacci-Folge** (1, 2, 3, 5, 8, 13, 21) wird häufig verwendet, weil sie die zunehmende Unsicherheit bei größeren Aufgaben widerspiegelt.

Planning Poker

Das Team schätzt gemeinsam:

1. Ein Feature wird vorgestellt

2. Jedes Teammitglied wählt **verdeckt** eine Story-Point-Karte

3. Alle Karten werden gleichzeitig aufgedeckt

4. Bei großen Abweichungen diskutieren die Extreme ihre Begründung

5. Erneute Abstimmung

Der Vorteil: **Kein Gruppendruck**, alle Perspektiven fließen ein.

T-Shirt-Sizing

Noch grobgranularer: Features werden in **S, M, L, XL** eingeordnet. Besonders nützlich für frühe Projektphasen, wenn noch vieles unklar ist.

Drei-Punkt-Schätzung

Für jede Aufgabe werden drei Werte geschätzt:

•Optimistisch (O):: Wenn alles glatt läuft

•Realistisch (R):: Der wahrscheinlichste Aufwand

•Pessimistisch (P):: Wenn vieles schief geht

Der gewichtete Durchschnitt: **(O + 4R + P) / 6** liefert eine deutlich realistischere Schätzung.

Velocity: Daten statt Bauchgefühl

Nach einigen Sprints kennt ein Team seine **Velocity** – die durchschnittliche Anzahl an Story Points pro Sprint. Damit lassen sich Releases und Roadmaps **datenbasiert** planen statt auf Bauchgefühl.

Wichtige Regeln

•Nie die Velocity eines anderen Teams vergleichen: – Story Points sind teamspezifisch

•Mindestens 3–5 Sprints: abwarten, bevor die Velocity aussagekräftig ist

•Puffer einplanen:: Velocity × 0,7 für externe Kommunikation

Tipps für bessere Schätzungen

1. **Große Features aufteilen** – Aufgaben über 13 Story Points sind zu groß zum zuverlässigen Schätzen

2. **Vergangene Projekte analysieren** – wie genau waren Ihre letzten Schätzungen?

3. **Unsicherheiten explizit machen** – "wir wissen noch nicht, wie die API des Drittanbieters funktioniert"

4. **Testing und Bugfixing mitschätzen** – nicht nur die reine Entwicklung

Fazit

Perfekte Schätzungen gibt es nicht. Aber mit den richtigen Methoden und genug Daten werden Ihre Prognosen **deutlich realistischer**. Das schafft Vertrauen bei Stakeholdern und reduziert Stress im Team.