Vact Agile Estimation Techniques: Story Points, T-Shirts, and Beyond
Estimation is one of the most contentious topics in agile project management. Teams need estimates to plan sprints, forecast delivery dates, and communicate timelines to stakeholders. But estimates are inherently uncertain, and teams that treat them as commitments create dysfunction. The key is choosing estimation techniques that provide useful forecasts without pretending to offer false precision.
Agile Estimation Techniques: Story Points, T-Shirts, and Beyond
Why Relative Estimation Works
Traditional project management estimates work in hours or days. Agile teams prefer relative estimation, where items are compared to each other rather than estimated in absolute units. Relative estimation works better because humans are poor at absolute estimation but good at comparing things.
Ask someone how heavy a box is and they will guess poorly. Ask them whether Box A is heavier than Box B and they will usually get it right. Story points, T-shirt sizes, and other relative techniques leverage this natural ability.
Story Points
Story points are the most common agile estimation unit. They measure the relative size of a work item based on complexity, effort, and uncertainty. A story estimated at 5 points is roughly 2.5 times the work of a 2-point story.
The Fibonacci Scale
Most teams use a modified Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21. The increasing gaps between numbers reflect the increasing uncertainty in larger estimates. If you think a story is somewhere between 5 and 8 points, the gap between those numbers is appropriate for that level of uncertainty. If the scale were linear (5, 6, 7, 8), teams would waste time debating whether a story is 6 or 7 points — a distinction that adds no value.
Calibrating Story Points
New teams need a reference story. Pick a well-understood story the team has completed and assign it a baseline value, typically 3 or 5 points. All future estimates are relative to this reference. “Is this story bigger or smaller than our reference story? By how much?”
Over time, the team develops a shared understanding of what each point value represents. This calibration is team-specific — one team’s 5-point story might be another team’s 8-point story, and that is fine. Story points are only meaningful within the team that created them.
Planning Poker
Planning poker is a technique for achieving consensus on estimates. Each team member holds a set of cards with Fibonacci numbers. The Product Owner reads a user story and answers questions. Each team member privately selects a card. All cards are revealed simultaneously.
If estimates are unanimous or close (e.g., all 5s and 8s), the team accepts the majority estimate. If estimates diverge significantly (e.g., a 3 and a 21), the highest and lowest estimators explain their reasoning. Often, one person has information the others lack — a hidden technical complexity or a simpler approach. After discussion, the team re-estimates.
Planning poker works because it prevents anchoring (no one sees others’ estimates before choosing), surfaces hidden knowledge, and builds shared understanding of the work.
T-Shirt Sizing
T-shirt sizing uses categories — XS, S, M, L, XL — instead of numbers. This technique is faster than story points and works well for high-level estimation during roadmap planning or initial backlog refinement.
| Size | Relative Effort | Typical Story Point Equivalent |
|---|---|---|
| XS | Very small, well-understood | 1-2 |
| S | Small, minimal complexity | 3 |
| M | Medium, some complexity | 5 |
| L | Large, significant complexity | 8-13 |
| XL | Very large, needs splitting | 13-21+ |
T-shirt sizes are particularly useful when the team needs to estimate a large number of items quickly, such as during product discovery or quarterly planning.
No Estimates (#NoEstimates)
The #NoEstimates movement argues that teams should stop estimating individual items and instead use historical throughput data to forecast delivery. If a team completes an average of 8 stories per sprint, they can forecast that 40 stories will take approximately 5 sprints.
This approach works when stories are roughly similar in size and the team has a stable throughput history. It fails when story sizes vary wildly or when stakeholders need item-level effort information for prioritization.
Estimation Anti-Patterns
Converting story points to hours. The moment management converts story points to hours, the team loses the benefits of relative estimation. Points become a proxy for hours, and the team feels pressure to deliver in exact timeframes.
Estimating in isolation. One person estimating a story misses the collaborative knowledge-sharing that makes team estimation valuable. Always estimate as a team.
Penalizing estimation errors. If the team is held accountable for individual story estimates, they will pad estimates to protect themselves. This undermines the trust and transparency that make agile estimation useful.
Estimating too far ahead. Stories that are months away from implementation will change significantly before the team works on them. Estimate only stories that are within two to three sprints of being started.
Ignoring velocity trends. A single sprint’s velocity is noisy. Use a rolling average of the last three to five sprints for forecasting. If velocity is trending down, investigate — it may indicate growing technical debt, team turnover, or process issues worth addressing in a retrospective.
Choosing the Right Technique
Use T-shirt sizing for high-level roadmap planning. Use story points with planning poker for sprint-level estimation. Consider #NoEstimates if your team has stable throughput and similarly-sized stories. The best estimation technique is the one your team uses consistently and finds valuable — not the one that is most theoretically pure.