Estimating Epics and Large Stories - When to Use T-Shirt Sizing
How do you estimate epics and features that are too large for sprint planning? Do you use planning poker with large numbers (20, 40, 100) or switch to T-shirt sizing? We need roadmap-level estimates for quarterly planning.
Three-tier approach works best: T-shirts for epics (XS=1-2 sprints, S=3-4 sprints, M=5-8 sprints, L=9-16 sprints, XL=too big, must split), Planning poker for features within epics (use 1-13 scale), Standard poker for user stories in sprint planning (1-8 scale).
Each tier uses appropriate granularity for its horizon. Convert T-shirts to story points for roadmap math using midpoint values: XS=25pts, S=75pts, M=175pts, L=325pts based on your team's average velocity.
Extended Fibonacci for everything: 1,2,3,5,8,13,20,40,100. Epics are 40-100pts, features are 13-40pts, stories are 1-13pts. Keeps everything in same unit for easy aggregation.
If epic is estimated as 100pts and team velocity is 50pts/sprint, you know it's minimum 2 sprints. Simple math, no conversion tables, stakeholders see the timeline directly.
T-shirts for epics, but map them to sprint ranges not points. XS=1 sprint, S=2-3 sprints, M=1 quarter, L=2 quarters, XL=deferred (too uncertain to even estimate).
Product stakeholders understand time horizons better than story points. Avoids false precision of "this epic is 87 points." Just say "this is a Medium epic, plan 1 quarter" and refine as you learn more.
Controversial: Don't estimate large items at all - decompose them first. If epic is too big to estimate with any accuracy, it's too big to plan reliably.
Break into smaller features (spike if necessary), estimate those. Large estimates are always wildly wrong anyway - I've seen "100pt epics" deliver in 40pts and others take 300pts. Better to say "we'll know more after discovery spike" than pretend you can estimate huge unknowns.