Internal LOE Explanation.

The team's shared sizing language — how Jira story points translate to T-shirt sizes and to days of work. One scale, used by everyone, calibrated against historical delivery.

01Correspondence table

— story points, T-shirt size, days/man-day equivalent

Story Points	T-shirt	Days/man	What it usually means
1	XS	< 0.5 day	Trivial change. Copy edit, config tweak, single-line fix. No design needed.
2	S	0.5 – 1 day	Small isolated change, single PR, no cross-team coordination.
3	S	1 – 2 days	Standard small story. Clear scope, known pattern, light QA.
5	M	2 – 3 days	Medium story. Some complexity or coordination, multiple files / components.
8	L	3 – 5 days	Large story. Multiple parts, possibly cross-team, non-trivial QA.
13	XL	5 – 10 days	Very large. Should be split if at all possible — split first, estimate second.
21+	—	> 10 days	Must be split into smaller stories before entering a sprint. Anything 21+ means “we don’t really know yet.”

What a story point covers

Code · unit tests · code review · QA · monitoring instrumentation · deployment · documentation. Not just “dev time” — everything needed for the story to be Done.

02Sizing principles

— eight rules that keep the scale honest

01 Relative, not absolute. Story points are calibrated against the team's historical delivery, not against an industry benchmark. A "5" on team A is not a "5" on team B.
02 Sized by the team. Never by the PM, the tech lead alone, or any single individual. Use Planning Poker (or async equivalent) so every voice counts.
03 Fibonacci, not linear. The scale is 1, 2, 3, 5, 8, 13, 21. The gaps grow on purpose — large stories carry more uncertainty, and our estimation precision drops with size.
04 Discuss spreads > 2 levels. If estimates spread by more than two Fibonacci steps, do not average. Stop. Discuss. The spread reveals a hidden assumption.
05 T-shirt sizing for high-level discovery only. Use XS–XL during framing / business case, when no design exists. Switch to story points the moment a refined ticket enters the backlog.
06 Velocity = sum of points completed per sprint. Used to forecast capacity, not to compare teams or judge individuals. Velocity is a planning tool, not a performance metric.
07 Re-estimate when scope changes. Mid-sprint scope changes mean the original estimate is invalid. Re-estimate or split — never silently absorb.
08 The LOE is the agreed estimation post-sizing session. The number written in the Jira ticket field is the team's shared commitment, not the dev's gut feel.

03When to split a story

— the “13” rule and what to do about it

If the team estimates a story at 13 or higher, the story is too big to be predictable. The right move is to split first, estimate second. Common splitting patterns:

A By workflow step. "User adds product to cart" → (1) UI for add-to-cart button, (2) cart state management, (3) cart persistence across sessions.
B By happy path / edge cases. Ship the happy path first, then handle empty state, error state, mobile-specific behaviour as separate stories.
C By data slice. Implement for one user segment / one product type / one country first, then expand.
D By interface. Backend API first (with a stub UI), then full UI in a separate ticket.

Anti-pattern

Don’t commit a 13. Splitting feels like overhead. Committing to a 13 in the sprint is the silent way teams overcommit. Resist it — the 30 minutes spent splitting saves 3 days of mid-sprint pain.

← Back to the process