Agile T-Shirt Sizing: Aufwand gemeinsam schätzen in weniger als 90 Minuten

Das Team hat 30 Backlog-Einträge zu schätzen, ein 60-Minuten-Fenster, und eine Roadmap-Entscheidung hängt am Ergebnis. Warum diskutiert ihr dann noch, ob eine Story eine 5 oder eine 8 ist? Agile T-Shirt Sizing existiert genau für diese Situation: eine schnellere, erstaunlich präzise Methode, um gemeinsames Verständnis über Aufwand herzustellen, ohne die Zeremonie von Planning Poker.

Dieser Artikel erklärt, wie T-Shirt Sizing funktioniert, wie man eine Session Schritt für Schritt durchführt, wie man Größen auf Story Points mappt, und wann die Methode sinnvoller ist als Planning Poker oder Dot Voting.

Was ist Agile T-Shirt Sizing?

T-Shirt Sizing ist eine relative Schätztechnik, bei der Backlog-Einträge Größen erhalten (XS, S, M, L, XL, manchmal XXL) statt konkreter Stunden oder Tage. Das Ziel ist, Aufwand, Komplexität und Unsicherheit kollektiv einzuschätzen, nicht eine exakte Prognose zu produzieren.

Die kognitive Grundlage ist dieselbe wie bei allen relativen Schätzmethoden: Menschen vergleichen Dinge besser miteinander als sie absolute Werte isoliert beurteilen. Die Frage „Ist das ein Small oder ein Medium?" ist schneller und fehlerarmer als „Wie viele Stunden wird das dauern?" Das beschreibt Atlassian's Agile Coach als einen der Hauptgründe, warum relative Schätzung in agilen Teams Einzug gehalten hat.

Besonders verbreitet ist T-Shirt Sizing beim frühen Backlog-Grooming, bei der Roadmap-Planung und im SAFe-Kontext beim PI Planning, wo Epics und große Features schnell eine Grobgröße brauchen, bevor sie vollständig aufgebrochen werden.

Ein konkretes Beispiel aus der Praxis: Ein Produktteam eines mittelgroßen SaaS-Unternehmens setzt T-Shirt Sizing bei quartalsweisen Roadmap-Reviews ein. Jedes Feature wird der Gruppe gezeigt, Engineers schreiben ihre Größe auf einen Haftzettel, alle zeigen gleichzeitig, und Abweichungen werden besprochen. Das dauert rund zwei Minuten pro Item, verglichen mit acht bis zehn Minuten bei vollständigem Planning Poker. Das Ergebnis: ein ganzes Quartal an Features wird in einer einzigen 90-Minuten-Session geschätzt.

Eine Session in fünf Phasen durchführen

Eine gut geführte T-Shirt-Sizing-Session hat fünf klare Phasen.

Phase 1: Vorbereitung

Der Facilitator stellt sicher, dass alle Backlog-Einträge genug Kontext für eine sinnvolle Diskussion haben. Stories ohne Akzeptanzkriterien oder Beschreibung führen zu Schätzdebatten über unklare Anforderungen, nicht über echten Aufwand. Diese Items gehören nicht in die Session, sondern zurück zum Product Owner.

Phase 2: Ankerpunkte setzen

Das ist der am häufigsten übersprungene Schritt, und das ist ein Fehler. Ohne gemeinsamen Referenzpunkt bedeutet „Medium" für jede Person etwas anderes. Best Practice: Das Team einigt sich auf eine abgeschlossene Story, die jede Größe repräsentiert, und hält diese „Größenreferenz" während der Session sichtbar. Spotify-Engineering-Teams haben diesen Ansatz mit einem geteilten Confluence-Page-Referenzset beschrieben, damit neue Team-Mitglieder schnell kalibrieren können, was „Medium" im Teamkontext bedeutet.

Phase 3: Stille, simultane Schätzung

Jeder Teilnehmer schreibt seine Schätzung auf, niemand sieht die anderen Antworten, bevor alle fertig sind. Dann wird gleichzeitig aufgedeckt. Dieses Prinzip ist nicht verhandelbar. Wer zuerst spricht, beeinflusst alle anderen. Scrum.org benennt Anchoring Bias als einen der häufigsten Fehler bei Schätzsessions, und die simultane Enthüllung ist die direkte Gegenmaßnahme.

Bei Remote-Teams: In Tools wie Miro oder MURAL tippen alle ihre Schätzung in die Karte, aber niemand dreht sie um, bevor alle abgestimmt haben. Das muss der Facilitator aktiv einfordern.

Phase 4: Diskussion bei Ausreißern

Nicht jedes Item braucht eine Diskussion. Wenn acht von neun Personen „M" schreiben, ist das Konsens. Diskutiert wird nur, wenn die Spanne groß ist, zum Beispiel wenn jemand XS und jemand anderes L schreibt. Diese Diskrepanzen sind wertvoll: Sie zeigen, dass Teilnehmer unterschiedliche Annahmen über Scope oder technische Komplexität haben. Genau das will man aufdecken.

Phase 5: Konsens festhalten

Die vereinbarte Größe wird direkt im Backlog-Tool dokumentiert. Kein Post-it-Chaos, kein Protokoll, das drei Tage später niemand mehr findet.

T-Shirt-Größen auf Story Points mappen

Manche Teams belassen es bei den Größenbezeichnungen. Andere brauchen Story Points, weil ihr Tooling (Jira, Azure DevOps) Velocity in Punkten trackt. Eine häufig verwendete Zuordnung ist XS=1, S=2, M=3, L=5, XL=8, was der Fibonacci-Sequenz aus dem Planning Poker entspricht. Wer zwischen großen Items stärker differenzieren will, nutzt XS=1, S=2, M=5, L=8, XL=13.

Das Mapping ist eine Teamkonvention, keine universelle Wahrheit. Es muss stabil bleiben, mindestens ein Quartal lang. Ein Fintech-Produktteam hat bei Mountain Goat Software beschrieben, wie sie nach zwei Quartalen mit XS=1, S=2, M=3, L=5, XL=8 in Jira feststellten, dass XL-Stories deutlich unvorhersehbarer geliefert wurden als M-Stories. Das führte zu einer Teamregel: Jedes XL-Item muss vor dem Sprint-Eintrag aufgebrochen werden. T-Shirt Sizing wurde damit gleichzeitig zur Story-Splitting-Entscheidungshilfe.

Es gibt auch das Gegenargument: Scrum.org hält fest, dass das Konvertieren von T-Shirt-Größen zu Story Points den Vorteil der Methode teilweise zunichtemacht. Teams, die mit Flow-Metriken wie Cycle Time oder Throughput arbeiten, können T-Shirt Sizing als groben Priorisierungsfilter einsetzen, ohne je Punkte zu vergeben.

T-Shirt Sizing, Planning Poker und Dot Voting im Vergleich

Diese drei Techniken werden oft in einem Atemzug genannt, aber sie lösen unterschiedliche Probleme.

T-Shirt Sizing ist das richtige Werkzeug, wenn viele Items geschätzt werden müssen, die Zeit knapp ist, oder der Detailgrad noch niedrig ist (Epics, Themes, Features). Planning Poker eignet sich für Präzision und tiefere Diskussion: Die Fibonacci-Skala zwingt Teilnehmer, zwischen einer 5 und einer 8 zu unterscheiden, während „Medium vs. Large" weniger Granularität hat. ThoughtWorks beschreibt ein Zwei-Pass-System, das viele erfahrene Coaches empfehlen: T-Shirt Sizing für alles oberhalb des Sprint-Levels (Epics, Roadmap-Features, PI-Ziele), Planning Poker für User Stories im Sprint-Refinement.

Dot Voting ist keine Schätzmethode. Es ist eine Priorisierungsmethode, die Gruppen hilft, sich auf die wichtigsten Items zu einigen, nicht darauf, wie groß sie sind. Die beiden Techniken verwechseln bedeutet, Äpfel mit Orangen zu vergleichen.

Ein praxiserprobter Entscheidungsbaum: Hast du mehr als 20 Items zu schätzen und weniger als 90 Minuten? Nimm T-Shirt Sizing. Bist du im Sprint-Refinement mit vollständig beschriebenen Stories? Nimm Planning Poker. Musst du zwischen Optionen priorisieren, nicht schätzen? Nimm Dot Voting.

Typische Fehler und wie man sie vermeidet

Der häufigste Fehler ist Anchoring Bias durch verfrühtes Sprechen. Gelöst wird das durch die simultane Enthüllung, die nicht optional ist.

Ein zweiter systematischer Fehler ist „Size Creep": Über Monate hinweg inflatiert das Team unbewusst seine Größendefinitionen, bis was früher ein Medium war jetzt als Small gilt. Das korrumpiert Velocity-Daten und Roadmap-Planungen. Regelmäßige Rekalibrierungs-Sessions, monatlich oder quartalsweise, mit dem Referenz-Story-Set halten die Drift in Grenzen, wie Mountain Goat Software empfiehlt.

Ein dritter Fehler: Stakeholder behandeln T-Shirt-Größen als Zusagen. Das sind sie nicht. Sie sind Grobschätzungen mit breiten Unsicherheitsbändern. Als Facilitator ist es deine Aufgabe, diese Erwartung von Beginn an zu setzen, verbal und explizit.

Und dann gibt es noch das Timeboxing-Problem. Teams debattieren manchmal fünfzehn Minuten über ein einziges Item, das in zwei Minuten hätte entschieden werden können. Eine Lösung: striktes Drei-Minuten-Limit pro Item. Kein Konsens in drei Minuten? Größere Kategorie, Item zur Verfeinerung parken. Eine digitale Agentur berichtete, dass nach Einführung eines Drei-Minuten-Limits und einer dedizierten „Park it"-Spalte im Miro-Board ihre durchschnittliche Sizing-Session von zwei Stunden auf 45 Minuten schrumpfte, bei gleichzeitig höherer Zufriedenheit im Retro.

T-Shirt Sizing im Remote-Kontext

Remote-Sessions brauchen mehr explizite Struktur. Konkret: Ein sichtbares geteiltes Board für alle, ein striktes Enthüllungsprotokoll, und einen Timekeeper. Ohne diese drei Elemente driftet die Session in sequentielles Teilen, bei dem Teilnehmer die Antworten anderer hören, bevor sie ihre eigene Entscheidung treffen. Anchoring Bias kehrt durch die Hintertür zurück.

Für global verteilte Teams über Zeitzonen hinweg wächst asynchrones T-Shirt Sizing. Tools wie Parabol ermöglichen es, dass alle Beteiligten ihre Schätzung unabhängig eingeben, bevor ein kurzes 20-Minuten-Sync nur die Ausreißer diskutiert. Das reduziert den Synchronisationsaufwand gegenüber einer vollständigen Planning-Poker-Session erheblich.

Es gibt noch einen psychologischen Aspekt, der remote relevanter ist als im Präsenzkontext: Junior-Engineers oder neue Team-Mitglieder zögern eher, wenn sie eine Senior-Schätzung vor Augen haben. Blind simultane Enthüllung schützt Mindermeinungen strukturell. Das ist kein nettes Feature, sondern die Voraussetzung für valide Schätzergebnisse.

T-Shirt Sizing in das Backlog-Refinement integrieren

T-Shirt Sizing passt am besten in die frühe Phase des Backlog-Refinements, wenn Items auf Readiness geprüft werden, bevor sie für einen Sprint geplant werden. Viele Teams nutzen die Größe als Readiness-Gate: Items müssen XS, S oder M sein, bevor sie in Sprint Planning gezogen werden. L und XL wandern zurück zur Zerlegung.

Im SAFe-Kontext übernimmt T-Shirt Sizing die Schätzung von Features auf Programm-Ebene, bevor sie in Stories heruntergebrochen werden. Das gibt Release Train Engineers und Product Managern die Möglichkeit, Kapazitätsbedarf über PIs hinweg abzuschätzen, wie Scaled Agile beschreibt.

Atlassians eigene Engineering-Teams haben ein Refinement-Prozess beschrieben, bei dem Epics im monatlichen Program-Level-Refinement eine T-Shirt-Größe erhalten, die direkt in das quartalsweise Roadmap-Confidence-Scoring fließt. Das zeigt: T-Shirt Sizing ist kein Behelfswerkzeug für unklar definierte Teams, sondern ein bewusster Prozessschritt in reifen Delivery-Organisationen.

Workshop Weaver enthält fertige Sessionvorlagen für T-Shirt Sizing, inklusive Ankergeschichten, Timeboxing-Struktur und Remote-Konfiguration, damit man nicht jedes Mal das Setup von Grund auf neu erfindet.

Fazit: Die Größe ist nicht das Ziel

Der eigentliche Wert von T-Shirt Sizing liegt nicht in der Größenbezeichnung am Ende. Er liegt in der Diskussion, die entsteht, wenn zwei Personen „S" und „L" zeigen und herausfindet werden muss, warum.

Diese Gespräche decken unterschiedliche Annahmen auf, klären Scope, und bauen gemeinsames Verständnis auf, das sonst erst im Sprint verloren geht, wenn es teuer ist.

Ein konkreter Vorschlag: Nimm das nächste Backlog-Refinement und führe T-Shirt Sizing mit dem Fünf-Phasen-Prozess aus diesem Artikel durch. Bereite drei Anker-Stories vor, setze ein Drei-Minuten-Limit pro Item, und beobachte, wie sich die Diskussionsqualität verändert.

Wer danach die Schätzmethoden im Team weiter ausbauen will: Planning Poker eignet sich für die detailliertere Story-Ebene, Dot Voting für Priorisierungsentscheidungen. Beide Techniken ergänzen T-Shirt Sizing, sie ersetzen es nicht.

Welche Technik passt gerade am besten zu eurem Team-Kontext?