How to Estimate Software Projects More Accurately: Story Points, T-Shirt Sizes and Ranges

“How long will it take?” is the most common question in software, and one of the hardest to answer honestly. Give a number too low and you spend months explaining delays. Pad it too much and the project never gets approved. Either way, trust between developers and the business erodes.

The problem is rarely that developers are bad at estimating. It is that software work is full of unknowns, and most organizations ask for a single, precise number at the moment they know the least. Better estimation is less about a magic technique and more about choosing the right method for the stage of the project and communicating uncertainty clearly.

This guide compares the 3 most common approaches, story points, t-shirt sizing and ranges, and gives you practical tips for estimates people can actually plan around.

Why software estimates go wrong

A few patterns cause most bad estimates:

• Unclear scope. If requirements are vague, the estimate is a guess about a guess. A clear software requirements document or well-written user stories fix much of this.
• Big, undivided work. Large items hide complexity. “Build the customer portal” is impossible to estimate well. “Add password reset by email” is not.
• Forgetting the non-coding work. Testing, code review, deployments, meetings, bug fixes, data migration and support all take time.
• Optimism and anchoring. People tend to picture the happy path. Once someone says “2 weeks”, later estimates tend to cluster around it.
• Estimates treated as commitments. When a rough early guess becomes a deadline, teams start padding or hiding problems.
• Unknown unknowns. Third-party APIs, legacy code and new technology always surprise someone.

Estimates naturally get more accurate as the project progresses and unknowns are resolved. That is why the right method changes over time.

Story points, t-shirt sizing and ranges compared

T-shirt sizing

T-shirt sizing is the quickest way to rough out a large set of work. The team sorts features into sizes by comparing them with each other, not by calculating hours. It is ideal when you’re deciding what goes on a quarterly roadmap or whether a project is worth doing at all. To convert sizes into time, map each size to a range based on past work, such as “M usually takes 1 to 2 weeks for our team”.

Story points

Story points measure relative effort, including complexity, uncertainty and volume of work. A 5-point story should be roughly 5 times the effort of a 1-point story for that particular team. Many teams estimate with planning poker: each person picks a card privately, everyone reveals at once, and the people with the highest and lowest estimates explain their thinking. The Agile Alliance notes that the spread of estimates is useful information in itself, and forcing quick consensus can hide real uncertainty.

Over a few sprints, the team learns its velocity, the average points completed per sprint, which makes forecasting possible. Note that the Scrum Guide itself does not require story points; it says only that the developers who will do the work are responsible for sizing it. Story points are one popular way to do that.

Ranges with confidence levels

A range, such as “8 to 12 weeks, and we’re about 80% confident”, is the most honest way to communicate an estimate. It tells stakeholders both the likely outcome and the risk. The width of the range itself is useful: a wide range signals that you should spend time reducing uncertainty before committing.

Key takeaway: Use t-shirt sizes when you know little, story points or throughput when the team is delivering regularly, and always communicate the result as a range with a confidence level rather than a single date.

How to break work down so it can be estimated

Smaller pieces produce better estimates because you can see the work clearly. Practical rules:

1. Split features into user stories that each deliver something testable. Our guide on how to write user stories shows how to add acceptance criteria that make scope clear.
2. Aim for items a team can finish in a few days. Anything bigger than about half a sprint should usually be split.
3. Split by workflow step, data type, user role or business rule, rather than by technical layer (front end, back end, database).
4. List hidden work explicitly: tests, documentation, monitoring, data migration, security review and deployment.
5. Create a spike for unknowns. A spike is a time-boxed investigation, such as 2 days to test a payment API, that turns a big unknown into something you can estimate.

Use historical data, not gut feeling

The best predictor of how long something will take is how long similar work took before.

• Track actuals. Record how long features actually took, not just what was estimated.
• Use reference classes. Before estimating a new integration, look at the last 3 integrations your team built.
• Measure throughput. If your team consistently finishes 6 to 9 stories a week, a 60-story backlog is likely 7 to 10 weeks of work, before allowing for new scope.
• Watch delivery metrics. Lead time and other DORA metrics show how quickly work typically moves from start to production.

Formal estimating guidance outside software takes the same approach. The US Government Accountability Office’s Cost Estimating and Assessment Guide lays out steps that include defining scope, building a work breakdown structure, documenting ground rules and assumptions, collecting data, sensitivity and risk analysis, and updating estimates with actual results.

How to communicate uncertainty

Even a great estimate fails if it is misunderstood. These habits help:

• Separate estimates, targets and commitments. An estimate is a forecast. A target is what the business wants. A commitment is what the team agrees to deliver. Say which one you’re giving.
• Give ranges and confidence levels: “6 to 9 weeks, 80% confidence” instead of “7 weeks”.
• State your assumptions: “This assumes the payment provider’s sandbox is available and the design is approved by March 3.”
• Name the biggest risks and what you’re doing to reduce them.
• Offer scope trade-offs. “We can hit June 1 with features A and B; adding C pushes it to late June.”
• Re-forecast regularly. Share an updated range every sprint or every 2 weeks, so surprises arrive early.
• Use a cone of narrowing ranges. Explain that early estimates are wide and will narrow as discovery and early delivery remove unknowns.

For fixed-price client work, consider splitting the project into a paid discovery phase followed by an estimate for the build. It protects both sides. Our guide to custom software development costs explains how pricing models handle this risk.

Where to start: an estimation process for your next project

1. Clarify the goal and scope. Write down what problem the project solves and what is explicitly out of scope.
2. Rough-size with t-shirt sizes. Sort features into XS to XL to see the shape of the project.
3. Identify the biggest unknowns and run spikes on them.
4. Break the first release into user stories and estimate them with the team, using story points or simple counts.
5. Apply historical velocity or throughput to get a range of sprints or weeks.
6. Add explicit allowances for testing, release work and known risks, rather than hidden padding.
7. Present a range, confidence level and assumptions to stakeholders.
8. Track actuals and re-forecast every sprint. Hold a short review at the end to improve the next estimate.

If you are deciding how your team should work in the first place, compare Scrum vs Kanban and see our step-by-step guide to sprint planning.

Common mistakes to avoid

• Comparing story points across teams. Points are relative to each team and cannot be converted between them.
• Using velocity as a performance target. Teams under pressure simply inflate their points.
• Estimating alone. The people doing the work should estimate, because they see risks managers miss.
• Never re-estimating. An estimate made before discovery is stale within weeks.
• Ignoring support and maintenance work that steadily eats team capacity.
• Hiding padding. Make buffers visible and explain them, so they are not cut later without discussion.

Conclusion

Accurate software estimation comes from matching the method to what you know: t-shirt sizes early, story points or throughput once a team is delivering, and ranges with confidence levels whenever you talk to stakeholders. Break work into small pieces, lean on historical data, investigate unknowns with spikes and re-forecast often. Do that, and “how long will it take?” becomes a conversation about trade-offs instead of a source of conflict.

Sources

• The 2020 Scrum Guide — Product Backlog refinement and developers’ responsibility for sizing
• Agile Alliance Glossary: Planning Poker — how planning poker works and why spread in estimates matters
• US GAO: Cost Estimating and Assessment Guide (GAO-20-195G) — estimating steps including work breakdown, assumptions, data collection and risk analysis