Schätzung für mobile Projekte — was ist das, Methoden zur Aufgabenbewertung

Was ist eine Schätzung?

Schätzung (vom englischen estimate — Bewertung) ist eine Vorhersage der Zeit oder des Aufwands, die für die Erledigung einer Aufgabe erforderlich sind. In der mobilen Entwicklung können Schätzungen in Stunden, Tagen, Story Points oder Geldbeträgen ausgedrückt werden. Der Zweck einer Schätzung ist nicht eine exakte Vorhersage, sondern die Reduzierung von Unsicherheit für die Entscheidungsfindung.

Wie sich eine Schätzung von einer Zusage unterscheidet

Schätzung ist eine Prognose mit Fehlertoleranz. Zusage (Commitment) ist ein Versprechen, eine Aufgabe bis zu einem bestimmten Datum zu erledigen. Der Unterschied ist entscheidend: Eine Schätzung sagt „wahrscheinlich 5 Tage“, eine Zusage sagt „wir schaffen es in 5 Tagen“. Manager verwechseln diese Konzepte oft und verwandeln eine Schätzung in eine Frist ohne Fehlertoleranz.

Die Schätzung als Kommunikationsinstrument

Der Schätzprozess ist nicht weniger wichtig als sein Ergebnis. Wenn das Team eine Aufgabenschätzung diskutiert, kommen versteckte Anforderungen, Abhängigkeiten und Risiken ans Licht. Selbst wenn die endgültige Zahl ungenau ist, gibt die Diskussion allen Beteiligten ein Verständnis der Aufgabe. Deshalb sind kollektive Schätzmethoden (Planning Poker) effektiver als individuelle.

Schätzmethoden in der Entwicklung

Es gibt mehrere Schätzmethoden, jede geeignet für verschiedene Projektphasen und Detailierungsgrade. Die Wahl der Methode hängt von den verfügbaren Daten und der erforderlichen Genauigkeit ab.

Planning Poker

Planning Poker ist die beliebteste Schätzmethode in Agile. Jeder Entwickler erhält ein Kartenspiel mit Fibonacci-Zahlen (1, 2, 3, 5, 8, 13, 21). Nach der Diskussion der Aufgabe zeigen alle gleichzeitig ihre Karte. Wenn die Schätzungen abweichen, erklären die Entwickler mit der niedrigsten und höchsten Schätzung ihre Logik, dann folgt eine erneute Abstimmung. Diese Methode eliminiert Autoritätsverzerrung und liefert eine genauere Schätzung.

T-Shirt sizing

T-Shirt sizing ist eine grobe Schätzung nach T-Shirt-Größe: XS, S, M, L, XL, XXL. Diese Methode wird für die schnelle Schätzung großer Aufgaben (Epics) in frühen Phasen verwendet, wenn Details unbekannt sind. Später wird jede dieser Aufgaben zerlegt und in Planning Poker geschätzt. T-Shirt sizing dauert 5-10 Minuten pro Aufgabe, liefert aber nur eine Größenordnung.

Drei-Punkt-Schätzung (PERT)

PERT verwendet drei Schätzungen: optimistisch (O), pessimistisch (P) und am wahrscheinlichsten (M). Die endgültige Schätzung wird mit der Formel (O + 4M + P) / 6 berechnet. Diese Methode berücksichtigt Unsicherheit und liefert ein realistischeres Ergebnis als eine einzelne Schätzung. PERT ist besonders nützlich für Aufgaben mit hohen Risiken oder neuen Technologien.

Schätzgenauigkeit: Erwartungen vs. Realität

Die Schätzgenauigkeit hängt von der Projektphase und der Menge bekannter Informationen ab. Je früher die Schätzung erfolgt, desto größer ist die Fehlertoleranz — das ist normal und sollte in der Planung berücksichtigt werden.

Unsicherheitskonus

Der Unsicherheitskonus (Cone of Uncertainty) ist ein Modell, das beschreibt, wie der Schätzfehler mit fortschreitendem Projekt abnimmt. In der Konzeptphase beträgt die Fehlertoleranz 400 % (eine Aufgabe kann 1 bis 4 Monate dauern). In der Sprintphase sind es 20 % (1-1,2 Monate). Das Verständnis dieses Modells hilft, in frühen Phasen keine genauen Schätzungen zu verlangen.

Faktoren, die die Genauigkeit beeinflussen

• Aufgabenkomplexität — ist es eine neue oder bekannte Technologie? Unbekanntes erhöht die Fehlertoleranz um das 2- bis 3-fache.
• Aufgabengröße — kleine Aufgaben (bis zu 2 Tagen) werden genauer geschätzt als große. Zerlegung verbessert die Genauigkeit.
• Team-Erfahrung — ein Team, das 6+ Monate zusammengearbeitet hat, schätzt 30-50 % genauer als ein neues.
• Historische Daten — Velocity-Metriken und Zyklometriedaten verbessern die Prognosegenauigkeit.

Relative vs. absolute Schätzung

Relative Schätzung (in Story Points) ist genauer als absolute Schätzung (in Stunden), weil Menschen besser darin sind, Aufgaben zu vergleichen als Zeit zu schätzen. „Diese Aufgabe ist doppelt so komplex wie jene“ ist ein zuverlässigeres Urteil als „diese Aufgabe wird 8 Stunden dauern“. Relative Schätzungen hängen nicht von einem bestimmten Entwickler ab und behalten ihre Genauigkeit bei einem Wechsel des Bearbeiters.

Wie man die Schätzgenauigkeit verbessert: Best Practices

Die Schätzgenauigkeit kann durch einen systematischen Ansatz, kollektive Diskussion und Analyse vergangener Fehler verbessert werden. Es gibt mehrere bewährte Praktiken.

Zerlegung auf 1-2 Tage

Jede Aufgabe, die auf mehr als 2 Tage geschätzt wird, sollte in Teilaufgaben zerlegt werden. Das Prinzip: Wenn eine Aufgabe nicht mit mehr als 50 % Genauigkeit geschätzt werden kann, ist sie zu groß. Teilen Sie sie in Schritte auf, die jeweils verständlich und schätzbar sind. Nach der Zerlegung ist die Gesamtschätzung oft 1,5- bis 2-mal größer als die ursprüngliche.

Historische Daten und Metriken

Führen Sie eine Schätzhistorie und vergleichen Sie diese mit dem tatsächlichen Aufwand. Zum Beispiel: „Aufgaben, die auf 3 Story Points geschätzt wurden, dauern im Durchschnitt 4 Tage, nicht 2“. Verwenden Sie die Team-Velocity für Prognosen: Wenn das Team 20 Story Points pro Sprint abschließt, planen Sie nicht 30. Die Analyse der Genauigkeit vergangener Schätzungen ist das beste Training für die Schätzfähigkeit.

Ankern und Kalibrierung

Ankern ist ein psychologischer Effekt, bei dem die zuerst genannte Schätzung alle Teilnehmer beeinflusst. Um Ankern in Planning Poker zu vermeiden, zeigen alle gleichzeitig ihre Karten, nicht der Reihe nach. Kalibrierung ist der regelmäßige Vergleich von Schätzungen mit Ist-Werten: Nach 10-20 Sprints lernt das Team durch Feedback, genauer zu schätzen.

Risikoadjustierte Schätzung

Jede Aufgabe enthält versteckte Risiken: Krankheit des Entwicklers, API-Probleme, Anforderungsänderungen. Fügen Sie Ihrer Schätzung einen risikoadjustierten Faktor hinzu: für Aufgaben mit hohem Risiko einen Multiplikator von 1,5-2, für niedriges Risiko 1,1-1,2. Zeigen Sie dem Kunden transparent, welche Risiken berücksichtigt wurden und wie sie sich auf die Zeitpläne auswirken.

Typische Schätzfehler

Schätzfehler wiederholen sich in den meisten Teams, unabhängig von ihrer Reife. Diese Fehler zu kennen, ist der erste Schritt zu ihrer Behebung.

Optimismusfehler

Der häufigste Fehler ist die Schätzung nach dem besten Szenario: „Wenn alles perfekt läuft, schaffen wir es in 3 Tagen“. In der Realität läuft nichts perfekt: Bugs, Fragen zu Anforderungen, abhängige Aufgaben. Lösung: Schätzen Sie nach dem wahrscheinlichsten Szenario, nicht nach dem optimistischen. Verwenden Sie PERT, um Variabilität zu berücksichtigen.

Schätzung unter Druck

Wenn ein Manager sagt „wir brauchen es bis Freitag“, passt der Entwickler unbewusst die Schätzung an diese Frist an. Schätzung unter Druck ist immer zu niedrig und führt zu Terminüberschreitungen. Lösung: Die Schätzung sollte der Frist vorausgehen, nicht umgekehrt. Zuerst schätzt das Team, dann einigen sich die Parteien auf die Zeitpläne.

Verwechslung von Komplexität und Zeit

Aufgabenkomplexität (wie viel Denkarbeit) und Zeit (wie viel Ausführung) sind unterschiedliche Metriken. Eine Aufgabe kann einfach aber zeitaufwendig sein (10 Bildschirme erstellen) oder komplex aber schnell (einen Bug in Legacy-Code finden). Story Points schätzen normalerweise die Komplexität, während die Zeit aus der Team-Velocity abgeleitet wird.

Ignorieren von Kontextwechseln

Ein Entwickler arbeitet nicht 8 Stunden ununterbrochen an einer einzigen Aufgabe: Meetings, Code-Reviews, Hilfe für Kollegen und administrative Aufgaben verbrauchen 30-50 % der Arbeitszeit. Kontextwechsel müssen in der Schätzung berücksichtigt werden: In Wirklichkeit schreibt ein Entwickler 3-4 Stunden pro Tag Code.