„Wie lange wird das dauern?“ ist die Frage, die jeder Stakeholder stellt. „Das kommt darauf an“ ist die ehrliche Antwort, aber keine hilfreiche.
Aufwandseinheiten schließen diese Lücke — sie bieten Stakeholdern Transparenz und erkennen gleichzeitig Unsicherheit an.
Was sind Aufwandseinheiten?
Aufwandseinheiten messen Komplexität und Aufwand, nicht Zeit. Betrachten Sie sie als relative Größeneinschätzung:
- 1 Punkt: Trivial (Button-Text ändern, Tippfehler beheben)
- 2 Punkte: Klein (Formularfeld hinzufügen, Farbschema aktualisieren)
- 3 Punkte: Einfach (Formularvalidierung hinzufügen, einfachen API-Endpunkt erstellen)
- 5 Punkte: Mittel (CRUD-Oberfläche bauen, Suche mit Filtern implementieren)
- 8 Punkte: Komplex (Drittanbieter-Integration, Echtzeit-Datensynchronisation)
- 13 Punkte: Sehr komplex (Zahlungsabwicklung, mehrstufiger Wizard)
- 21 Punkte: Groß (komplexe Geschäftslogik mit mehreren Integrationen)
- 34 Punkte: Sehr groß (ganzes Subsystem, z.B. Benachrichtigungssystem mit mehreren Kanälen)
- 55 Punkte: Ausnahme (plattformübergreifende Änderung, große Migration)
- 89 Punkte: Maximum — reserviert für seltene, gut abgegrenzte Epics, die sich nicht weiter aufteilen lassen
Wir verwenden die Fibonacci-Folge (1, 2, 3, 5, 8, 13, 21, 34, 55, 89), weil die Abstände zwischen den Zahlen mit steigender Komplexität größer werden. Der Unterschied zwischen einer 1-Punkt- und einer 2-Punkt-Aufgabe ist gering. Der Unterschied zwischen einer 13-Punkt- und einer 21-Punkt-Aufgabe ist erheblich — und diese Lücke spiegelt die zunehmende Unsicherheit bei größeren Arbeiten wider. Die meisten Feature-Anfragen liegen im Bereich 1–21; alles über 34 ist die Ausnahme und sollte normalerweise in kleinere Feature-Anfragen aufgeteilt werden.
Warum nicht einfach Stunden verwenden?
Früher haben wir in Stunden geschätzt. Deshalb haben wir gewechselt.
Entwicklergeschwindigkeit variiert
Dieselbe Aufgabe dauert unterschiedlich lange, je nachdem wer sie bearbeitet, welche Tools verwendet werden und wie vertraut die Person mit der Codebase ist. Stunden bestrafen Ehrlichkeit — schätzen Sie hoch, wirken Sie langsam; schätzen Sie niedrig, verpassen Sie Fristen.
Aufwandseinheiten trennen die Frage „Wie komplex ist das?“ von „Wie lange braucht diese bestimmte Person?“
In IEEE Software veröffentlichte Forschung[1] ergab, dass Expertenschätzungen, insbesondere relative Schätztechniken wie Aufwandseinheiten, tendenziell genauer sind als algorithmische Modelle für Softwareprojekte. Der entscheidende Vorteil ist, dass relative Größeneinschätzung (Aufgaben miteinander vergleichen) kognitiv einfacher und zuverlässiger ist als absolute Schätzung (Stunden vorhersagen).
Unbekannte Unbekannte
Die „5-Stunden-Aufgabe“ wird zu 15 Stunden, wenn Sie undokumentierte API-Eigenheiten, Inkompatibilitäten mit Legacy-Code oder Sicherheitsanforderungen entdecken, die niemand erwähnt hat. Stunden tun so, als wüssten wir mehr, als wir wissen.
Aufwandseinheiten akzeptieren Unsicherheit. Eine 5-Punkt-Aufgabe ist komplex, unabhängig von den Überraschungen, die sie birgt.
Druck zur Unterschätzung
Wenn Sie in Stunden schätzen, gibt es Druck, niedrig zu schätzen. „Können Sie es in 40 statt 60 Stunden schaffen?“ ist eine gängige Verhandlung. Der Entwickler sagt ja und spart dann entweder an der Qualität oder verpasst die Frist.
Aufwandseinheiten beseitigen diesen Druck. Sie sind abstrakt genug, dass niemand argumentiert: „Können Sie es in 5 statt 8 Punkten schaffen?“
Die State of Agile-Umfrage von VersionOne (jetzt Digital.ai)[2] verfolgt agile Praktiken weltweit seit über einem Jahrzehnt. Aufwandseinheiten bleiben die beliebteste Schätztechnik in agilen Teams, wobei relative Schätzung von der Mehrheit der Befragten übernommen wird. Die Langlebigkeit der Technik spricht für ihren praktischen Nutzen, obwohl sie designbedingt „ungenau“ ist.
Wie wir schätzen
Schritt 1: Referenz-Feature-Anfragen definieren
Wir legen Baseline-Komplexitätsstufen fest, auf die sich das gesamte Team einigt:
1 Punkt — „Text aktualisieren“
├─ Button-Beschriftung ändern
├─ Farbvariable aktualisieren
└─ Tippfehler in Texten beheben
3 Punkte — „Einfaches Feature“
├─ Formularfeld mit Validierung hinzufügen
├─ Einfachen API-Endpunkt erstellen
└─ Unit-Tests für bestehenden Code hinzufügen
5 Punkte — „Standard-Feature“
├─ Listenansicht mit Paginierung bauen
├─ Authentifizierungsablauf hinzufügen
└─ Suche mit Filtern implementieren
8 Punkte — „Komplexes Feature“
├─ Drittanbieter-API integrieren
├─ Echtzeit-Datensynchronisation bauen
└─ Komplexe Geschäftsregeln implementieren
13 Punkte — „Sehr komplexes Feature“
├─ Zahlungsabwicklungs-Integration
├─ Mehrstufiger Onboarding-Wizard
└─ Rollenbasiertes Berechtigungssystem
Schritt 2: Relative Größeneinschätzung
Neue Aufgaben werden mit Referenz-Feature-Anfragen verglichen:
Frage: „Ist dieses Benachrichtigungssystem eher wie das 5-Punkt-Suchfeature oder die 8-Punkt-Drittanbieter-Integration?“
Antwort: „Es hat externe Abhängigkeiten (E-Mail-Provider, Push-Benachrichtigungen), also liegt es näher an 8 Punkten.“
Schritt 3: Team-Konsens
Mehrere Personen schätzen unabhängig und vergleichen dann. Wenn Schätzungen deutlich abweichen, offenbart die Diskussion Annahmen, die geklärt werden müssen. Das dauert 2–5 Minuten pro Feature-Anfrage und fängt Missverständnisse ab, bevor die Arbeit beginnt.
Von Aufwandseinheiten zum Zeitplan
Aufwandseinheiten allein beantworten nicht „Wann ist es fertig?“. Dafür brauchen Sie die Liefergeschwindigkeit.
Was ist Liefergeschwindigkeit?
Liefergeschwindigkeit ist die Anzahl der Aufwandseinheiten, die pro Entwicklungszyklus abgeschlossen werden. Nach einigen Entwicklungszyklen stabilisiert sich die Liefergeschwindigkeit und wird zu einem zuverlässigen Planungsinstrument.
Beispiel:
- Entwicklungszyklus 1: 22 Punkte abgeschlossen
- Entwicklungszyklus 2: 28 Punkte abgeschlossen
- Entwicklungszyklus 3: 25 Punkte abgeschlossen
- Durchschnittliche Liefergeschwindigkeit: 25 Punkte/Entwicklungszyklus
Zeitplan-Schätzung
Mit einer bekannten Liefergeschwindigkeit ist die Zeitplanschätzung unkompliziert:
Projekt-Backlog: 100 Aufwandseinheiten
Team-Liefergeschwindigkeit: 25 Punkte/Entwicklungszyklus
Zyklusdauer: 2 Wochen
Zeitplan: 100 ÷ 25 = 4 Entwicklungszyklen = 8 Wochen
Das ist kein Versprechen — es ist eine Prognose auf Basis historischer Daten. Die tatsächliche Liefergeschwindigkeit variiert von Entwicklungszyklus zu Entwicklungszyklus, weshalb wir regelmäßig neu prognostizieren.
Häufige Einwände
„Aufwandseinheiten sind willkürlich!“
Ja. Stunden auch. Zumindest geben Aufwandseinheiten zu, dass sie Schätzungen sind, anstatt Präzision vorzutäuschen.
„Warum nicht einfach T-Shirt-Größen verwenden?“
Haben wir versucht. Stakeholder fragen „Wie viele Smalls passen in einen Entwicklungszyklus?“ und Sie sind wieder beim Quantifizieren. Aufwandseinheiten sind bereits quantifiziert, was die Planung einfacher macht.
„Mein Team kann sich nicht auf Schätzungen einigen!“
Das ist ein Feature, kein Bug. Wenn eine Person „3 Punkte“ sagt und eine andere „13 Punkte“, sehen sie unterschiedliche Dinge. Die anschließende Diskussion deckt Annahmen auf, klärt Anforderungen und verhindert Überraschungen während der Implementierung.
„Das fühlt sich wie zusätzlicher Overhead an!“
Schätzung kostet vorab Zeit. Aber sie verhindert kostspielige Überraschungen mitten im Projekt. Eine 30-minütige Planungssitzung, die eine missverstandene Anforderung aufdeckt, spart Wochen an Nacharbeit.
Wenn Aufwandseinheiten schiefgehen
Aufwandseinheiten sind kein Wundermittel. Sie gehen schief, wenn:
- Schätzungen nie aktualisiert werden: Wenn sich eine 5-Punkt-Aufgabe mitten im Entwicklungszyklus als 13 Punkte herausstellt, sagen Sie es. Stakeholder schätzen Ehrlichkeit mehr als falschen Optimismus.
- Punkte für Leistungsbeurteilungen verwendet werden: Aufwandseinheiten messen Komplexität, nicht Produktivität. Sie zum Vergleich von Entwicklern oder Teams zu verwenden, verfehlt den Zweck.
- Große Feature-Anfragen nicht aufgeteilt werden: Alles über 13 Punkte hat zu viel Unsicherheit. Teilen Sie es in kleinere, besser verstandene Feature-Anfragen auf.
- Liefergeschwindigkeit als Ziel behandelt wird: Liefergeschwindigkeit ist eine Messung, kein Ziel. Teams zu drängen, die „Velocity zu erhöhen“, führt nur zu aufgeblähten Schätzungen.
Best Practices
1. Bei Bedarf neu schätzen
Wenn eine Aufgabe schwieriger ist als erwartet, aktualisieren Sie die Schätzung. Das ist kein Scheitern — es ist Information, die zukünftige Schätzungen genauer macht.
2. Liefergeschwindigkeit über die Zeit verfolgen
Liefergeschwindigkeit stabilisiert sich nach 3–4 Entwicklungszyklen. Verwenden Sie historische Liefergeschwindigkeit für Prognosen, nicht Wunschdenken.
3. Große Feature-Anfragen aufteilen
Wenn Sie nicht in einem Satz erklären können, was eine Feature-Anfrage liefert, ist sie zu groß. Teilen Sie sie auf.
4. Alle Arbeit in die Liefergeschwindigkeit einbeziehen
Code Review, Deployment, Bugfixes — all das ist echte Arbeit. Ihre Liefergeschwindigkeit sollte die tatsächliche Kapazität widerspiegeln, nicht nur Feature-Entwicklung.
5. Das System nicht manipulieren
Schätzungen aufzublähen, um produktiver zu wirken, ist verlockend und sinnlos. Liefergeschwindigkeit dient der Planung, nicht der Leistungsbewertung.
Das Fazit
Aufwandseinheiten sind nicht perfekt. Aber sie sind besser als die Alternativen:
- Festpreisverträge führen zu Qualitätseinbußen
- Stundenabrechnung belohnt Langsamkeit
- „Wir sagen Ihnen, wenn es fertig ist“ bietet keine Transparenz
Aufwandseinheiten geben Stakeholdern Vorhersehbarkeit, Flexibilität und Einblick in das, was ihr Geld bewirkt.
Möchten Sie transparente Projektschätzungen? Aufwandseinheiten-Schätzung erhalten →
