Posted by Abhishek on February 05, 2026
This post expands on Project Estimation from the Architect-101 series.
Estimation is one of the most talked-about and often misunderstood activities in software delivery. Done well, it helps teams commit realistically, plan capacity, and spot work that needs to be broken down. Done poorly, it becomes a source of stress, missed deadlines, and distrust. This article covers what software estimation is, two common approaches: T-shirt sizing and Story Points - and how to use Story Points in a disciplined way.
Software estimation is the process of predicting the effort, time, or cost required to deliver a piece of work - a feature, user story, epic, or project. It is not a promise or a guarantee; it is a forecast based on what we know today.
Why we estimate:
Estimation is useful when it drives these outcomes. It becomes harmful when it is treated as a commitment to a fixed date without re-estimating as we learn.
Two widely used relative estimation approaches are T-shirt sizing and Story Point Estimation. Both compare work items to each other instead of guessing hours.
T-shirt sizing uses labels like XS, S, M, L, XL (and sometimes XXL) to indicate relative size. No numbers are attached-only order of magnitude.
| Size | Meaning (typical) |
|---|---|
| XS | Trivial; minutes to an hour. |
| S | Small; part of a day. |
| M | Medium; a day or a few days. |
| L | Large; a week or more. |
| XL | Very large; multiple weeks; consider splitting. |
When to use: Roadmap discussions, epics, initiatives, or when the audience is non-technical. It is quick and avoids false precision. It is less suitable for sprint planning where you need finer granularity.
Limitation: Only a few buckets, so many items land in “M” or “L” and still need to be broken down or refined before development.
Story Points are a unit of relative size. They combine effort, uncertainty, and complexity into a single number so that the team can compare stories and plan sprints. Points are not hours - they are consistent within a team over time.
Story points are usually chosen from a Fibonacci-like sequence so that the gap between numbers grows as size grows. This reflects the fact that we are less precise when things are bigger.
A common scale is:
0, 1, 2, 3, 5, 8, 13 (and sometimes 21 for “too big to fit in a sprint”).
Why cap at 13 (or treat 21 as out-of-scope for a single story)?
High point values mean high uncertainty. A “13” or “21” is a reminder: don’t commit to this as one story. Split it into smaller, shippable stories with lower points (e.g. 3, 5, 8). So: higher story points are an indicator to break that user story into more achievable stories or tasks with smaller points.
A story point should reflect three factors:
So: Story Point ≈ f(Risk, Complexity, Repetition). Same “raw” effort can be 3 or 5 depending on risk and repetition.
Before the team assigns a number, make sure these are discussed:
If most answers are “we don’t know,” the story is not ready to estimate. Refine it first, or give it a high point and plan to split.
Triangulation means checking your estimate against nearby numbers. If you think a story is 5, explicitly ask:
This does two things:
So: triangulate on the points. “I put 5-can we debate why it’s not 3 or 8?” is a healthy ritual in refinement or planning.
| Concept | Takeaway |
|---|---|
| Software estimation | A forecast of effort/time/cost to support planning and conversation, not a fixed promise. |
| T-shirt sizing | XS–XL for high-level, roadmap or epic-level comparison; quick and coarse. |
| Story points | Relative size in a Fibonacci-like scale (0, 1, 2, 3, 5, 8, 13; 21 = split). |
| High points | Signal to break the work into smaller, achievable stories with lower points. |
| Three factors | Risk (uncertainty, dependencies), Complexity (effort to build), Repetition (familiarity). |
| Before pointing | Design, scope, acceptance criteria, dependencies, expertise, complexity, risks. |
| Triangulation | Debate why the story is not the next number down or up (e.g. why 5 and not 3 or 8). |
Short answer: It’s not wrong, but it’s a trade-off.
Many teams use a rough conversion like “1 point = 0.5 days” or “1 point = 4 hours” for capacity planning or to explain velocity to stakeholders. That’s acceptable and can be useful when:
The risks of fixing “1 point = X hours” are:
Recommendation: Use a conversion only as an internal, loose guideline for planning (e.g. “we treat 1 point as about half a day for capacity”). Don’t bake it into contracts or use it to compare teams. Keep estimating in relative terms first; convert to time only when you need to communicate or plan.
Estimation is a team skill. Keep the scale consistent, cap big numbers so they get split, and use Risk, Complexity, and Repetition plus a short checklist and triangulation - so that Story Points and T-shirt sizes actually improve planning and delivery rather than becoming a ritual.