T-Shirt-Sizing: Agile Schätzung einfach erklärt

Fragen Sie ein Team, was eine T-Shirt-Größe eigentlich bedeutet, und früher oder später versucht jemand, damit zu rechnen. „Wir haben im letzten Sprint zwei Smalls und ein Medium geliefert, also sollten wir im nächsten ein Large schaffen.“ Der Satz klingt vernünftig. Er ist auch Unsinn, und zu verstehen, warum, ist der schnellste Weg zu begreifen, wofür T-Shirt-Sizing eigentlich gedacht ist.

T-Shirt-Sizing ordnet Arbeit auf einer ordinalen Skala ein: XS, S, M, L, XL und manchmal XXL. Ordinal heißt, die Bezeichnungen haben eine Reihenfolge (ein XL ist größer als ein L), aber keinen Abstand, den man addieren, subtrahieren oder mitteln könnte. Zwei Mediums sind kein Large. Ein Team, das die Bezeichnungen wie Zahlen behandelt, verliert die einzige Eigenschaft, die die Technik überhaupt ehrlich macht: Sie behauptet nie mehr Genauigkeit, als das Team tatsächlich besitzt.

Key Facts

• Der Scrum Guide schreibt bewusst keine Schätzeinheit vor. Er sagt lediglich, dass „die Entwickler, die die Arbeit leisten werden, für die Größenbestimmung verantwortlich sind“, und überlässt es dem Team, ob Story Points, Stunden oder T-Shirt-Größen zum Einsatz kommen.
• Mike Cohns zentrale Kritik an T-Shirt-Größen ist, dass sie nicht additiv sind: „Sie können Ihrem Chef nicht sagen, dass Sie in 3 Mediums, 4 Larges und 2 Petites fertig sind“ (Mountain Goat Software).
• Um ein großes, bislang ungeschätztes Backlog schnell einzuordnen, empfiehlt Scrum.org stilles Affinity Grouping: „Affinity Mapping in Stille liefert ziemlich schnell gut genug Ergebnisse.“
• Nicht alle halten Schätzen für die Meetingzeit wert. Die Denkrichtung #NoEstimates, die mit Woody Zuill verbunden wird, fragt: „Woher wissen wir, dass Schätzungen helfen?“, statt eine bessere Zahl anzubieten.

Was T-Shirt-Sizing ist und warum „ordinal“ wichtig ist

T-Shirt-Sizing ist eine relative Schätztechnik. Statt zu fragen „Wie viele Stunden braucht das?“, fragt das Team: „Liegt das eher bei einem Small oder einem Large, verglichen mit Arbeit, die wir bereits eingeordnet haben?“ Das Ergebnis ist ein Label aus einem kleinen, festen Set: Extra Small, Small, Medium, Large, Extra Large und gelegentlich Extra Extra Large für den seltenen Eintrag, der größer ist als alles andere auf der Liste.

Das wichtigste Wort in dieser Beschreibung ist „ordinal“. Eine ordinale Skala sagt Ihnen die Reihenfolge der Dinge, ohne den Abstand dazwischen zu nennen, so wie ein Rennergebnis verrät, wer wen geschlagen hat, aber nicht mit welchem Vorsprung. Sie wissen, dass ein XL größer ist als ein Medium. Sie wissen nicht, dass es genau viermal so groß oder doppelt so unsicher ist, denn die Skala wurde nie dafür gebaut, diese Art von Arithmetik zu tragen.

Das ist ein Merkmal, keine Einschränkung. Fast jedes Fehlerbild dieser Technik geht darauf zurück, dass ein Team trotzdem mit den Labels rechnet: Größen zu einer Velocity-Zahl mittelt, eine Größe in ein Lieferdatum umrechnet oder das Large eines Teams mit dem Large eines anderen Teams vergleicht, als bedeute das Wort in beiden Räumen dasselbe. Behalten Sie die ordinale Eigenschaft im Blick, und die Technik bleibt nützlich. Verlieren Sie sie, wird sie unbemerkt zu einer schlechteren Version von Story Points.

Die Grobheit ist noch aus einem zweiten Grund gewollt: Sie entschärft die Scheingenauigkeit, die sich in stundenbasierte Schätzungen einschleicht. Wenn jemand sagt, eine Aufgabe dauere „12 Stunden“, trägt diese Zahl eine unverdiente Autorität, obwohl sie meist „wenn nichts schiefgeht und mich niemand unterbricht“ bedeutet. Ein Medium erhebt diesen Anspruch auf Sicherheit nicht, und es lässt sich auch außerhalb des Teams besser vermitteln: Ein VP oder ein Kunde, der nie in einem Sprint Planning gesessen hat, versteht sofort, dass Small kleiner ist als Large, ohne dass jemand erklären muss, was eine 5 auf einer Fibonacci-Skala bedeutet.

So führen Sie eine T-Shirt-Sizing-Session durch

Eine T-Shirt-Sizing-Session funktioniert am besten, wenn sie zügig läuft und der Versuchung widersteht, jeden Eintrag auszudiskutieren. Die folgenden Schritte gelten, egal ob Sie fünf Roadmap-Einträge oder fünfzig Backlog-Kandidaten in einer Sitzung einordnen.

Dem Anker-Schritt gebührt die meiste Aufmerksamkeit, denn ihn überspringen Teams, wenn sie es eilig haben. Ohne ein gemeinsames Small, auf das man zeigen kann, wird „Ist das ein Small oder ein Medium?“ zu einer Debatte über Bauchgefühle. Mit einem wird es zu einem echten Vergleich, den ein Team tatsächlich beantworten kann: Ist das mehr oder weniger Arbeit als das, was wir bereits als Small vereinbart haben?

Stilles Sizing skaliert die Technik auf Backlogs, die sonst Stunden dauern würden. Jede Person (oder die ganze Gruppe gemeinsam) ordnet Einträge entlang eines Spektrums vom kleinsten zum größten ein, ohne die eigene Begründung laufend zu kommentieren. Die Empfehlung von Scrum.org zum Schätzen großer Backlogs stützt sich genau auf diesen Instinkt und beschreibt stilles, vergleichsbasiertes Gruppieren als Weg zu „gut genug Ergebnissen ziemlich schnell“, statt sich durch jeden Eintrag einzeln zu quälen. Beide Ansätze tauschen die Genauigkeit pro Eintrag gegen Tempo, und beide setzen voraus, dass das Team genug gemeinsamen Kontext hat, um Dinge per Vergleich einzuordnen, statt zu debattieren.

Der letzte Schritt, das Aufhören bei Konvergenz, ist der Ort, an dem die Disziplin tatsächlich liegt. Eine zehnminütige Auseinandersetzung über Medium oder Large liefert kaum zusätzliche Information, denn die Skala wurde nie dafür gebaut, diese Genauigkeit zu belohnen. Wenn sich ein Team nach einer Diskussionsrunde nicht einigen kann, ist das meist ein Zeichen, dass der Eintrag selbst unklar ist, nicht dass die Gruppe länger streiten muss.

Eine Tabelle mit Größendefinitionen

Die meisten Teams, die T-Shirt-Sizing einführen, profitieren davon, einmal aufzuschreiben, was jede Größe für sie bedeutet, und darauf zu verweisen, statt die Definition in jeder Session neu zu verhandeln.

Beachten Sie, dass die Spalte „Nächster Schritt“ echte Arbeit leistet: Eine Größe ist eine Routing-Entscheidung, nicht nur ein Label. Kleine Einträge sind fast bereit, Large- und Extra-Large-Einträge sind ein Signal, sie aufzuteilen, bevor jemand im Detail um sie herum plant. So bleibt T-Shirt-Sizing mit Handlung verbunden, statt für immer als Label in einer Tabellenspalte zu liegen.

T-Shirt-Größen in etwas Planbares überführen

Irgendwann will ein Stakeholder mehr als „Das ist ein Medium“. Er will eine grobe Vorstellung, wann etwas fertig sein könnte oder wie viel der Teamkapazität es bindet. Für diese Lücke gibt es zwei ehrliche Ansätze und einen unehrlichen, den man meiden sollte.

Der Hybrid mit Punktzuordnung. Viele Teams legen unter jede Größe eine grobe Zahl, vor allem damit die Zahlen und nicht die Labels die Arithmetik tragen. Planning Poker dokumentiert bereits eine gängige Variante: ein Hybrid-Deck mit XS=1, S=2, M=3, L=5, XL=8, das T-Shirt-Labels an einer modifizierten Fibonacci-Skala ausrichtet. Andere Teams nutzen eine andere Leiter, etwa Medium=5 und Large=10, die sich mit wachsender Größe verdoppelt. Beides funktioniert. Entscheidend ist, eine Zuordnung zu wählen und konsequent zu nutzen: Sie ist eine Bequemlichkeit, um über Größe zu sprechen, keine universelle Umrechnungstabelle zwischen Teams.

Der Ansatz mit Bereich pro Größe. Statt eine Größe einer einzelnen Zahl zuzuordnen, ordnen Sie ihr einen Bereich zu: Ein Small könnte „einen halben bis zwei Tage“ bedeuten, ein Medium „drei Tage bis eine Woche“, ein Large „ein bis drei Wochen“. So bleibt die Ehrlichkeit der ordinalen Skala erhalten, und Planer bekommen etwas, das sie für die grobe Terminplanung nutzen können.

Welchen Ansatz Sie auch wählen, die Warnung bleibt dieselbe: Ein Bereich ist keine Zusage. In dem Moment, in dem aus den „drei Tagen bis einer Woche“ eines Mediums ein versprochenes Lieferdatum auf einer kundenseitigen Roadmap wird, übernimmt die Schätzung eine Aufgabe, für die sie nie gebaut wurde. Bereiche kommunizieren Unsicherheit, Termine kommunizieren Sicherheit. Beides zu verwechseln macht aus einer groben, ehrlichen Schätzmethode eine Quelle gebrochener Versprechen, an deren Zustandekommen sich niemand erinnert.

T-Shirt-Sizing vs. Story Points vs. Planning Poker vs. Drei-Punkt-Schätzung vs. No Estimates

Keine dieser Techniken ist ein Konkurrent in dem Sinn, dass nur eine „richtig“ wäre. Jede passt zu einem anderen Horizont und einem anderen Maß an Gewissheit über die Arbeit.

Liest man die Spalte „Bester Horizont“ quer, ergibt sich dasselbe Muster, das Story Points bereits beschreibt: T-Shirt-Sizing gehört am weitesten weg von der Umsetzung, wo eine falsche Schätzung eine Priorisierungsentscheidung kostet und keine gebrochene Sprint-Zusage. Planning Poker und Story Points gehören am nächsten an die Umsetzung, wo das Team gerade reale Kapazität zusagt. Die Drei-Punkt-Schätzung gehört zu terminierter, abhängigkeitsreicher Arbeit, meist außerhalb eines reinen Scrum-Kontexts. Der No-Estimates-Ansatz gehört zu Teams, deren Backlog granular und stabil genug ist, dass die Historie besser vorhersagt als jedes Urteil über einen einzelnen Eintrag, weiter unten ausführlicher behandelt.

Sizing auf verschiedenen Flughöhen

T-Shirt-Sizing ist nicht eine Technik, die überall gleich eingesetzt wird. Was sich ändert, ist die Flughöhe: wie weit der Eintrag von dem Team entfernt ist, das ihn tatsächlich bauen wird.

Oben in dieser Tabelle leisten T-Shirt-Größen genau die Arbeit, für die sie gebaut sind. Die Hierarchie in Epics vs. Features vs. User Stories macht diesen Punkt bereits direkt: Epics werden in T-Shirt-Größen oder groben Sprint-Anzahlen geschätzt, und Story Points auf Epic-Ebene erzeugen Scheingenauigkeit. Ein Epic, das noch ein Absatz voller Absicht ist und kein Set definierter Stories, hat nicht das Detail, das Story Points brauchen, um etwas zu bedeuten.

Quartalsplanung und Intake liegen in ähnlichem Terrain. Das Ziel ist dort keine genaue Prognose, sondern ein ausreichend schnelles Signal, um zu entscheiden, was einen genaueren Blick verdient. Ein beim Intake markiertes Large sagt dem Product Owner: „Versprechen Sie das nicht vorschnell“, und das ist auch ohne Zahl eine wirklich nützliche Information.

Die unterste Zeile ist dort, wo am häufigsten etwas schiefgeht: Eine sprint-reife Story in T-Shirts zu schätzen ist meist ein Rückschritt, kein Fortschritt. Sobald eine Story ein oder zwei Sprints entfernt ist, beschreibt Story Points bereits die erwartete Verschiebung: T-Shirt-Größen in Punkte umrechnen, sobald ein Eintrag nah genug an der Bearbeitung ist. Das ist auch der Punkt, an dem das Team genug Klarheit haben sollte, um die Arbeit in etwas zu zerlegen, das näher an einem Projektstrukturplan liegt, oder, für die Nachverfolgung auf Umsetzungsebene, in ein einzelnes Arbeitspaket mit echten Positionen. T-Shirt-Größen existieren für die Zeit, in der diese Zerlegung noch fehlt; sobald sie da ist, wirft die Rückkehr zu einem groben Label Information weg, die sich das Team bereits erarbeitet hat.

Jenseits der Softwareentwicklung

T-Shirt-Sizing hat nichts Code-Spezifisches. Es ist eine Vergleichstechnik, und jedes Team, das zwischen mehr Arbeit wählen muss, als Zeit da ist, kann sie nutzen.

Marketing. Ein Kampagnen-Backlog voller Einträge wie „Hero-Bereich der Startseite überarbeiten“, „Paid-Social-Test starten“ und „Lead-Scoring-Modell neu aufbauen“ lässt sich allein über Stunden unmöglich vergleichen, denn die Stunde eines Designers und die eines Datenanalysten sind nicht austauschbar. Mit T-Shirt-Größen kann ein Marketing Lead die Kampagnenideen eines Quartals nach grobem Aufwand ordnen, ohne eine Genauigkeit vorzugeben, die das Team nicht hat.

Operations. Ops-Anfragen (ein neues Vendor-Onboarding, eine Richtlinienänderung, eine Tool-Migration) unterscheiden sich stark im Umfang und lassen sich selten sauber auf eine einzelne Arbeitseinheit abbilden. Eine große Ops-Anfrage signalisiert „das braucht einen eigenen Projektplan“, während eine kleine vermutlich innerhalb der bestehenden Arbeitslast einer Person erledigt werden kann.

Professional Services. Das Scoping eines Kundenprojekts beginnt oft mit T-Shirt-Größen für einzelne Module, noch bevor ein detailliertes Statement of Work existiert. „Discovery ist ein Small, Migration ein Large, Training ein Medium“ gibt einem Angebotsteam eine grobe Form, an der es die Preisgestaltung ausrichten kann, bevor es sich auf exakte Stunden festlegt.

Recruiting-Pipelines. Recruiting-Teams ordnen offene Stellen manchmal auf diese Weise ein: Eine kleine Stelle hat einen tiefen, verfügbaren Talentpool und eine klare Stellenbeschreibung; eine große Stelle ist ein ganz neuer Titel mit dünnem Markt und unklarer interner Definition von Erfolg. Die Einordnung hilft dem Recruiting-Team zu entscheiden, wo es den größten Suchaufwand zuerst einsetzt.

Hier ein durchgerechnetes Beispiel eines Marketing-Teams, das ein Produkt-Launch-Quartal plant, mit genau den Größendefinitionen aus der Tabelle oben.

Beim Lesen dieser Liste braucht der Marketing Lead keine Story-Point-Velocity, um das offensichtliche Sequenzierungsrisiko zu erkennen: Das Rebranding und der Neuaufbau des Lead-Scorings sind die beiden Einträge, die am frühesten starten und am schnellsten aufgebrochen werden müssen, weil alles andere auf der Liste davon abhängt zu wissen, wie viel vom Quartal sie ungefähr verbrauchen werden.

Fehlerbilder

Die meisten Fehler beim T-Shirt-Sizing gehen auf eine Ursache zurück: Jemand rechnet mit einem ordinalen Label. Die konkreten Erscheinungsformen sind es wert, benannt zu werden, damit ein Team sie früh erkennt.

Das Fehlerbild des teamübergreifenden Vergleichs verdient einen zweiten Blick, weil es im Stillen den größten Schaden anrichtet. Zwei Teams, die melden „wir haben dieses Quartal drei Larges geliefert“, klingen vergleichbar. Das sind sie nicht, aus demselben Grund, aus dem ein 50-Punkte-Sprint eines Scrum Teams nicht heißt, dass es schneller ist als ein 30-Punkte-Sprint eines anderen: Beides sind intern kalibrierte Skalen ohne gemeinsame Einheit dahinter. In dem Moment, in dem eine Größe oder Punktesumme eine Teamgrenze überschreitet und als gleichwertig behandelt wird, hört sie auf nützlich zu sein und wird irreführend.

Die Grenzen relativer Schätzung

Es lohnt sich, bei etwas ehrlich zu sein, das die meisten Schätz-Inhalte glattbügeln: Es gibt sehr wenige belastbare, unabhängig verifizierte Daten dafür, dass eine relative Schätztechnik genauere Prognosen liefert als eine andere. Behauptungen, eine Methode mache Teams um einen festen Prozentsatz genauer, kursieren ständig, und die meisten lassen sich auf nichts Überprüfbares zurückführen. Die ehrliche Position lautet: T-Shirt-Sizing, Story Points und Planning Poker sind allesamt urteilsbasierte Techniken, deren Wert darin liegt, Annahmen sichtbar zu machen und Gespräche schnell zu halten, nicht in einem nachgewiesenen Genauigkeitsvorteil gegenüber den anderen.

Diese Ehrlichkeit öffnet die Tür zu einem echten Gegenargument, das ein faires Gehör verdient. Die Denkrichtung, die sich um den Hashtag #NoEstimates gesammelt hat und am stärksten mit Woody Zuill verbunden ist, stellt infrage, ob es die Meetingzeit überhaupt wert ist, eine Schätzung zu erzeugen. Die Agile Alliance, die Zuills Vortrag zum Thema hostet, beschreibt sein Argument als Reihe von Fragen und nicht als Ersatztechnik: „Woher wissen wir, dass Schätzungen helfen? Können wir beweisen, dass Schätzungen helfen?“ Die praktische Alternative ist die Prognose aus dem Throughput: Man verfolgt, wie viele kleine, ähnlich große Einträge ein Team in der jüngeren Vergangenheit tatsächlich abgeschlossen hat, und rechnet von dieser Rate aus nach vorn, statt die Größe der noch vor einem liegenden Arbeit zu beurteilen.

Dieser Ansatz funktioniert wirklich für Teams mit einem stetigen Strom kleiner, vergleichbar zugeschnittener Einträge und genug Historie, um der Throughput-Zahl zu trauen. Weniger gut funktioniert er, wenn ein Backlog in Größe und Art stark schwankt, denn die Throughput-Prognose setzt voraus, dass die jüngere Vergangenheit der nahen Zukunft ähnlich genug ist, um aussagekräftig zu sein. Die meisten Organisationen landen irgendwo dazwischen: Sie behalten eine leichtgewichtige Schätzgewohnheit wegen des Urteils, das sie erzwingt, nämlich des Gesprächs über den Umfang und nicht der Zahl, die sie erzeugt, und behandeln die resultierende Zahl mit angemessener Demut. T-Shirt-Sizing passt genau in diese Mitte, gerade weil man seiner Grobheit schwer zu sehr vertrauen kann.

Weiterführende Lektüre

• Story Points: So schätzen Sie agile Arbeit
• Planning Poker: So schätzen agile Teams den Aufwand
• Epics vs. Features vs. User Stories erklärt
• Drei-Punkt-Schätzung (PERT): Formel und Beispiele
• Velocity in Agile: So messen Sie den Team-Throughput
• Sprint Planning: So führen Sie ein wirksames Sprint-Planning-Meeting durch
• Product Backlog: Was es ist und wie Sie es managen
• Backlog Refinement
• Kapazitätsplanung
• Projektstrukturplan

T-Shirt-Sizing verdient sich seinen Platz im Schätz-Werkzeugkasten dadurch, dass es bewusst grob bleibt. In dem Moment, in dem ein Team XS bis XL wie verkleidete Zahlen behandelt, sei es durch Mitteln zu einer Velocity-Zahl, durch Vergleiche zwischen Teams oder durch das Zurücklesen eines Bereichs als versprochenes Datum, hört die Technik auf, die eine Aufgabe zu erfüllen, für die sie gebaut wurde. Halten Sie die Größen ordinal, halten Sie die Session schnell, und wechseln Sie erst dann zu etwas Genauerem, wenn die Arbeit nah genug dran ist, um es zu verdienen.