T-Shirt-Groessen in Agile: Kompletter Leitfaden zur relativen Schaetzung

T-Shirt-Groessen sind eine agile Schaetzungstechnik, die Kleidergroessen - XS, S, M, L, XL, XXL - anstelle von Zahlen verwendet, um den relativen Aufwand von Arbeitspaketen zu schaetzen. Es ist die schnellste Methode, um ein grosses Backlog zu bewerten, ohne sich in falscher Praezision zu verlieren, und es ist oft die erste Schaetzungstechnik, die neue Agile Teams erlernen.

Warum Kleidergroessen? Weil jeder sofort den Unterschied zwischen einem Small und einem Extra Large versteht. Sie muessen nicht erklaeren, was eine „5" auf einer Fibonacci-Skala bedeutet oder darueber diskutieren, ob etwas eine 6 oder eine 7 ist. Ein T-Shirt ist ein T-Shirt. Diese intuitive Einfachheit ist genau das, was diese Technik so effektiv macht fuer Sprint Planning, Roadmap-Planung und funktionsuebergreifende Gespraeche, in denen nicht jeder die Sprache der Story Points spricht.

Dieser Leitfaden behandelt, wann T-Shirt-Groessen eingesetzt werden sollten (und wann nicht), den schrittweisen Prozess, wie Groessen in numerische Werte umgerechnet werden, haeufige Fehler und wie sie sich im Vergleich zu Planning Poker und anderen Techniken verhalten.

Schnelluebersicht: T-Shirt-Groessen auf einen Blick

Aspekt	Details
Was es ist	Relative Schaetzung mit Kleidergroessen (XS, S, M, L, XL, XXL)
Am besten geeignet fuer	Roadmap-Planung, grosse Backlogs, neue Agile Teams, funktionsuebergreifende Gruppen
Geschwindigkeit	30-60 Sekunden pro Element (vs. 2-5 Min. fuer Planning Poker)
Genauigkeit	Mittel - gut fuer relativen Vergleich, nicht fuer praezise Kapazitaetsplanung
Wer teilnimmt	Entwickler und optional Stakeholder fuer Roadmap-Schaetzungen
Wann einsetzen	Fruehe Planungsphasen, wenn Details duenn und Richtung wichtiger als Termine ist
Typische Skala	XS, S, M, L, XL (manche Teams fuegen XXL oder XXS hinzu)
Hauptvorteil	Keine Lernkurve - jeder versteht T-Shirt-Groessen sofort

Was sind T-Shirt-Groessen?

T-Shirt-Groessen sind eine relative Schaetzungsmethode, bei der Teams Kleidergroessen - typischerweise XS, S, M, L, XL - Product Backlog-Elementen zuweisen, basierend auf deren relativer Komplexitaet, Aufwand und Unsicherheit. Anstatt zu fragen „Wie viele Story Points hat das?" fragt das Team „Ist das ein Small oder ein Large?"

Die Technik funktioniert, weil sie bewusst numerische Praezision vermeidet. Wenn jemand sagt „Das ist ein Medium", versucht niemand, Stunden oder Tage zu berechnen. Das Gespraech bleibt auf den relativen Vergleich fokussiert: „Ist das Erstellen der Passwort-Zuruecksetzungsfunktion groesser oder kleiner als die E-Mail-Benachrichtigungsfunktion, die wir bereits geschaetzt haben?"

Warum Kleidergroessen funktionieren

Drei psychologische Prinzipien machen T-Shirt-Groessen effektiv:

1. Universelles Verstaendnis Jeder hat schon ein T-Shirt getragen. Das Konzept von Small, Medium und Large erfordert keinerlei Erklaerung. Im Gegensatz dazu verbringen Teams bei Story Points ganze Sitzungen damit, „Was bedeutet eine 5?" zu diskutieren. T-Shirt-Groessen beseitigen diese Einarbeitungshuerde.

2. Natuerliche Kategorien Nur 5-6 Kategorien erzwingen schnelle Entscheidungen. Sie koennen nicht darueber gruebeln, ob etwas eine „6,5 vs. 7" ist - es ist entweder ein Medium oder ein Large. Diese Einschraenkung beschleunigt die Schaetzung erheblich.

3. Reduzierter Ankereffekt Worte tragen weniger numerischen Ballast als Zahlen. Wenn jemand „Large" sagt, faellt es anderen schwerer, sich an einen bestimmten numerischen Wert zu ankern, als wenn jemand „8 Punkte" sagt.

T-Shirt-Groessen vs. Story Points

Aspekt	T-Shirt-Groessen	Story Points (Fibonacci)
Lernkurve	Keine - sofortiges Verstaendnis	Mittel - braucht 3-5 Sprints zur Kalibrierung
Geschwindigkeit pro Element	30-60 Sekunden	2-5 Minuten
Praezision	Niedrig (5-6 Kategorien)	Mittel (10+ Werte)
Velocity-Tracking	Erfordert Umrechnung	Direktes Tracking
Am besten fuer	Roadmaps, grosse Backlogs, neue Teams	Sprint Planning, Kapazitaetsprognosen
Stakeholder-freundlich	Sehr - auch nicht-technische Personen verstehen es	Weniger - „Was ist eine 8?"
Numerische Prognosen	Nicht direkt	Ja - Velocity-basiert

Wichtige Erkenntnis: T-Shirt-Groessen und Story Points sind keine Konkurrenten - sie ergaenzen sich. Viele Teams verwenden T-Shirt-Groessen fuer die uebergeordnete Roadmap-Schaetzung und rechnen dann in Story Points um, wenn die Arbeit ins Sprint Planning kommt.

Der T-Shirt-Groessen-Prozess: Schritt fuer Schritt

Schritt 1: Definieren Sie Ihre Skala

Vor Ihrer ersten Sitzung einigen Sie sich darauf, was jede Groesse fuer Ihr Team bedeutet. Es gibt keinen universellen Standard - was zaehlt, ist die Konsistenz innerhalb Ihres Teams.

Eine typische 5-Punkte-Skala:

Groesse	Bedeutung	Beispiel
XS	Triviale Aenderung, minimaler Aufwand	Tippfehler beheben, Konfigurationswert aktualisieren
S	Klein, gut verstandene Aufgabe	Button hinzufuegen, einfaches Formularfeld
M	Mittlere Komplexitaet, klarer Ansatz	Neuer API-Endpunkt mit Validierung
L	Gross, mehrere Komponenten beteiligt	Komplettes Feature mit UI + Backend + Tests
XL	Sehr gross, erhebliche Unbekannte	Multi-System-Integration, neue Architektur

Manche Teams fuegen XXL hinzu („zu gross, muss aufgeteilt werden") oder XXS („bereits erledigt, muss nur noch verifiziert werden").

Schritt 2: Referenz-Stories festlegen

Waehlen Sie ein abgeschlossenes Arbeitspaket fuer jede Groesse. Diese werden zu Ihren Kalibrierungsankern.

• XS: „Die CSS-Farbaenderung, die wir letzten Sprint gemacht haben"
• S: „Die E-Mail-Validierung, die wir zum Registrierungsformular hinzugefuegt haben"
• M: „Die Benutzerprofilseite mit Avatar-Upload"
• L: „Die Zahlungsintegration mit Stripe"
• XL: „Das Echtzeit-Benachrichtigungssystem, das wir gebaut haben"

Schreiben Sie diese an eine Wand oder in ein gemeinsames Dokument. Verweisen Sie in jeder Schaetzungssitzung darauf.

Schritt 3: Das Arbeitspaket vorstellen

Der Product Owner beschreibt die User Story oder das Feature kurz:

• Was macht es?
• Fuer wen ist es?
• Gibt es bekannte Einschraenkungen oder Abhaengigkeiten?

Halten Sie es auf 1-2 Minuten. T-Shirt-Groessen funktionieren, weil sie schnell sind - machen Sie keine Anforderungsanalyse daraus.

Schritt 4: Unabhaengig schaetzen

Jedes Teammitglied waehlt privat eine Groesse. Methoden sind:

• Physische Karten mit aufgedruckten Groessen
• Finger (1 = XS, 2 = S, 3 = M, 4 = L, 5 = XL)
• Digitale Tools (Miro-Boards, Planning Poker-Apps mit T-Shirt-Optionen)

Der Schluessel: Alle decken gleichzeitig auf, genau wie bei Planning Poker. Dies verhindert den Ankereffekt.

Schritt 5: Aufdecken und diskutieren

Wenn alle uebereinstimmen (oder innerhalb einer Groesse liegen), notieren Sie die Groesse und machen weiter.

Bei einer grossen Abweichung (z.B. ein S und ein XL) erklaeren die Ausreisser:

• „Ich habe S gesagt, weil wir letzten Sprint etwas fast Identisches gebaut haben"
• „Ich habe XL gesagt, weil das das Zahlungssystem betrifft und allein die Compliance-Pruefung eine Woche dauert"

Normalerweise loest eine Diskussionsrunde die Differenz. Falls nicht, waehlen Sie die groessere Groesse - das ist sicherer, und man kann spaeter immer noch aufteilen.

Schritt 6: Erfassen und weitermachen

Schreiben Sie die T-Shirt-Groesse auf die Story-Karte oder in Ihr Backlog-Tool. Verbringen Sie nicht mehr als 60-90 Sekunden pro Element. Der ganze Sinn ist Geschwindigkeit.

Fuer grosse Backlogs (50+ Elemente): Verwenden Sie die Affinitaetsschaetzungs-Variante. Anstatt jedes Element zu diskutieren, sortieren alle Elemente schweigend in Groessenspalten, und diskutieren dann nur die Elemente, bei denen Teammitglieder unterschiedlicher Meinung sind.

T-Shirt-Groessen definieren

Die haeufigste Frage, die Teams stellen: „Was genau bedeutet jede Groesse?" Hier sind drei Ansaetze.

Ansatz 1: Aufwandbasierte Definition

Groesse	Ungefaehrer Aufwand	Beteiligte Teammitglieder
XS	Unter einem halben Tag	1 Person
S	Halber Tag bis 1 Tag	1 Person
M	1-3 Tage	1-2 Personen
L	3-5 Tage	2-3 Personen
XL	1-2 Wochen	Mehrere Personen
XXL	Mehr als 2 Wochen - aufteilen	Gesamtes Team

Ansatz 2: Komplexitaetsbasierte Definition

Groesse	Komplexitaetsmerkmale
XS	Bekannte Loesung, keine Abhaengigkeiten, keine Unbekannten
S	Bekannte Loesung, minimale Abhaengigkeiten
M	Groesstenteils bekannte Loesung, einige Abhaengigkeiten oder Unbekannte
L	Teilweise Unbekannte, mehrere Abhaengigkeiten, komponentenuebergreifend
XL	Erhebliche Unbekannte, externe Abhaengigkeiten, neue Muster erforderlich
XXL	Zu viele Unbekannte - zuerst Spike oder Aufschluesselung noetig

Ansatz 3: Beispielbasierte Definition

Ueberspringen Sie abstrakte Definitionen komplett. Fuehren Sie einfach eine Referenzliste mit 2-3 abgeschlossenen Elementen pro Groesse. Wenn das Team mehr Arbeit abschliesst, aktualisieren Sie die Beispiele. Dies ist der praktischste Ansatz, weil er die Schaetzung in der tatsaechlichen Erfahrung Ihres Teams verankert.

T-Shirt-Groessen in numerische Werte umrechnen

Irgendwann brauchen Sie Zahlen - fuer Velocity-Tracking, Kapazitaetsplanung oder Berichte an Stakeholder. So rechnen Sie um.

Gaengige Umrechnungstabellen

Lineare Umrechnung (einfachste):

XS	S	M	L	XL	XXL
1	2	3	5	8	13

Dies bildet direkt auf Fibonacci ab, was praktisch ist, wenn Ihr Team spaeter auf Story Points umsteigt.

Gewichtete Umrechnung (spiegelt exponentielles Wachstum wider):

XS	S	M	L	XL	XXL
1	3	5	8	13	21

Dies spiegelt besser die Realitaet wider, dass ein XL nicht einfach „5-mal groesser als ein XS" ist - es ist proportional unsicherer.

Stundenbasierte Umrechnung (fuer zeitfokussierte Teams):

XS	S	M	L	XL	XXL
2h	4h	1T	3T	1W	2W+

Verwenden Sie dies nur, wenn Ihre Organisation stundenbasierte Berichte erfordert. Die meisten Agile-Praktiker raten davon ab, da es Schaetzung mit Zusage verwechselt.

Wann umrechnen (und wann nicht)

Umrechnen wenn:

• Von der Roadmap-Planung zum Sprint Planning gewechselt wird
• Velocity ueber Sprints hinweg verfolgt wird
• Liefertermine prognostiziert werden
• An Stakeholder berichtet wird, die numerische Prognosen benoetigen

Nicht umrechnen wenn:

• Initiale Backlog-Schaetzung durchgefuehrt wird (schnell und grob halten)
• Roadmap-Diskussionen mit nicht-technischen Stakeholdern gefuehrt werden
• Das Team neu in der Schaetzung ist (lassen Sie sie sich erst mit relativer Schaetzung vertraut machen)

T-Shirt-Groessen vs. andere Schaetzungstechniken

Aspekt	T-Shirt-Groessen	Planning Poker	Affinitaetsschaetzung	Bucket-System
Geschwindigkeit pro Element	30-60 Sekunden	2-5 Minuten	10-20 Sekunden	15-30 Sekunden
Beste Stapelgroesse	20-100 Stories	10-20 Stories	50-200 Stories	30-100 Stories
Praezision	Niedrig (5-6 Kategorien)	Mittel (10+ Werte)	Niedrig-Mittel	Mittel
Lernkurve	Keine	Mittel	Niedrig	Niedrig
Velocity-Tracking	Erfordert Umrechnung	Direkt	Erfordert Umrechnung	Direkt
Am besten fuer	Roadmaps, neue Teams	Sprint Planning	Grosse Backlog-Sichtung	Mittlere Backlogs
Stakeholder-Freundlichkeit	Sehr hoch	Niedrig	Mittel	Niedrig

Gaengige Schaetzungsprogression:

1. T-Shirt-Groessen fuer initiale Roadmap- und Backlog-Priorisierung
2. Affinitaetsschaetzung fuer schnelle Bewertung grosser Backlogs
3. Planning Poker fuer Sprint-Level Story-Schaetzung

Teams muessen T-Shirt-Groessen nicht „entwachsen" - die Technik bleibt auch bei erfahrenen Teams fuer Roadmap-Diskussionen nuetzlich.

Wann T-Shirt-Groessen einsetzen

T-Shirt-Groessen sind die richtige Wahl wenn:

• Ihr Team ganz neu bei Agile ist - Starten Sie hier. Keine Lernkurve, keine Debatten darueber, was Zahlen bedeuten. Werden Sie vertraut mit relativer Schaetzung, bevor Sie Komplexitaet hinzufuegen.
• Sie ein grosses Backlog schaetzen - Muessen Sie 50+ Stories in einer Stunde schaetzen? T-Shirt-Groessen sind die einzige Technik, die schnell genug ist.
• Sie Roadmap-Planung machen - Fuehrungskraefte interessieren sich nicht fuer Fibonacci. „Dieses Feature ist Large, jenes ist Small" kommuniziert perfekt.
• Funktionsuebergreifende Gruppen schaetzen - Wenn Designer, Marketingfachleute und Entwickler gemeinsam schaetzen, sind T-Shirt-Groessen die gemeinsame Sprache.
• Sie einen schnellen ersten Ueberblick brauchen - „Besteht die Arbeit dieses Quartals hauptsaechlich aus Mediums, oder haben wir mehrere XLs?" hilft bei Kapazitaetsgespraechen ohne detaillierte Schaetzung.
• Stakeholder grobe Schaetzungen brauchen - „Die Migration ist ein XL, das neue Dashboard ist ein Medium" ist fuer einen PM nuetzlicher als „Die Migration hat 34 Story Points."

Wann T-Shirt-Groessen NICHT einsetzen

T-Shirt-Groessen reichen nicht aus wenn:

• Sie praezise Kapazitaetsplanung brauchen - Wenn Ihr Sprint Planning erfordert zu wissen, wie viele Elemente genau in einen Sprint passen, benoetigen Sie Story Points und Velocity-Tracking.
• Sie Velocity verfolgen muessen - T-Shirt-Groessen lassen sich nicht mathematisch addieren. „Wir haben 3 Larges und 5 Smalls abgeschlossen" sagt Ihnen nicht, ob das mehr oder weniger als letzten Sprint ist, ohne Umrechnung.
• Ihr Team eine etablierte Story-Point-Kalibrierung hat - Wenn Ihr Team bereits fliessend in Fibonacci denkt, fuegt T-Shirt-Groessen einen Uebersetzungsschritt hinzu, ohne Mehrwert zu bieten.
• Einzelne Stories detaillierten Vergleich brauchen - Wenn der Unterschied zwischen einer 5 und einer 8 wichtig ist (Passt diese Story in einen Sprint?), brauchen Sie numerische Praezision.

Verwenden Sie Planning Poker fuer Sprint-Level-Schaetzung. Verwenden Sie Affinitaetsschaetzung, wenn Sie mehr als 50 Elemente sehr schnell schaetzen muessen und bereits eine numerische Skala haben.

T-Shirt-Groessen fuer Remote-Teams

T-Shirt-Groessen eignen sich gut fuer Remote-Arbeit, da die Sitzungen kurz und die Skala einfach ist.

Synchron (Videoanruf):

• Verwenden Sie Miro, Mural oder FigJam mit Spalten von XS bis XL
• Jede Person zieht Haftnotizen in die Groessenspalten
• Diskutieren Sie Elemente, bei denen Uneinigkeit besteht
• Zeitlimit auf 45 Minuten fuer 30-50 Elemente

Asynchron (verteilte Zeitzonen):

• Teilen Sie das Backlog in einer Tabelle oder einem Jira-Board
• Jede Person fuegt ihre Groessenschaetzung ueber 24-48 Stunden hinzu
• Markieren Sie Elemente mit Uneinigkeit fuer einen 15-minuetigen Sync-Call
• Erfassen Sie die Konsens-Groessen

Jira-Einrichtung:

• Erstellen Sie ein benutzerdefiniertes Feld namens „T-Shirt-Groesse" (Dropdown: XS, S, M, L, XL, XXL)
• Verwenden Sie Jira-Plugins wie Easy Agile oder Agile Poker fuer interaktive Sitzungen
• Erstellen Sie bei Bedarf ein separates numerisches Feld fuer umgerechnete Story Points

Miro-Vorlagen-Ansatz:

• Erstellen Sie Spalten fuer jede Groesse
• Fuegen Sie alle Stories als Haftnotizen hinzu
• Team sortiert Stories schweigend in Spalten
• Diskutieren und loesen Sie alle Stories, die in verschiedenen Spalten gelandet sind

Haeufige Fehler bei T-Shirt-Groessen

Fehler 1: Groessen als exakte Zeitschaetzungen behandeln

So sieht es aus: „Ein Medium sind 3 Tage. Das ist ein Medium, also ist es bis Mittwoch fertig."

Warum es ein Problem ist: T-Shirt-Groessen repraesentieren relative Komplexitaet, nicht Kalender-Zusagen. Ein Medium bedeutet „ungefaehr der gleiche Aufwand wie andere Mediums" - keine bestimmte Dauer.

Loesung: Verwenden Sie Groessen fuer relativen Vergleich und Planung. Wenn Sie Termine brauchen, rechnen Sie in Story Points um und verwenden Sie Velocity-basierte Prognosen.

Fehler 2: Zu viele Groessenkategorien

So sieht es aus: Das Team verwendet XS, S, SM, M, ML, L, XL, XXL, XXXL - neun Kategorien.

Warum es ein Problem ist: Mehr Kategorien verfehlen den Zweck. Sie haben numerische Schaetzung mit schlechteren Bezeichnungen neu erfunden. Der Wert von T-Shirt-Groessen ist Geschwindigkeit durch Einschraenkung.

Loesung: Bleiben Sie bei 5 Groessen (XS, S, M, L, XL). Fuegen Sie XXL nur als „zu gross, muss aufgeteilt werden"-Kennzeichnung hinzu.

Fehler 3: Keine Referenz-Stories

So sieht es aus: „Ist das ein Medium? Was ist ueberhaupt ein Medium in diesem Team?"

Warum es ein Problem ist: Ohne Kalibrierung koennte dasselbe Feature von einer Person als Small und von einer anderen als Large eingestuft werden. Schaetzungen werden inkonsistent und nutzlos.

Loesung: Waehlen Sie vor Ihrer ersten Sitzung 1-2 abgeschlossene Elemente fuer jede Groesse. Halten Sie diese in jeder Schaetzungssitzung sichtbar.

Fehler 4: Gleichzeitiges Aufdecken ueberspringen

So sieht es aus: „Ich denke, das ist ein Large." Alle nicken.

Warum es ein Problem ist: Die erste Person, die spricht, ankert alle anderen. Dies zerstoert das unabhaengige Denken, das Gruppenschaetzungen genau macht.

Loesung: Immer gleichzeitig aufdecken - Finger hochhalten, Karten umdrehen oder ein digitales Tool verwenden, das Schaetzungen verbirgt, bis alle abgegeben haben.

Fehler 5: T-Shirt-Groessen fuer Sprint-Zusagen verwenden

So sieht es aus: „Wir haben Kapazitaet fuer ein XL, zwei Ls und drei Ms in diesem Sprint."

Warum es ein Problem ist: Ohne numerische Umrechnung koennen Sie das nicht tatsaechlich ueberpruefen. Entspricht ein XL zwei Ls? Entsprechen zwei Ls drei Ms? Die Mathematik funktioniert nicht ohne die Definition expliziter Verhaeltnisse.

Loesung: Rechnen Sie vor dem Sprint Planning in Story Points um oder akzeptieren Sie, dass T-Shirt-Groessen nur fuer grobe Planung gedacht sind.

Fehler 6: Groessendefinitionen nie aktualisieren

So sieht es aus: Das Team hat Groessen vor sechs Monaten definiert. Seitdem ist ihre Codebasis gewachsen, Standards haben sich geaendert, und „Medium" bedeutet nicht mehr das, was es frueher bedeutete.

Warum es ein Problem ist: Die Schaetzungsgenauigkeit nimmt ab, wenn sich der Bezugsrahmen des Teams verschiebt.

Loesung: Ueberpruefen Sie Referenz-Stories jedes Quartal waehrend einer Sprint Retrospective. Aktualisieren Sie Beispiele, um die aktuelle Komplexitaet widerzuspiegeln.

T-Shirt-Groessen-Reifegrad: Vom Anfaenger zum Fortgeschrittenen

Stufe 1: Einstieg (Erste 1-3 Sprints)

Was Sie erwarten koennen:

• Grosse Uneinigkeit darueber, was jede Groesse bedeutet
• Manche Elemente brauchen 2-3 Minuten statt 30 Sekunden
• Team tendiert zu „Alles ist ein Medium"
• Haeufige Fragen wie „Was bedeutet Large?"

Fokus auf:

• Klare Referenz-Stories fuer jede Groesse etablieren
• Sitzungen kurz halten (maximal 30 Minuten)
• Sich noch nicht um Umrechnung kuemmern - erst mit relativer Schaetzung vertraut werden

Stufe 2: Konsistenz aufbauen (Sprints 4-8)

Was Sie erwarten koennen:

• Die meisten Elemente in unter 30 Sekunden geschaetzt
• Uneinigkeiten hauptsaechlich bei L- und XL-Elementen
• Team faengt natuerlich an, XLs vor der Schaetzung aufzuteilen
• Groessen werden vorhersehbar genug fuer grobe Planung

Fokus auf:

• Umrechnungstabelle einfuehren (Groessen zu Story Points)
• Verfolgen, wie viele Elemente jeder Groesse das Team pro Sprint abschliesst
• Groessen fuer Quartals-Roadmap-Gespraeche mit Stakeholdern nutzen

Stufe 3: Integrierte Schaetzung (Sprint 9+)

Was Sie erwarten koennen:

• T-Shirt-Groessen fliessen natuerlich in Planning Poker fuer Sprint-Level-Verfeinerung ueber
• Team nutzt T-Shirts fuer Roadmap, Story Points fuer Sprints
• Umrechnungsverhaeltnisse sind gut auf die tatsaechliche Teamleistung kalibriert
• Stakeholder verstehen und nutzen die Groessensprache

Fokus auf:

• Umrechnungsverhaeltnisse basierend auf tatsaechlichen Lieferdaten verfeinern
• Schaetzungsdaten fuer Release-Prognosen nutzen
• Neue Teammitglieder mit etablierten Referenz-Stories einarbeiten

Branchenbeispiele

SaaS-Produktteam

Schaetzung einer Quartals-Roadmap:

• XS: Tooltip zu bestehendem Feature hinzufuegen
• S: Neue E-Mail-Vorlage mit Merge-Tags
• M: Self-Service-Abrechnungsportal fuer Kunden
• L: SSO-Integration (SAML + OIDC)
• XL: Multi-Tenant-Datenisolierung Neugestaltung

Wie sie es nutzen: Product Manager und Engineering Lead schaetzen die Features des naechsten Quartals in einer 30-minuetigen Sitzung. Das Ergebnis fliesst in die Kapazitaetsverteilung ein: „Wir koennen ein XL, zwei Ls und mehrere S/M-Elemente dieses Quartal unterbringen."

E-Commerce-Plattform

Schaetzung eines Product Backlogs:

• XS: Versandlabel-Format aktualisieren
• S: „Geschenkverpackung"-Option zum Checkout hinzufuegen
• M: Produktempfehlungs-Karussell implementieren
• L: Treuepunkte-System aufbauen
• XL: Zahlungsabwicklung zu neuem Anbieter migrieren

Wie sie es nutzen: Waehrend der Release-Planung schaetzt das Team 80+ Backlog-Elemente in unter einer Stunde. Sie rechnen nur fuer die Elemente in Story Points um, die in die naechsten zwei Sprints eingehen.

Gesundheitswesen-Anwendung

Schaetzung compliance-bezogener Features:

• XS: Datenschutzrichtlinien-Anzeige aktualisieren
• S: Audit-Log-Eintrag fuer eine neue Aktion hinzufuegen
• M: Rollenbasierte Zugriffskontrolle fuer ein neues Modul implementieren
• L: HIPAA-konformen Patientendatenexport erstellen
• XL: Ende-zu-Ende-Verschluesselung fuer Messaging implementieren

Wie sie es nutzen: Der Compliance-Beauftragte nimmt an T-Shirt-Groessen-Sitzungen teil, weil die Skala intuitiv ist. Er markiert: „Jedes L oder XL, das PHI beruehrt, braucht zuerst einen Compliance-Review-Spike."

Mobile App-Entwicklung

Schaetzung eines Feature-Backlogs fuer iOS und Android:

• XS: Abstand auf dem Einstellungsbildschirm beheben (beide Plattformen)
• S: „Teilen"-Button zu Benutzerprofilen hinzufuegen (beide Plattformen)
• M: Biometrisches Login implementieren (jede Plattform separat)
• L: Offline-Synchronisierung mit Konfliktloesung aufbauen
• XL: Echtzeit-Chat mit Push-Benachrichtigungen hinzufuegen

Wie sie es nutzen: Plattformunterschiede bedeuten, dass dasselbe Feature unterschiedliche Groessen haben kann. „Biometrisches Login ist ein Small auf iOS (Face ID ist gut dokumentiert), aber ein Medium auf Android (fragmentierte Hardware-Unterstuetzung)."

Agentur / Beratung

Schaetzung von Kundenprojekt-Angeboten:

• XS: Landingpage aus Vorlage (2-5K EUR)
• S: Benutzerdefinierte WordPress-Seite (5-10 Seiten) (5-15K EUR)
• M: E-Commerce-Seite mit Zahlungsintegration (15-40K EUR)
• L: Benutzerdefinierte Webanwendung mit Benutzerverwaltung (40-100K EUR)
• XL: Unternehmensplattform mit Integrationen (100K+ EUR)

Wie sie es nutzen: Vertriebs- und Delivery-Teams verwenden T-Shirt-Groessen in Angeboten. „Dieses Projekt ist ein Large basierend auf unseren Referenzprojekten" gibt Kunden und Delivery-Teams ein gemeinsames Verstaendnis, bevor die detaillierte Schaetzung beginnt.

Best Practices

Vor der Sitzung:

• Referenz-Stories dort platzieren, wo alle sie sehen koennen
• Backlog vorsortieren - offensichtliche XS- oder XL-Elemente ueberspringen
• Bei komplexen Elementen das Backlog 24 Stunden vorher teilen

Waehrend der Sitzung:

• Jedes Element auf 60 Sekunden begrenzen (einschliesslich kurzer Diskussion)
• Wenn ein Element mehr als 2 Minuten zum Schaetzen braucht, fuer eine separate Vertiefung markieren
• Nach Zuversicht sortieren: zuerst die offensichtlichen schaetzen, um Schwung aufzubauen
• „XXL" als Ausloeser zum Aufteilen verwenden, nicht als gueltige Schaetzung

Nach der Sitzung:

• Groessen sofort im Backlog-Tool erfassen
• Elemente markieren, die weitere Recherche (Spikes) benoetigen, bevor sie geschaetzt werden koennen
• Nur in Story Points umrechnen, wenn die Arbeit sich dem Sprint Planning naehert

Moderationstipps:

• Den Moderator jede Sitzung rotieren
• Fuer grosse Backlogs (50+) zuerst stilles Sortieren (Affinitaets-Stil) nutzen, danach Unstimmigkeiten diskutieren
• Wenn das Team haeufig uneins ist, muessen Ihre Groessendefinitionen aktualisiert werden - nicht Ihr Team

Fazit

T-Shirt-Groessen funktionieren, weil sie Praezision gegen Geschwindigkeit und Zugaenglichkeit eintauschen. Sie brauchen in der fruehen Planung keine Praezision - Sie brauchen Richtung. Ist dieses Feature ein kleiner Aufwand oder ein grosser? Diese Antwort eroeffnet Roadmap-Gespraeche, Kapazitaetsplanung und Backlog-Priorisierung ohne den Aufwand detaillierter Schaetzung.

Wichtigste Erkenntnisse:

1. Verwenden Sie 5 Groessen (XS bis XL) - mehr Kategorien verfehlen den Zweck
2. Etablieren Sie Referenz-Stories - sie sind Ihr Kalibrierungswerkzeug
3. Decken Sie gleichzeitig auf - unabhaengige Schaetzung verhindert den Ankereffekt
4. 60 Sekunden pro Element - wenn es laenger dauert, braucht das Element Verfeinerung, nicht mehr Schaetzung
5. Rechnen Sie fuer Sprint Planning in Story Points um - T-Shirt-Groessen sind fuer grobe Planung, nicht fuer Kapazitaets-Zusagen
6. T-Shirt-Groessen und Story Points ergaenzen sich - Groessen fuer Roadmaps, Punkte fuer Sprints
7. Aktualisieren Sie Ihre Referenzen quartalweise - was „Medium" bedeutet, aendert sich, wenn Ihr Team und Ihre Codebasis sich weiterentwickeln

Beginnen Sie damit, Ihr aktuelles Backlog in einer einzigen 30-minuetigen Sitzung zu schaetzen. Sie werden ueberrascht sein, wie viel Klarheit ein einfaches Small/Medium/Large-Gespraech schafft - und wie schnell Ihr Team vorankommen kann, wenn Schaetzung aufhoert, sich wie eine laestige Pflicht anzufuehlen.

Weiterlesen

Haeufig gestellte Fragen

Häufig gestellte Fragen (FAQs)