Relative Schätzung in Agile: Der vollständige Leitfaden zur Arbeitsbewertung ohne Stunden

Relative Schätzung ist eine Technik, bei der Teams Arbeitspakete durch Vergleich untereinander bewerten, anstatt in absoluten Einheiten wie Stunden oder Tagen zu schätzen. Anstatt zu fragen „Wie lange wird das dauern?", fragen Teams „Ist das größer oder kleiner als das andere, was wir gemacht haben?" Dieser Perspektivwechsel ist eines der wirkungsvollsten - und am häufigsten missverstandenen - Konzepte in Agile. Teams, die relative Schätzung anwenden, erstellen durchgängig genauere Prognosen, verbringen weniger Zeit mit Schätzungen und decken versteckte Risiken früher auf. Dieser Leitfaden behandelt, warum relative Schätzung funktioniert, welche Techniken verfügbar sind, wie man sie implementiert und welche Fehler Teams zum Scheitern bringen.

Schnellantwort: Relative vs. Absolute Schätzung

Aspekt	Relative Schätzung	Absolute Schätzung
Was Sie schätzen	Größe im Vergleich zu anderen Arbeitspaketen	Stunden, Tage oder Kalenderzeit
Kernfrage	„Ist das größer oder kleiner als X?"	„Wie viele Stunden wird das dauern?"
Maßeinheit	Story Points, T-Shirt-Größen oder Kategorien	Stunden, Tage oder Personentage
Genauigkeit	Bewusst grob (z.B. Fibonacci-Skala)	Scheinbar präzise („genau 14 Stunden")
Personenabhängig	Nein - das Team schätzt gemeinsam	Ja - hängt davon ab, wer die Arbeit erledigt
Treffsicherheit über Zeit	Verbessert sich, wenn das Team die Velocity kalibriert	Bleibt inkonsistent, unabhängig von der Übung
Am besten für	Sprint Planning, Release-Prognosen, Backlog-Dimensionierung	Aufgabenzerlegung innerhalb einer Story, Zeiterfassung

Was ist relative Schätzung?

Die zentrale Erkenntnis

Relative Schätzung ist die Praxis, Arbeitspakete durch Vergleich untereinander zu bewerten, anstatt absolute Zeitwerte zuzuweisen. Wenn ein Team relative Schätzung verwendet, fragt es nicht „Wie viele Stunden wird diese Story dauern?", sondern „Wie verhält sich diese Story im Vergleich zu anderen Stories, die wir bereits bewertet oder abgeschlossen haben?"

Das Ergebnis ist eine relative Größe - eine Zahl, ein Label oder eine Kategorie, die das Element auf einer Skala im Vergleich zu allem anderen im Product Backlog einordnet. Eine Story, die auf 8 Punkte geschätzt wird, bedeutet nicht „8 Stunden" oder „8 Tage" - sie bedeutet „diese Story ist ungefähr 8/5 so groß wie unsere 5-Punkte-Referenz-Story."

Eine einfache Analogie

Stellen Sie sich vor, Sie sortieren einen Stapel Steine nach Gewicht. Sie haben zwei Möglichkeiten:

1. Absoluter Ansatz: Jeden Stein auf einer Waage wiegen, die Gramm notieren und nach Zahl sortieren.
2. Relativer Ansatz: Zwei Steine aufnehmen - einen in jeder Hand - und fühlen, welcher schwerer ist. Mit anderen Steinen wiederholen, bis Sie sie von leicht nach schwer sortiert haben.

Der relative Ansatz ist schneller, benötigt keine Werkzeuge und liefert eine brauchbare Reihenfolge. Sie kennen nicht das genaue Gewicht jedes Steins, aber Sie wissen mit Sicherheit, dass Stein C etwa doppelt so schwer ist wie Stein A. Für Planungszwecke - „Kann ich diese Steine in einer Fahrt transportieren?" - reicht der relative Vergleich in der Regel aus.

Softwareschätzung funktioniert genauso. Sie müssen selten exakte Stunden wissen. Sie müssen die relative Größe kennen, um beantworten zu können: „Passt diese Arbeit in den nächsten Sprint?"

Warum relative Schätzung besser funktioniert als absolute

Die Psychologie: Das Weber-Fechner-Gesetz

Das Weber-Fechner-Gesetz, das im 19. Jahrhundert formuliert wurde, besagt, dass Menschen Unterschiede in Reizen proportional und nicht absolut wahrnehmen. Sie können den Unterschied zwischen dem Heben eines 1-kg-Gewichts und eines 2-kg-Gewichts leicht erkennen (100% Unterschied). Aber den Unterschied zwischen einem 50-kg-Gewicht und einem 51-kg-Gewicht (2% Unterschied) zu erkennen, ist viel schwieriger, obwohl beide Unterschiede genau 1 kg betragen.

Dieses Gesetz erklärt, warum die Fibonacci-Sequenz so gut für Schätzungen funktioniert. Die Abstände zwischen den Werten wachsen proportional: 1-2-3-5-8-13-21. Jede Zahl ist ungefähr 60% größer als die vorherige. Das spiegelt wider, wie unser Gehirn Größenordnungen tatsächlich verarbeitet - wir unterscheiden proportionale Unterschiede, keine absoluten.

Wenn Teams in Stunden schätzen, werden sie gezwungen, absolute Urteile zu fällen, für die ihr Gehirn nicht gemacht ist. Wenn sie in relativen Größen mit wachsenden Intervallen schätzen, arbeiten sie mit ihren kognitiven Stärken statt dagegen.

Kognitionswissenschaft: Vergleich vs. Vorhersage

Forschung in der kognitiven Psychologie zeigt durchgehend, dass Menschen wesentlich besser im Vergleichen sind als im Vorhersagen:

• Vergleich (relativ): „Ist der Aufbau dieses API-Endpunkts größer oder kleiner als die Login-Funktion, die wir im letzten Sprint gebaut haben?" Ihr Gehirn ruft eine konkrete Erinnerung ab und macht einen schnellen Vergleich. Dies aktiviert das Wiedererkennungsgedächtnis, das schnell und zuverlässig ist.
• Vorhersage (absolut): „Wie viele Stunden wird dieser API-Endpunkt dauern?" Ihr Gehirn muss die gesamte zukünftige Ausführung der Aufgabe simulieren - jeden Sonderfall, jede Unterbrechung, jede Unbekannte. Dies aktiviert die konstruktive Vorstellungskraft, die langsam und unzuverlässig ist.

Teams, die von Stunden auf relative Schätzung umsteigen, sehen typischerweise innerhalb von 4-6 Sprints eine Verbesserung ihrer Prognosegenauigkeit, weil sie aufhören, gegen ihre eigene kognitive Architektur zu kämpfen.

Der Anker-Vorteil

Relative Schätzung gibt Teams einen konkreten Anker - eine Referenz-Story - der die Schätzung schneller und konsistenter macht. Ohne Anker beginnt jede Schätzsitzung von Null: „Also... sind das 16 Stunden?" Mit einer Referenz-Story ist das Gespräch fundiert: „Unsere 5-Punkte-Referenz-Story war die Benutzerprofil-API. Diese neue Story ist ähnlich komplex, aber mit mehr Unsicherheit durch die Drittanbieter-Integration, also ist sie wahrscheinlich eine 8."

Verankerung reduziert auch die Streuung der Schätzungen innerhalb eines Teams. Wenn alle gegen die gleiche Referenz vergleichen, konvergieren ihre Schätzungen natürlich. Ohne Referenz verankert jede Person an ihrem eigenen privaten mentalen Modell, was zu größerer Abweichung führt.

Unsicherheit absorbieren

Absolute Schätzungen erzeugen Druck für falsche Präzision. „14 Stunden" zu sagen impliziert, dass Sie die Aufgabendauer mit einer Genauigkeit kennen, die Softwareentwicklung selten unterstützt. Wenn aus diesen 14 Stunden dann 22 Stunden werden, fühlt es sich wie ein Versagen an.

Relative Schätzungen begrüßen Unsicherheit von Natur aus. Zu sagen „das ist ungefähr so groß wie diese 8-Punkte-Story" erkennt an, dass Sie die genauen Stunden nicht kennen - und auch nicht kennen müssen. Die wachsenden Abstände der Fibonacci-Skala verhindern bewusst falsche Präzision: Sie können nicht „das ist eine 6" sagen, wenn Ihre Auswahlmöglichkeiten 5 oder 8 sind, und diese Grobheit ist ein Merkmal, kein Fehler.

Der Referenz-Story-Ansatz

Die richtige Basislinie wählen

Eine Referenz-Story ist ein gut verstandenes, abgeschlossenes Arbeitselement, das das Team als Maßstab für alle zukünftigen Schätzungen verwendet. Die Wahl der richtigen Referenz-Story ist entscheidend - sie wird zum Lineal, an dem alles andere gemessen wird.

Eigenschaften einer guten Referenz-Story:

• Das Team hat sie kürzlich genug abgeschlossen, um sich an die Details zu erinnern
• Sie war ein mittelgroßes Arbeitselement (weder das Kleinste noch das Größte)
• Aufwand, Komplexität und Unsicherheit waren alle moderat
• Die meisten Teammitglieder haben daran gearbeitet oder sind damit vertraut
• Sie repräsentiert eine typische Arbeitsart für das Team

Weisen Sie Ihrer Referenz-Story einen Wert in der Mitte Ihrer Skala zu - typischerweise 3 oder 5 auf einer Fibonacci-Skala.

Einen Referenzkatalog aufbauen

Eine einzelne Referenz-Story reicht nicht aus. Bauen Sie einen Katalog von 5-7 Referenz-Stories auf, die Ihre Schätzskala abdecken:

Punkte	Referenz-Story	Warum diese Größe
1	Tooltip zu einem vorhandenen Button hinzufügen	Trivialer Aufwand, keine Komplexität, keine Unsicherheit
2	Eingabevalidierung zu einem bestehenden Formularfeld hinzufügen	Geringer Aufwand, niedrige Komplexität, keine Unsicherheit
3	Neuen API-Endpunkt mit Standard-CRUD erstellen	Moderater Aufwand, niedrige Komplexität, minimale Unsicherheit
5	Benutzerprofilseite mit API-Integration bauen	Erheblicher Aufwand, moderate Komplexität, etwas Unsicherheit
8	Drittanbieter-Zahlungsgateway integrieren	Großer Aufwand, hohe Komplexität, beachtliche Unsicherheit
13	Benachrichtigungssystem mit Echtzeit-Push neu gestalten	Sehr großer Aufwand, hohe Komplexität, erhebliche Unsicherheit

Überprüfen und aktualisieren Sie diesen Katalog vierteljährlich oder wenn sich die Teamzusammensetzung wesentlich ändert. Neue Teammitglieder sollten diese Referenz-Stories vor ihrer ersten Schätzsitzung studieren.

Kalibrierung im Laufe der Zeit

Relative Schätzung verbessert sich durch Kalibrierung - den Prozess, Schätzungen mit tatsächlichen Ergebnissen zu vergleichen und anzupassen:

1. Sprint Retrospective Überprüfung: „Wir haben das auf 5 Punkte geschätzt, aber es war eindeutig eine 8 - was haben wir übersehen?"
2. Mustererkennung: „Wir unterschätzen Stories mit Datenbankmigrationen durchgehend um etwa eine Fibonacci-Stufe."
3. Referenzaktualisierung: „Unsere 5-Punkte-Referenz-Story spiegelt nicht mehr wider, wie sich eine 5 anfühlt. Wählen wir eine bessere aus."

Diese Kalibrierungsschleife ist der Motor, der relative Schätzung im Laufe der Zeit immer genauer macht. Teams, die die Kalibrierung überspringen, bleiben bei verrauschten Schätzungen hängen, die sich nie verbessern.

Techniken der relativen Schätzung

Story Points

Story Points sind die am weitesten verbreitete Einheit für relative Schätzung. Jeder Story Point repräsentiert eine Mischung aus Aufwand, Komplexität und Unsicherheit - ausgedrückt als einzelne Zahl auf einer relativen Skala.

Wesentliche Merkmale:

• Teamspezifisch: Eine 5-Punkte-Story in Team A ist nicht dasselbe wie eine 5-Punkte-Story in Team B
• Skalenbasiert: Verwendet typischerweise Fibonacci (1, 2, 3, 5, 8, 13, 21) oder modifizierte Fibonacci
• Velocity-verbunden: Gesamte Story Points pro Sprint abgeschlossen = Velocity
• Nicht in Stunden umrechenbar: Es gibt keine gültige Story-Point-zu-Stunden-Umrechnung

Story Points sind ideal für Sprint-Planung und Release-Prognosen. Sie erfordern eine Investition in Referenz-Stories, Kalibrierung und Team-Konsistenz - aber der Ertrag sind zuverlässige Velocity-Daten innerhalb von 4-6 Sprints.

T-Shirt-Größen

T-Shirt-Größen verwenden Labels statt Zahlen: XS, S, M, L, XL, XXL. Es ist die zugänglichste Form der relativen Schätzung, weil jeder intuitiv versteht, dass ein „Large" größer ist als ein „Small".

Am besten geeignet für:

• Initiale Backlog-Dimensionierung, wenn Sie 50-200 Elemente schnell bewerten müssen
• Roadmap-Planung, bei der Präzision nicht nötig ist
• Teams, die neu bei der relativen Schätzung sind und Zahlen einschüchternd finden
• Stakeholder-Kommunikation (einfacher zu erklären als Story Points)

Einschränkung: T-Shirt-Größen lassen sich nicht zu einer Velocity aggregieren. Sie können nicht „2 Medium und 1 Large" zusammenrechnen, um eine Kapazitätszahl zu erhalten. Viele Teams beginnen mit T-Shirt-Größen und wechseln zu Story Points, sobald sie sich mit dem relativen Denken wohlfühlen.

Fibonacci-Sequenz-Skala

Die Fibonacci-Sequenz (1, 2, 3, 5, 8, 13, 21) ist die gängigste Skala für relative Schätzung, weil ihre wachsenden Abstände widerspiegeln, wie die menschliche Wahrnehmung funktioniert. Die Sequenz zwingt Schätzer, am unteren Ende bedeutsame Unterscheidungen zu treffen (ist das eine 2 oder eine 3?), während sie am oberen Ende falsche Präzision verhindert (es gibt keine Option zwischen 13 und 21).

Warum Fibonacci für Schätzungen funktioniert:

• Das Abstandswachstum entspricht dem Weber-Fechner-Gesetz der abnehmenden Wahrnehmung
• Verhindert Debatten über bedeutungslose Unterschiede („ist das eine 14 oder eine 15?")
• Erzwingt, dass Stories über 13 aufgeteilt werden - große Elemente tragen zu viel Unsicherheit
• Jeder Wert ist ungefähr 60% größer als der vorherige, was konsistente proportionale Sprünge erzeugt

Manche Teams verwenden modifizierte Fibonacci (1, 2, 3, 5, 8, 13, 20, 40, 100), die 21 durch 20 für einfacheres Kopfrechnen ersetzt und 40 und 100 für Backlog-Elemente hinzufügt, die noch aufgeteilt werden müssen.

Affinitätsschätzung

Affinitätsschätzung ist eine schnelle Technik zur Dimensionierung großer Mengen von Elementen. Das Team gruppiert Elemente physisch oder virtuell in relative Größenkategorien, indem es sie miteinander vergleicht - nicht indem jedes einzelne im Detail diskutiert wird.

So funktioniert es:

1. Die Skala auslegen (Spalten mit 1, 2, 3, 5, 8, 13 beschriften)
2. Das erste Element als Startreferenz in die mittlere Spalte legen
3. Teammitglieder platzieren die verbleibenden Elemente stillschweigend in Spalten basierend auf der relativen Größe
4. Die Gruppierungen überprüfen, Meinungsverschiedenheiten diskutieren und anpassen

Geschwindigkeitsvorteil: Affinitätsschätzung kann 50-100 Elemente in 30-60 Minuten dimensionieren - 10x schneller als Planning Poker für die gleiche Anzahl von Elementen.

Am besten geeignet für: Initiale Dimensionierung eines großen Backlogs, PI-Planung in skalierten Frameworks und jede Situation, in der Sie schnell grobe Schätzungen für viele Elemente benötigen.

Planning Poker

Planning Poker ist der Goldstandard für detaillierte relative Schätzung. Jeder Developer wählt gleichzeitig eine Karte mit seiner Schätzung aus, wodurch Ankerverzerrungen verhindert werden. Wenn Schätzungen auseinandergehen, diskutiert das Team - und diese Diskussionen sind oft der wertvollste Teil des Prozesses.

So funktioniert es:

1. Der Product Owner stellt die Story vor und beantwortet Fragen
2. Jeder Developer wählt privat eine Fibonacci-Karte
3. Alle Karten werden gleichzeitig aufgedeckt
4. Wenn Schätzungen konvergieren (z.B. alle zeigen 5 oder 8), wird schnell Konsens erreicht
5. Wenn Schätzungen divergieren (z.B. einer zeigt 3 und ein anderer 13), erklären die Ausreißer ihre Begründung
6. Nach der Diskussion erneut abstimmen, typischerweise Konvergenz innerhalb von 2-3 Runden

Am besten geeignet für: Sprint-Level-Verfeinerung von 5-15 Elementen, bei der detaillierte Diskussion und Risikoerkennung wichtig sind.

Relative Schätzung implementieren: Schritt für Schritt

Schritt 1: Wählen Sie Ihre Technik

Wählen Sie die Technik, die zu Ihrem aktuellen Bedarf passt:

Situation	Empfohlene Technik
Neues Team, erste Schätzung	T-Shirt-Größen (niedrige Einstiegshürde)
Großes Backlog braucht initiale Dimensionierung (50+ Elemente)	Affinitätsschätzung
Sprint-Level-Verfeinerung (5-15 Elemente)	Planning Poker mit Story Points
Roadmap- oder PI-Planung	T-Shirt-Größen oder Affinitätsschätzung
Erfahrenes Team, stabiles Backlog	Story Points mit schnellem Konsens

Schritt 2: Referenz-Stories festlegen

Bevor Sie Ihre erste Schätzsitzung durchführen, identifizieren Sie 3-5 abgeschlossene Stories, die Ihre Skala abdecken. Präsentieren Sie sie dem Team und einigen Sie sich auf ihre relativen Größen. Schreiben Sie sie auf - diese werden Ihr Kalibrierungsanker für jede zukünftige Sitzung.

Schritt 3: Die erste Sitzung durchführen

Für Planning Poker:

• Beginnen Sie mit den Referenz-Stories sichtbar an einem Board oder geteilten Bildschirm
• Stellen Sie jede neue Story vor, lassen Sie Fragen zum Umfang und den Akzeptanzkriterien zu
• Lassen Sie jeden Developer privat eine Karte wählen, dann gleichzeitig aufdecken
• Divergenzen diskutieren, dann erneut abstimmen
• Streben Sie 2-5 Minuten pro Story an - wenn Sie nicht konvergieren können, nehmen Sie die höhere Schätzung und machen weiter

Für Affinitätsschätzung:

• Die Skalenspalten auslegen
• Eine Referenz-Story pro Spalte platzieren
• Teammitglieder platzieren die restlichen Stories stillschweigend
• Die Gruppierungen durchgehen, diskutieren und anpassen
• Streben Sie 10-20 Sekunden pro Story an

Schritt 4: Velocity verfolgen (bei Verwendung von Story Points)

Notieren Sie nach jedem Sprint die Gesamtzahl der abgeschlossenen Story Points (nur Stories, die die Definition of Done erfüllen). Nach 4-6 Sprints haben Sie genug Daten für zuverlässige Velocity-basierte Prognosen.

Schritt 5: In Retrospektiven kalibrieren

Verbringen Sie in jeder Sprint Retrospective 5 Minuten mit der Überprüfung der Schätzgenauigkeit:

• Waren Stories deutlich größer oder kleiner als geschätzt?
• Was hat die Überraschung verursacht?
• Sollten Referenz-Stories aktualisiert werden?
• Gibt es systematische Muster (z.B. „wir unterschätzen immer Integrationsarbeit")?

Schritt 6: Ihre Skala verfeinern

Nach 6-10 Sprints evaluieren Sie, ob Ihre Skala noch funktioniert:

• Wenn sich alles bei 3-5 häuft, könnten Ihre Referenz-Stories zu grob sein
• Wenn Sie regelmäßig Werte von 13+ verwenden, muss Ihr Team möglicherweise aggressiver aufteilen
• Wenn die Velocity instabil ist, untersuchen Sie, ob Schätzkonsistenz oder externe Faktoren die Ursache sind

Schritt 7: Mit der Planung integrieren

Sobald die Velocity stabil ist (Variationskoeffizient unter 25%), verwenden Sie sie für:

• Sprint Planning: Wählen Sie ungefähr den Umfang einer Sprint-Velocity in Story Points
• Release-Planung: Teilen Sie die verbleibenden Backlog-Punkte durch die durchschnittliche Velocity, um den Abschluss zu prognostizieren
• Kapazitätsplanung: Verwenden Sie Velocity-Spannen (beste/durchschnittliche/schlechteste) für probabilistische Prognosen

Relative vs. absolute Schätzung: Detaillierter Vergleich

Dimension	Relative Schätzung	Absolute Schätzung
Kognitive Belastung	Niedrig - Mustererkennung und Vergleich	Hoch - erfordert Simulation der zukünftigen Ausführung
Geschwindigkeit	Schnell - die meisten Elemente in 1-3 Minuten geschätzt	Langsam - detaillierte Aufgabenzerlegung erforderlich
Genauigkeit (einzelnes Element)	Niedrig - jede einzelne Schätzung kann um eine Fibonacci-Stufe daneben liegen	Mittel - Stundenschätzungen können bei vertrauter Arbeit nah dran sein
Genauigkeit (aggregiert)	Hoch - Über- und Unterschätzungen gleichen sich über einen Sprint aus	Niedrig - Fehler potenzieren sich, statt sich auszugleichen
Team vs. Einzelperson	Teambasiert - reduziert individuelle Verzerrung	Oft individuell - die Einschätzung einer Person
Umgang mit Unsicherheit	Gut - grobe Skala absorbiert Unbekannte	Schlecht - Druck für falsche Präzision
Lernkurve	Moderat - erfordert 4-6 Sprints zur Kalibrierung	Niedrig - jeder versteht Stunden
Wartung	Erfordert Referenz-Stories und Kalibrierung	Erfordert Neubewertung bei Umfangsänderungen
Teamübergreifender Vergleich	Nicht möglich (teamspezifische Einheiten)	Möglich, aber irreführend (unterschiedliche Leistungsfähigkeit)
Stakeholder-Kommunikation	Erfordert Übersetzung in Termine mittels Velocity	Direkt, aber oft ungenau

Wann relative vs. absolute Schätzung verwenden

Verwenden Sie relative Schätzung, wenn:

• Sie Sprint- oder Release-Prognosen benötigen
• Das Team Arbeit im Product Backlog während der Verfeinerung dimensioniert
• Arbeitspakete erheblich in der Größe variieren
• Sie Risiken und Missverständnisse durch Teamdiskussion aufdecken wollen
• Sie aggregierte Genauigkeit über viele Elemente hinweg brauchen

Verwenden Sie absolute Schätzung, wenn:

• Sie eine Story in Umsetzungsaufgaben während des Sprint Planning zerlegen
• Die Arbeit hochgradig vertraut und vorhersehbar ist (z.B. „dieses Migrationsskript dauert 2 Stunden")
• Vertragliche Pflichten zeitbasierte Schätzungen erfordern
• Sie aufgewendete Zeit für Abrechnung oder Compliance-Zwecke erfassen
• Individuelle Aufgabenzuweisungen Zeitgrenzen benötigen

Viele Teams nutzen beides: Relative Schätzung für die Story-Ebene (Story Points für Sprint-Planung und Prognosen) und absolute Schätzung für die Aufgabenebene (Stunden für die individuelle Arbeitsorganisation innerhalb eines Sprints).

Branchenbeispiele

SaaS-Produktentwicklung

Ein SaaS-Team mit 7 Entwicklern verwendet Story Points auf einer Fibonacci-Skala mit Planning Poker für die Sprint-Verfeinerung. Ihre Referenz-Stories: 1-Punkt-Konfigurationsänderungen, 3-Punkt-Feature-Anpassungen, 5-Punkt-neue Features mit API-Integration, 8-Punkt-Integrationen mit Drittanbieterdiensten. Sie führen 2-Wochen-Sprints mit stabiler Velocity von 34 Punkten durch, was ihnen ermöglicht, vierteljährliche Releases mit einer Genauigkeit von 1 Sprint zu prognostizieren.

Gesundheitswesen-Software

Ein Gesundheitswesen-Team, das EHR-Integrationssoftware entwickelt, berücksichtigt regulatorische Compliance in seinen relativen Schätzungen. Stories mit PHI (Protected Health Information) werden automatisch 1-2 Fibonacci-Stufen höher bewertet als gleichwertige Nicht-PHI-Stories, wegen erforderlicher HIPAA-Dokumentation, Audit-Protokollierung, Verschlüsselungsverifizierung und Sicherheitsprüfung. Ihre Velocity (22 Punkte pro Sprint) ist niedriger als bei nicht-regulierten Teams, aber die Prognosen sind genau, weil der Compliance-Aufwand in den relativen Größen eingebettet ist.

Finanzdienstleistungen

Ein Fintech-Team, das Zahlungsverarbeitungsfunktionen schätzt, verwendet T-Shirt-Größen für erste Roadmap-Diskussionen mit Stakeholdern (S/M/L entspricht 1-Monat/1-Quartal/Mehrquartal-Lieferung) und konvertiert für die Sprint-Arbeit in Story Points. PCI-DSS-Compliance-Anforderungen sind in ihren Referenz-Stories erfasst - ein „5-Punkte-Zahlungsfeature" beinhaltet automatisch die Compliance-Tests, die das Team als Begleiterscheinung jeder zahlungsbezogenen Änderung kennt.

E-Commerce-Plattform

Ein E-Commerce-Team verfolgt relative Schätzungen über drei Arbeitstypen: kundenorientierte Features, Performance-Optimierung und Infrastruktur. Sie pflegen separate Referenzkataloge für jeden Typ, weil sich die Profile von Aufwand/Komplexität/Unsicherheit deutlich unterscheiden. Ein 5-Punkte-Kundenfeature umfasst UI-Arbeit und API-Integration, während eine 5-Punkte-Infrastrukturänderung Terraform-Module und Monitoring-Setup umfasst. Separate Kataloge verhindern typübergreifende Schätzungsdrift.

Regierungssoftware

Ein Team eines Regierungsauftragnehmers nutzt relative Schätzung innerhalb der Einschränkungen von Festpreisverträgen. Sie schätzen das initiale Backlog mittels Affinitätsschätzung, um eine Gesamtzahl an Story Points zu erhalten, teilen durch die prognostizierte Velocity, um die Anzahl der Sprints zu schätzen, und präsentieren die Sprint-Anzahl (mit Konfidenzbereich) dem Auftraggeber. Intern verfolgen sie die Velocity und nutzen sie für Sprint Planning. Die relativen Schätzungen ermöglichen es ihnen, innerhalb des festen Budgets umzupriorisieren und den Umfang anzupassen, ohne in Stunden neu zu schätzen.

EdTech-Plattform

Ein EdTech-Team, das ein Lernmanagementsystem entwickelt, nutzt relative Schätzung mit einer Besonderheit: Sie dimensionieren Barrierefreiheitsarbeit separat. Jedes Feature erhält zwei Schätzungen - Basisfunktionalität und Barrierefreiheits-Compliance (WCAG 2.1 AA). Ein Feature könnte 5 Punkte für die Basisfunktionalität und 3 Punkte für Barrierefreiheit haben, was insgesamt 8 Punkte ergibt. Diese Sichtbarkeit hilft dem Product Owner, die Kosten der Barrierefreiheits-Compliance zu verstehen und entsprechend zu planen, anstatt sie als unsichtbaren Overhead zu behandeln.

Reifegradmodell der relativen Schätzung

Stufe 1: Einstieg (Sprints 1-4)

Merkmale:

• Team ist neu bei der relativen Schätzung oder wechselt von Stunden
• Schätzungen fühlen sich willkürlich an - „Ist das eine 3 oder eine 5? Keine Ahnung"
• Noch keine Velocity-Daten vorhanden
• Referenz-Stories werden gerade aufgebaut
• Schätzsitzungen dauern lange (30+ Minuten für 5-10 Elemente)

Worauf Sie sich konzentrieren sollten:

• Wählen Sie 3-5 Referenz-Stories und zeigen Sie sie bei jeder Sitzung physisch an
• Machen Sie sich keine Sorgen um Genauigkeit - konzentrieren Sie sich auf Konsistenz (immer gegen die gleichen Referenzen vergleichen)
• Verfolgen Sie die Velocity, verlassen Sie sich aber noch nicht für die Planung darauf
• Verwenden Sie T-Shirt-Größen, wenn Story Points anfangs zu abstrakt wirken

Erwartetes Ergebnis: Bis Sprint 4 sollte das Team schneller bei Schätzungen konvergieren und sich mit der relativen Skala wohlfühlen.

Stufe 2: Kalibrierung (Sprints 5-10)

Merkmale:

• Velocity-Daten existieren, sind aber verrauscht (hohe Varianz zwischen Sprints)
• Team einigt sich schneller auf Schätzungen - die meisten Elemente konvergieren in 1-2 Runden
• Manche Stories überraschen noch (größer oder kleiner als geschätzt)
• Referenzkatalog wird auf Basis tatsächlicher Abschlussdaten verfeinert
• Schätzsitzungen dauern 15-20 Minuten für 5-10 Elemente

Worauf Sie sich konzentrieren sollten:

• Vergleichen Sie Schätzungen mit tatsächlichen Ergebnissen in jeder Retrospektive
• Identifizieren Sie systematische Muster: „Wir unterschätzen immer Stories, die [X] erfordern"
• Beginnen Sie mit der Nutzung der Velocity für Sprint-Kapazitätsplanung (mit Puffer)
• Aktualisieren Sie Referenz-Stories basierend auf dem, was Sie gelernt haben

Erwartetes Ergebnis: Bis Sprint 10 sollte die Velocity-Varianz sinken und die Sprint-Abschlussraten sich verbessern.

Stufe 3: Zuverlässig (Sprints 11-20)

Merkmale:

• Velocity ist innerhalb einer 15-20%-Spanne vorhersagbar
• Schätzsitzungen sind effizient - 10-15 Minuten für 5-10 Elemente
• Übertrag ist selten (weniger als 1 Story pro Sprint)
• Team hat ein intuitives Gespür für relative Dimensionierung
• Referenzkatalog ist stabil und wird vierteljährlich aktualisiert

Worauf Sie sich konzentrieren sollten:

• Verwenden Sie Velocity-Spannen (beste/durchschnittliche/schlechteste) für die Release-Prognose
• Neue Teammitglieder anhand des Referenzkatalogs einarbeiten
• Ihren Aufteile-Schwellenwert basierend auf Abschlussmustern verfeinern
• Durchsatz neben der Velocity zur Gegenprüfung verfolgen

Erwartetes Ergebnis: Zuverlässige Release-Terminprognosen mit einer Genauigkeit von 1-2 Sprints.

Stufe 4: Optimiert (Sprint 20+)

Merkmale:

• Velocity-Variationskoeffizient liegt unter 15%
• Schätzung benötigt minimale Zeit - Team stimmt oft ohne Diskussion überein
• Prognosen sind auf 10-15% genau
• Das Team beginnt möglicherweise zu hinterfragen, ob formelle Schätzung noch genug Mehrwert bietet
• Referenz-Stories werden selten benötigt - die Skala ist verinnerlicht

Worauf Sie sich konzentrieren sollten:

• Leichtgewichtige Alternativen in Betracht ziehen: schneller Konsens ohne Planning Poker Karten
• Evaluieren, ob Durchsatz-basierte Prognosen (Story-Anzahl statt Punkte) für Ihr Team funktionieren
• Schätzzeit nur auf Stories mit hoher Unsicherheit oder hohem Risiko konzentrieren
• Monte-Carlo-Simulation für probabilistische Release-Planung verwenden

Erwartetes Ergebnis: Schätzung wird zu einer leichtgewichtigen Praxis mit niedrigem Overhead, die zuverlässig die Planung unterstützt.

10 häufige Fehler bei der relativen Schätzung

Fehler Nr. 1: Relative Schätzungen in Stunden umrechnen

Was passiert: Das Management oder das Team legt eine Umrechnung fest: „1 Story Point = 4 Stunden." Eine 5-Punkte-Story wird erwartet, 20 Stunden zu dauern.

Warum es schädlich ist: Dies zerstört den gesamten Zweck der relativen Schätzung. Punkte werden zu einer Zeiteinheit, was Personenabhängigkeit, falsche Präzision und Zeitdruck zurückbringt. Wenn Sie ohnehin in Stunden umrechnen, können Sie gleich in Stunden schätzen.

Lösung: Definieren oder erlauben Sie niemals eine Punkt-zu-Stunden-Umrechnung. Verwenden Sie Velocity für zeitbasierte Planung: „Unsere durchschnittliche Velocity beträgt 28 Punkte pro Sprint. Das verbleibende Backlog umfasst 84 Punkte. Das sind etwa 3 Sprints."

Fehler Nr. 2: Ohne Referenz-Stories schätzen

Was passiert: Jede Schätzsitzung beginnt von Null ohne gemeinsamen Anker. Teammitglieder schätzen basierend auf ihren eigenen privaten mentalen Modellen.

Warum es schädlich ist: Ohne Referenz-Stories driften Schätzungen im Laufe der Zeit. Was vor drei Monaten eine 5 war, ist jetzt eine 3, wodurch Velocity-Trends bedeutungslos werden. Teammitglieder divergieren auch stärker, weil sie sich auf unterschiedliche persönliche Baselines verankern.

Lösung: Pflegen Sie einen Katalog von 5-7 Referenz-Stories an wichtigen Skalenwerten. Zeigen Sie sie bei jeder Schätzsitzung an. Überprüfen und aktualisieren Sie den Katalog vierteljährlich.

Fehler Nr. 3: Eine Person dominiert die Schätzungen

Was passiert: Der Senior Developer oder Tech Lead spricht zuerst, und alle anderen passen ihre Schätzung an. Oder der Product Owner schlägt eine Größe vor, bevor das Team schätzt.

Warum es schädlich ist: Dies führt zu Ankerverzerrung - die zuerst genannte Zahl wird zum Gravitationszentrum. Es bringt auch Junior-Teammitglieder zum Schweigen, die wertvolle Perspektiven zu Testkomplexität oder Unsicherheit haben könnten.

Lösung: Verwenden Sie gleichzeitiges Aufdecken (Planning Poker) für jede Schätzung. Niemand spricht seine Schätzung vor dem Aufdecken aus. Der Product Owner stellt die Story vor und beantwortet Fragen, schlägt aber niemals eine Größe vor.

Fehler Nr. 4: Zu lange an einer einzelnen Schätzung hängen

Was passiert: Das Team debattiert 15-20 Minuten darüber, ob eine Story eine 5 oder eine 8 ist und dreht sich dabei oft im Kreis.

Warum es schädlich ist: Der Präzisionsunterschied zwischen benachbarten Fibonacci-Werten ist über einen Sprint hinweg winzig. 15 Minuten Debatte zu führen spart keinerlei Prognosegenauigkeit. Es entzieht auch Energie, die für das Aufdecken von Risiken und Missverständnissen verwendet werden sollte.

Lösung: Setzen Sie ein Zeitlimit von 3-5 Minuten pro Element. Wenn das Team nach zwei Runden nicht konvergieren kann, nehmen Sie die höhere Schätzung und machen weiter. Wenn die Debatte offenbart, dass die Story schlecht verstanden wird, senden Sie sie zur Verfeinerung zurück, anstatt weiter zu schätzen.

Fehler Nr. 5: Schätzungen zwischen Teams vergleichen

Was passiert: Das Management bemerkt, dass Team A 40 Punkte pro Sprint abschließt und Team B 25, und folgert, dass Team B unterdurchschnittlich leistet.

Warum es schädlich ist: Story Points sind teamspezifisch. Team As „5 Punkte" und Team Bs „5 Punkte" repräsentieren unterschiedliche Arbeitsmengen - sie haben sich an verschiedenen Referenz-Stories mit unterschiedlichen Teamzusammensetzungen kalibriert. Sie zu vergleichen ist, als würde man Testergebnisse aus verschiedenen Prüfungen vergleichen.

Lösung: Wenn teamübergreifende Vergleiche nötig sind, verwenden Sie objektive Messgrößen: Durchsatz (abgeschlossene Stories pro Sprint), Durchlaufzeit (Tage von Start bis Abschluss) oder gelieferten Geschäftswert. Vergleichen Sie niemals rohe Story Point Velocity.

Fehler Nr. 6: Relative Schätzung für individuelle Leistung nutzen

Was passiert: Individuelle „Velocity" wird verfolgt: „Sarah hat 18 Punkte abgeschlossen, Carlos hat 12 abgeschlossen."

Warum es schädlich ist: Es erzeugt Fehlanreize. Entwickler blasen Schätzungen auf, um produktiver zu wirken. Zusammenarbeit nimmt ab, weil einem Teammitglied zu helfen den persönlichen Score nicht erhöht. Pair Programming und Mentoring werden zu „Velocity-Bremsern". Das Teamvertrauen erodiert.

Lösung: Relative Schätzung liefert ausschließlich Daten auf Teamebene. Individuelle Leistung sollte durch qualitative Maßnahmen bewertet werden: Code-Review-Qualität, Wissensaustausch, Mentoring und Beitrag zu Teamergebnissen.

Fehler Nr. 7: Kalibrierung überspringen

Was passiert: Das Team schätzt jeden Sprint, überprüft aber nie, ob seine Schätzungen genau waren. Es aktualisiert nie Referenz-Stories und identifiziert keine systematischen Verzerrungen.

Warum es schädlich ist: Ohne Kalibrierung stagniert oder verschlechtert sich die Schätzgenauigkeit. Das Team verpasst Lernmöglichkeiten. Velocity-Daten werden für Prognosen unzuverlässig, weil die Beziehung zwischen Punkten und tatsächlicher Arbeit driftet.

Lösung: Verbringen Sie in jeder Sprint Retrospective 5 Minuten mit der Überprüfung der Schätzgenauigkeit. Identifizieren Sie die größte Überraschung (am meisten über- oder unterschätzte Story), diskutieren Sie warum und aktualisieren Sie Referenz-Stories oder Schätzpraktiken entsprechend.

Fehler Nr. 8: Alles schätzen

Was passiert: Das Team schätzt jede Art von Arbeit: Features, Bugs, technische Schulden, Spikes, Dokumentation und Meetings. Alles bekommt Story Points.

Warum es schädlich ist: Bugs und Spikes sind von Natur aus unvorhersehbar - ihre „Größe" ist unbekannt, bis man die Arbeit beginnt. Sie zu schätzen erzeugt falsche Präzision und verunreinigt die Velocity-Daten. Wenn Bug-Punkte zur Velocity zählen, werden Teams dazu angeregt, mehr Bugs zu erzeugen.

Lösung: Schätzen Sie Stories (Features mit definierten Akzeptanzkriterien). Verfolgen Sie Bugs nach Anzahl, nicht nach Punkten. Begrenzen Sie Spikes zeitlich (z.B. „2 Tage Recherche") anstatt sie zu schätzen. Reservieren Sie einen Kapazitätspuffer für nicht-schätzbare Arbeit.

Fehler Nr. 9: Die falsche Skala verwenden

Was passiert: Ein Team verwendet eine lineare Skala (1, 2, 3, 4, 5, 6, 7, 8, 9, 10), die Debatten über den Unterschied zwischen 6 und 7 ermöglicht.

Warum es schädlich ist: Lineare Skalen fördern falsche Präzision. Der Unterschied zwischen einer 6 und einer 7 ist für die meisten Stories nicht sinnvoll unterscheidbar, aber die Existenz der Skala lädt zur Debatte ein. Zeit wird mit Präzision verschwendet, die die Prognose nicht verbessert.

Lösung: Verwenden Sie Fibonacci (1, 2, 3, 5, 8, 13, 21) oder eine ähnlich nichtlineare Skala. Die wachsenden Abstände zwingen Schätzer dazu, bedeutsame, erkennbare Unterscheidungen zu treffen, während sie bedeutungslose Präzision bei größeren Werten verhindern.

Fehler Nr. 10: Relative Schätzung zu früh aufgeben

Was passiert: Nach 3-4 Sprints mit verrauschten Velocity-Daten erklärt das Team oder das Management „Story Points funktionieren nicht" und wechselt zurück zu Stunden.

Warum es schädlich ist: Relative Schätzung braucht 4-6 Sprints der Kalibrierung, um zuverlässige Velocity-Daten zu liefern. Sie nach 3 Sprints zu beurteilen ist, wie eine Diät nach 3 Tagen zu beurteilen. Das frühe Rauschen ist der Kalibrierungsprozess bei der Arbeit - das Team lernt, konsistent zu schätzen.

Lösung: Verpflichten Sie sich zu mindestens 8 Sprints, bevor Sie bewerten, ob relative Schätzung für Ihr Team funktioniert. Verfolgen Sie die Velocity-Varianz über die Zeit - sie sollte abnehmen. Wenn sie nach 8 Sprints nicht abnimmt, untersuchen Sie die Grundursachen (Team-Instabilität, Umfangsänderungen, mangelhafte Verfeinerung), anstatt den Schätzansatz zu beschuldigen.

Relative Schätzung über Teams hinweg skalieren

Wenn mehrere Teams am gleichen Produkt arbeiten, braucht relative Schätzung Koordination:

Gemeinsame Referenz-Stories: Wenn Teams Schätzungen vergleichen oder aggregieren müssen (z.B. für PI-Planung), etablieren Sie 3-5 gemeinsame Referenz-Stories, gegen die alle Teams kalibrieren. Dies erzeugt „normalisierte" Story Points, die über Teams hinweg grob vergleichbar sind.

Unabhängige Velocity: Auch mit gemeinsamen Referenz-Stories pflegt jedes Team seine eigene Velocity. Eine 5-Punkte-Story kann Team A einen Tag und Team B drei Tage kosten - das ist in Ordnung, weil die Velocity jedes Teams sein spezifisches Tempo widerspiegelt.

Portfolio-Level-Schätzung: Für Roadmap- und Portfolio-Planung verwenden Sie T-Shirt-Größen oder Affinitätsschätzung statt Story Points. Diese Techniken sind schneller und erfordern keine teamübergreifende Punkt-Normalisierung.

Feature-Level-Aggregation: Wenn ein Feature über mehrere Teams geht, schätzt jedes Team seinen Anteil unabhängig mit seiner eigenen Skala. Die Gesamtschätzung ist die Summe der Team-Level-Schätzungen, umgerechnet in Sprints mittels der Velocity jedes Teams. Addieren Sie keine rohen Punkte über Teams - addieren Sie prognostizierte Sprint-Anzahlen.

Koordinationszeremonien: Während der PI-Planung oder Big-Room-Planung verwenden Sie Affinitätsschätzung, um eine gemeinsame Sicht auf relative Feature-Größen zu erstellen. Dann zerlegt jedes Team seinen Anteil in Stories und schätzt mit seiner eigenen Story-Point-Skala während der Sprint-Level-Planung.

Fazit

Relative Schätzung funktioniert, weil sie sich mit der Funktionsweise menschlicher Kognition deckt. Wir sind darauf programmiert zu vergleichen, nicht vorherzusagen. Wir nehmen proportionale Unterschiede wahr, keine absoluten. Wir treffen schnellere und genauere Urteile, wenn wir konkrete Referenzpunkte haben.

Kernaussagen:

1. Relative Schätzung bewertet Arbeit durch Vergleich („Ist das größer oder kleiner als X?") statt durch Vorhersage („Wie viele Stunden wird das dauern?")
2. Das Weber-Fechner-Gesetz erklärt, warum Fibonacci-Skalen funktionieren - unser Gehirn nimmt proportionale Unterschiede wahr, und die wachsenden Abstände der Skala spiegeln das wider
3. Referenz-Stories sind das Fundament - ohne sie driften Schätzungen und die Velocity wird bedeutungslos
4. Story Points, T-Shirt-Größen, Affinitätsschätzung und Planning Poker sind alles Techniken der relativen Schätzung - wählen Sie basierend auf Ihrer Situation
5. Relative und absolute Schätzung können koexistieren: Story Points für Sprint-Planung, Stunden für Aufgabenzerlegung
6. Rechnen Sie Story Points niemals in Stunden um, vergleichen Sie niemals Velocity zwischen Teams und nutzen Sie relative Schätzungen niemals für individuelle Leistungsbewertung
7. Kalibrierung ist unverzichtbar - überprüfen Sie die Schätzgenauigkeit in jeder Retrospektive und aktualisieren Sie Referenz-Stories vierteljährlich
8. Relative Schätzung braucht 4-6 Sprints Übung, um zuverlässige Velocity-Daten zu liefern - geben Sie sie nicht vorschnell auf

Häufig gestellte Fragen (FAQs)