Story points vs t-shirt sizing

Numbers add up. T-shirts don't. Pick the one whose arithmetic you need.

Points (Fibonacci, modified Fibonacci, Powers of 2) and t-shirts (XS / S / M / L / XL) are the same technique wearing different clothes. Both are relative-effort scales with non-uniform gaps; both rely on a reference story; both work for the same reasons. The interesting choice isn't which one is "better" — it's whether the team wants a scale whose values you can sum into a velocity number, or one whose values you can't.

Velocity is the whole question. If the team measures it, points are the simpler tool — sum the points completed each sprint and you have a forecast input. T-shirts can't do that without a mapping back to numbers, and the moment you write that mapping on the wiki, you're using points with extra steps. If the team doesn't measure velocity — early in a team's life, in a roadmap exercise, on a backlog refinement pass before stories even enter a sprint — t-shirts cost less because there are fewer values to argue about.

Where the "build a conversion table" instinct comes from

Someone outside the team wants velocity. The team's been sizing with t-shirts. Someone proposes "S = 2, M = 5, L = 13" so the existing backlog can roll up. Every team's wiki has this. Almost no team actually uses it. The conversion is a translation layer that recasts every conversation as "is this an S or an M?" rather than "what's the unknown here?"

If you need both — a roadmap-level pass and a sprint-level estimate — run two passes with two scales and don't translate between them. T-shirts at the roadmap level, points at the sprint level. The two scales serve different conversations and they don't need to agree.

If you track velocity, use points. If you don't, t-shirts are lighter. Don't build the conversion table.

Adjacent: story points vs hours for the related conversion failure mode; other estimation techniques compares both against affinity mapping and bucket sizing.