Was vorher fertig sein muss
Eine Produktrichtung oder Roadmap-Idee mit Themen oder Epics liegt vor, sodass die zu sizenden Items überhaupt benannt sind.
Was vor Start vorliegen muss
Whiteboard oder Miro-Board mit 5 Spalten (XS, S, M, L, XL); Haftnotizen oder Karten mit je einem Item; zwei bis drei vordefinierte Referenz-Items pro Größe; Timer; Stiftfarben für Markierungen.
Ein Facilitator, der durch die Sortierung führt; ein Product Owner für Item-Kontext; das umsetzende Team (Engineering, Design, je nach Item-Typ); optional ein Tech Lead für Architektur-Einschätzung.
Liste der zu sizenden Epics oder Items mit kurzer Beschreibung; Liste der Referenz-Items aus vergangenen Releases mit ihrer realen Größe; bekannte Constraints (Team-Kapazität, externe Abhängigkeiten).
15-45 min
Fünf Spalten an die Wand: XS (<1 Sprint), S (1 Sprint), M (2-3 Sprints), L (Quartal), XL (Halbjahr+). Referenz-Items in jede Spalte kleben. Regel ansagen: keine Stunden- oder Punkt-Diskussion, nur Vergleich mit Referenzen.
Die eine Frage, die diese Methode beantwortet
In welche Größenklasse fällt jedes Item relativ zu unseren Referenzen, und welche Items sind so groß, dass sie vor Planung geschnitten werden müssen?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Referenzen kalibrieren | 10 min | Referenz-Items pro Größenklasse gemeinsam ansehen. Wer abweichendes Verständnis hat, äußert es jetzt. Referenzen werden bei Bedarf umsortiert, bis Gruppe Konsens hat. | Ohne kalibrierte Referenzen ist die Sortierung Bauchgefühl. Wenn keine Referenzen aus echten Releases existieren, vor dem Workshop welche aus Roadmap-Historie auswählen. |
2Phase 2: Stilles Sortieren | 15 min | Items in zufälliger Reihenfolge an die Wand. Teilnehmer sortieren still in Spalten, dürfen Items anderer verschieben. Keine Diskussion in dieser Phase. | Wenn ein Item zwischen zwei Personen mehrfach hin- und hergeschoben wird, ist es ein Diskussionskandidat für Phase 3. Items still mit Punkt markieren. |
3Phase 3: Strittige Items klären | 15 min | Pro strittigem Item maximal 2 min: höchste und niedrigste Einschätzung erklären Annahmen, danach Entscheidung. XL-Items markieren als Slicing-Kandidaten. | Bei mehr als 5 strittigen Items hat die Gruppe entweder zu wenig Kontext oder die Referenzen passen nicht. Workshop pausieren, Discovery nachziehen. |
4Phase 4: XL-Items splitten oder parken | 10 min | Pro XL-Item entscheiden: Splitten (in welche kleineren Items zerfällt es), Spike (Discovery vorschalten) oder Parken (passt aktuell nicht). Ergebnis im Roadmap-Backlog dokumentieren. | XL-Items ohne Split bleiben Wunschdenken. Wer keinen Split-Vorschlag liefern kann, hat kein Lösungsverständnis, Item gehört in Discovery. |
Was am Ende rauskommt
Roadmap-Tabelle oder Board mit Spalten je Größe, jedem Item zugeordnet, plus separater Sektion für Slicing-Kandidaten und Spike-Bedarf. Annahmen pro Item als Kurznotiz.
Pro Roadmap-Review (üblicherweise quartalsweise) neue Version. Größenänderungen mit Datum und Begründung im Item dokumentieren, alte Werte nicht überschreiben. Bei Item-Split: alte ID als „aufgelöst in X, Y, Z“ markieren.
Kompakte Arbeitsvorlage für T-Shirt Sizing mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# T-Shirt Sizing Canvas
## Kontext
Wofür wird die Methode eingesetzt?
## Kernfrage
Welche Frage soll am Ende beantwortet sein?
## Input
Welche Daten, Beobachtungen oder Materialien liegen vor?
## Arbeitsfläche
- Bereich 1:
- Bereich 2:
- Bereich 3:
- Beziehungen / Muster:
## Ergebnisartefakte
- Size Buckets:
- Rough Backlog Map:
- Split Candidates:
## Offene Fragen
- ...
## Nächster Schritt
Owner, Datum, Erfolgssignal.Konkret gefülltes Szenario
## T-Shirt Sizing — Roadmap H2/2026, 2026-05-18
**Referenzen**
- XS: Onboarding-Tooltip-Update (3 Tage)
- S: Single-Sign-On-Integration mit Google
- M: Mandanten-Export als CSV/JSON
- L: Multi-Tenant-Mandantenverwaltung (Q1 2026 abgeschlossen)
- XL: Komplette Migration auf neue Datenbank (geparkt seit 2025)
**Ergebnis (12 Items)**
- XS: Tooltips überarbeiten
- S: DATEV-Import-Validierung, Empfehlungsprompt im Dashboard
- M: API-Webhook-System, neue Reporting-Module
- L: Mandanten-Self-Service-Portal (mit @ben), Workflow-Builder
- XL: KI-gestützte Belegerkennung (Slicing erforderlich), White-Label-Variante
**Slicing/Spike**
- KI-Belegerkennung -> Spike „Anbieter-Vergleich“ (2 Wochen, @anna).
- White-Label -> drei Teilstories für Q4 vorgeschlagen: Branding-Settings, Custom-Domain, Mandanten-Whitelabel-Toggle.Symptome erkennen, gegensteuern
Diskussion dreht sich um „M ist so 4 Wochen, oder?“ statt um Vergleich mit Referenz-Item.
Facilitator unterbricht: T-Shirt-Größen sind Vergleichsklassen, keine Stundenwerte. Wer Forecast braucht, nutzt Velocity oder Monte Carlo getrennt.
Spalten sind leer, Gruppe sortiert nach Gefühl ohne Kalibrierungsanker.
Workshop pausieren, drei bis fünf Referenz-Items aus realer Liefer-Historie suchen und einsortieren. Ohne Referenzen ist die Methode Bauchgefühl mit Klassenetikett.
Mehrheit der Items landet in den großen Spalten, kleine Spalten sind leer.
Entweder ist die Roadmap zu ambitioniert oder Items wurden auf Epic-Ebene zu grob geschnitten. Vor Sizing in mittlere Granularität bringen oder Vergleichsmaßstab schärfen.
Teilnehmer fragen wiederholt, was ein Item bedeutet, Sortierung steht still.
Sizing-Workshop ist nicht Discovery. Unklare Items aussortieren und in eigene Refinement-Session geben. Sizing nur mit verstandenen Items.
Product Owner verteilt Größen ohne Umsetzungsteam, Engineering korrigiert später drastisch.
Mindestens ein Tech Lead pro Item-Bereich anwesend. Sizing ist Team-Schätzung. PO bringt Scope, Team bringt Aufwandseinschätzung.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.