Simple work estimation without story points
Story points were supposed to make estimation easier. Instead, many teams spend more time debating whether a task is a 5 or an 8 than actually planning the work. The Fibonacci sequence becomes a recurring argument. Velocity charts become a reporting exercise that nobody trusts. And at the end of the sprint, the team still missed the forecast.
The problem isn't estimation itself. The problem is that story points add abstraction where teams need clarity. There are lighter approaches to work estimation without story points that give you useful sizing information without the ceremony.
TL;DR: Replace story points with T-shirt sizes as a custom field, compare time estimates against actuals using built-in tracking and count throughput to forecast capacity. No Fibonacci debates, no velocity theatre.
What is work estimation without story points?
Work estimation without story points is any method of sizing or forecasting work that avoids abstract point scales. Instead of assigning a Fibonacci number to each task, teams use relative sizes (S, M, L, XL), time-based ranges, throughput counts or a combination of all three. The goal is the same: understand how much work you can take on and when it might be done. The difference is that these methods stay closer to how people actually think about effort.
Story points were introduced in Extreme Programming to separate effort from duration. In practice, points became a proxy for hours anyway. "That's a 5-pointer" eventually just means "about two days" in most teams. Same information, extra abstraction.
Why do story points cause more confusion than clarity?
Story points fail for a few practical reasons:
- Teams argue about calibration. Is a 3-point task the same on Team A as on Team B? What about when a new member joins? Calibration meetings eat time without improving accuracy.
- Points become a performance metric. Managers start comparing velocity across teams, which was never the intent. Teams inflate points to look productive.
- The abstraction doesn't help planning. When a stakeholder asks "when will this be done?" you can't answer in story points. You translate back to time anyway.
- Estimation meetings drag on. Planning poker is fun once. By sprint 20, it's a ritual that produces the same result as a quick team conversation.
None of this means you should skip estimation entirely. You still need a rough sense of how big things are. You just don't need a point scale to get there.
How does work estimation without story points actually work?
Three practical methods replace story points for most teams. You can use one or combine them depending on what decisions you need to make.
Method 1: T-shirt sizes as a custom field
T-shirt sizing (S, M, L, XL) gives you relative sizing without the false precision of numbered scales. A task is either small, medium, large or extra-large. That's four options. No one argues about whether something is a 5 or an 8 when the choices are M or L.
The key difference from story points: T-shirt sizes are explicitly imprecise. An L is not exactly twice an M. It's just bigger. Nobody treats them as exact commitments, which makes them more honest.
In Eigenfocus, you set this up as a single-select custom field called "Effort" with options S, M, L and XL. Assign a color to each option (green for S, yellow for M, orange for L, red for XL) and the size shows as a colored badge on every card. You can scan the board and see how much heavy work is queued up. For more on setting up fields like this, see the guide on five custom fields every project manager should set up first.
Method 2: Time-based estimates vs actuals
If your team tracks time, you already have the data for a better estimation method. Record an hour estimate per issue before work starts. After the work is done, compare the estimate to the actual tracked hours. Over time, you build a dataset that tells you how accurate your guesses are and where they consistently miss.
This isn't about micromanaging hours. It's about building a feedback loop. If your backend tasks consistently take 40% longer than estimated, you adjust future estimates. The combination of estimates plus actuals gives you something story points never do: a way to measure whether your estimation is improving.
For a detailed walkthrough of building estimation baselines from tracked time, see how to use time tracking data for project estimation.
Method 3: Throughput counting
Throughput is the simplest forecasting method. Count how many issues your team completes per week. That's your throughput. If you completed 12 issues last week, 14 the week before and 10 before that, your average is about 12 issues per week.
Now look at the backlog. If there are 36 issues left, you're roughly three weeks out. No estimation session required. No points, no hours, no debates. Just counting completed work and dividing.
Throughput works best when your issues are roughly similar in size. If your backlog mixes tiny bug fixes with multi-week features, the numbers lose meaning. That's where T-shirt sizing helps: filter your throughput by size category. "We complete about 8 medium issues per week" is a more reliable forecast than "we complete 12 issues per week" when those issues range from 30 minutes to 30 hours.
Worked example: estimating a product redesign without story points
A team is planning a dashboard redesign. The project has about 30 issues across design, frontend and backend work. Here's how they estimate using all three methods together.
Step 1: T-shirt size every issue.
During a 20-minute planning session, the team walks through the backlog and assigns sizes:
| Issue | Effort |
|---|---|
| Redesign navigation layout | L |
| Update chart components | M |
| New filter sidebar | L |
| Fix date picker styles | S |
| API endpoint for dashboard stats | M |
| Migrate old widget data | XL |
| Write component tests | M |
| Update API documentation | S |
| Responsive layout adjustments | M |
| Performance audit | L |
No debates about whether the filter sidebar is a 5 or an 8. It's clearly bigger than the date picker fix and smaller than the data migration. L feels right. The team moves on.
Step 2: Add hour estimates for the larger items.
For L and XL issues, the team adds a rough hour estimate using a number custom field:
- Redesign navigation layout: ~16h
- New filter sidebar: ~14h
- Migrate old widget data: ~24h
- Performance audit: ~12h
They skip hour estimates for S and M items. Those are predictable enough from past experience.
Step 3: Check throughput from the last project.
The team looks at their completed project from last quarter. Over 6 weeks, they completed 42 issues. That's 7 issues per week on average. Broken down by size: about 3 S items, 3 M items and 1 L/XL item per week.
Step 4: Build the forecast.
The current backlog has 4 S items, 5 M items and 4 L/XL items (with more issues expected to be added for testing and polish). Based on throughput:
- S items: ~1.5 weeks
- M items: ~2 weeks
- L/XL items: ~4 weeks
Since these run in parallel across team members, the project will likely take 5-6 weeks. The hour estimates for the big items confirm this: 66 estimated hours for L/XL work, spread across two developers working roughly 30 productive hours each per week, is about 2-3 weeks for that slice alone.
The total estimation session took 25 minutes. Compare that to a planning poker session that would have burned an hour debating point values and still produced a similar timeline.
See Eigenfocus pricing and editions to find a plan that fits your team.
How to set up work estimation without story points in Eigenfocus
Setting up these three methods in Eigenfocus takes about five minutes per project.
For T-shirt sizing: Create a single-select custom field called "Effort" with options S, M, L and XL. Assign colors. The field appears as a badge on board cards, grid cells and list rows. You can scan effort distribution at a glance. For details on configuring field visibility per view, see the guide on labels, custom fields and custom statuses.
For time estimates vs actuals: Add a number custom field called "Estimated hours." Team members log time using the built-in timer or manual entry as they work. At the end of the project, compare the estimate field against the time report. This feedback loop sharpens future estimates with every completed project.
For throughput: No special setup needed. Count completed issues per week from your board's done column. If you want historical data, time reports and issue completion dates give you what you need.
Custom fields in Eigenfocus are per-project. Each project can have its own effort scale if needed. A design project might use S/M/L. An engineering project might add XL and XXL. The fields are yours to define.
When does work estimation without story points fall short?
No estimation method is perfect. These lighter approaches have trade-offs:
- T-shirt sizes don't aggregate well. You can't add up "3 mediums and 2 larges" into a meaningful total the way you can with points. But that precision was largely illusory with story points too.
- Time estimates require tracking discipline. If the team doesn't log hours consistently, your estimate-vs-actual comparison breaks down. The data only works if people actually record their time.
- Throughput assumes stable team capacity. If someone goes on leave or a new person joins, your throughput numbers shift. Recalibrate after any team change.
These are manageable limitations. The methods are faster to apply, easier to understand and don't require a ceremony to maintain.
Common questions about work estimation without story points
Can I use T-shirt sizes and time estimates together?
Yes, and that combination works well. Use T-shirt sizes for quick relative sizing during planning. Add hour estimates only for L and XL items where the range of possible effort is wide enough that a rough number helps. Skip hour estimates for S and M items since they're predictable enough from past experience. The two methods complement each other without creating double the overhead.
How do I convince my team to drop story points?
Start by running both methods in parallel for one or two sprints. Add T-shirt sizes alongside your existing story points. After a few weeks, compare which method produced more useful forecasts with less meeting time. Let the results make the argument.
Does throughput counting work for teams with mixed issue sizes?
Throughput is most reliable when issues are roughly similar in size. If your backlog has a wide range, filter throughput by T-shirt size. Track how many S, M and L items you complete per week separately. "We finish 4 M-sized issues per week" is more useful than "12 issues per week" when half are trivial fixes.
What if stakeholders expect story points or velocity charts?
Explain what you're replacing them with. Throughput charts (issues completed per week) give stakeholders the same visibility as velocity charts without the abstraction layer. Time estimate vs actual reports show whether the team is getting better at forecasting. Most stakeholders care about "when will it be done?" not "how many points did you burn?" Give them the answer in a format they understand: dates, hours, issue counts.
Are T-shirt sizes just story points with different labels?
Not quite. Story points carry assumptions about velocity calculation, sprint commitment and cross-team comparison. T-shirt sizes are deliberately simpler. They're relative sizes with no mathematical operations expected. You don't sum T-shirt sizes across a sprint, you don't chart them over time and you don't compare across teams. That lack of ceremony is the point.
Start estimating without story points
Pick one method and try it on your next project. T-shirt sizing takes five minutes to set up as a custom field. Time tracking is already built in. Throughput counting just needs a weekly glance at your done column.
Once you have estimates in place, learn why finishing work matters more than starting new work to keep your throughput numbers honest.
See how teams use Eigenfocus for software development or learn more about project management workflows.