Die minimal nützliche Schätzung

Die meisten Teams investieren zu viel in Schätzungspräzision. Sie debattieren zehn Minuten lang, ob ein Ticket eine 5 oder eine 8 ist – eine Unterscheidung, die keinerlei Auswirkung auf die Sprint-Planung und noch weniger auf die Lieferung hat. Die Zeit, die mit der Diskussion über Granularität verbracht wird, ist Zeit, die nicht für das Verständnis der Arbeit aufgewendet wird.

Drei Größen – klein, mittel, groß – decken die große Mehrheit der Planungsbedürfnisse ab. Ein kleines Ticket ist gut verstandene Arbeit, die ein Entwickler an einem Tag oder weniger erledigen kann. Ein mittleres ist ein bis drei Tage mit etwas Komplexität oder Unbekannten. Ein großes ist mehr als drei Tage und muss wahrscheinlich aufgeteilt werden, bevor jemand anfängt.

Das ist alles. Wenn Ihr Team Tickets konsistent in diese drei Kategorien einordnen kann, haben Sie genug Informationen, um einen Sprint zu planen, überlastete Wochen zu erkennen und Tickets zu identifizieren, die mehr Diskussion benötigen. Der Mehrwert, „mittel" in 3, 5 und 8 aufzuteilen, ist für manche Teams real – aber die meisten Teams brauchen das nicht, und die Komplexität kostet mehr als die Präzisionsgewinne.

Beginnen Sie mit S/M/L. Wenn Sie nach ein paar Sprints feststellen, dass Ihre Planung konsistent eine feinere Auflösung benötigt – vielleicht variieren große Tickets zu stark, oder Sie machen externe Zusagen, die engere Prognosen erfordern – steigen Sie auf Fibonacci oder T-Shirt-Größen um. Aber treffen Sie diese Entscheidung als Pull-Entscheidung basierend auf Evidenz, nicht als Push-Entscheidung basierend darauf, was ein Framework Ihnen gesagt hat.

S/M/L funktioniert nicht mehr, wenn jemand außerhalb des Teams mehr als „ungefähr wie viel Arbeit ist das?" braucht. Drei Situationen drängen Sie zu feinkörnigerer Schätzung:

Externe Zusagen. Wenn ein Vertriebsteam einem Kunden sagen muss „Feature X wird in Q3 ausgeliefert", muss das Entwicklungsteam mit genug Auflösung schätzen, um dieses Datum zu untermauern. S/M/L kann nicht zwischen „drei Wochen" und „drei Monaten" unterscheiden. Fibonacci-Schätzungen kombiniert mit historischen Velocity-Daten können es – nicht perfekt, aber gut genug, um eine Spanne statt eines Achselzuckens zu geben.

Budgetierung und Personalplanung. Ein Produktteam, das entscheidet, ob Projekt A oder Projekt B finanziert wird, muss deren Kosten vergleichen. „Projekt A hat 40 Story Points und Projekt B hat 90" ist ein grober, aber nützlicher Input. „Projekt A hat einige mittlere und Projekt B hat mehr große" ist es nicht.

Abhängigkeitsplanung. Wenn die Arbeit von Team A blockiert ist, bis Team B eine Voraussetzung fertigstellt, brauchen beide Teams genug Schätzungspräzision, um Zeitpläne zu koordinieren. „Wir sind irgendwann im nächsten Sprint oder zwei fertig" reicht nicht, wenn ein nachgelagertes Team seine Arbeit um die Übergabe herum plant.

In allen drei Fällen zahlt sich die Investition in Präzision aus, weil jemand eine Entscheidung basierend auf der Schätzung trifft. Wenn niemand eine Entscheidung trifft – wenn die Schätzungen in einen Tracker wandern und niemand sie ansieht – sparen Sie die Zeit.

Die größte Bedrohung für ehrliche Schätzung ist Verankerung: Die erste laut ausgesprochene Zahl verzerrt jede folgende Zahl. Wenn der Tech Lead sagt „Ich denke, das ist etwa eine 3", zweifelt der Junior-Entwickler, der an 8 dachte, an sich selbst und sagt 5. Das Team konvergiert auf eine Zahl, die die lauteste Stimme widerspiegelt, nicht das kollektive Verständnis.

Planning Poker löst dies mechanisch. Alle schätzen gleichzeitig und decken gleichzeitig auf. Es gibt keinen Anker, weil es keine erste Zahl gibt. Die Streuung – die Lücke zwischen der höchsten und niedrigsten Schätzung – ist das Signal. Eine einstimmige 3 bedeutet, dass das Team übereinstimmt und Sie weitermachen. Eine Aufteilung zwischen 2 und 13 bedeutet, dass zwei Personen sich grundlegend unterschiedliche Arbeit vorstellen, und dieses Gespräch muss stattfinden, bevor jemand Code schreibt.

Asynchrone Schätzung erweitert dies auf verteilte Teams. Statt sich in einem Raum zu versammeln, reichen Entwickler Schätzungen unabhängig über ein Zeitfenster ein, wobei die Stimmen verborgen bleiben, bis alle abgegeben haben. Der Anti-Verankerungs-Vorteil ist derselbe; die Logistik passt zu Teams, die Zeitzonen überspannen oder synchrone Meetings für jeden Ticket-Stapel nicht rechtfertigen können.

Beide Ansätze teilen dasselbe Prinzip: Schätzung funktioniert am besten, wenn Meinungen sich unabhängig bilden, bevor sie geteilt werden. Jede Methode, die die Zahl des Senior-Entwicklers den Raum beeinflussen lässt, bevor andere sich auf ihre eigene Schätzung festgelegt haben, lässt Informationen auf dem Tisch liegen.