Story points are broken because they hide the real driver of delivery: how long a piece of work actually takes. The alternative is to count tasks and track cycle time, which lets you see bottlenecks and predict release dates with real numbers.

What "story points" try to measure and why they collapse

Teams adopt story points to avoid estimating in hours. The idea is to assign a relative size (1, 2, 3, 5…) based on perceived effort, risk and complexity. In practice the three dimensions get mixed, so a 5-point story might be a quick UI tweak or a month-long backend refactor. Research on estimation bias shows that relative scales still suffer from the planning fallacy – people consistently underestimate the time needed for novel work. When the same team re-estimates a story after a sprint, the point value rarely changes, even though the actual hours do. The result is a velocity number that tells you little about future capacity.

Counting tasks as a concrete alternative

Instead of abstract points, break a feature into discrete tasks that can be completed in a day or less. Each task becomes a unit of work you can count. For example, a login feature might be split into: 1. Design the UI mockup 2. Implement the front-end form 3. Write the authentication API 4. Add unit tests 5. Deploy to staging If the team completes five tasks per sprint, the throughput is directly observable. When a sprint ends with three tasks done, you know the capacity dropped and can investigate why – perhaps a blocker or a skill gap. Counting tasks also aligns with the "Definition of Ready" used in many Scrum teams: a task is ready when it can be started without further clarification.

Measuring cycle time to predict delivery

Cycle time is the elapsed days from when a task moves into "In Progress" until it reaches "Done". Record the start and finish dates in your board, then calculate the average over the last 10 tasks. Suppose the average is 2.4 days. For a backlog of 12 tasks, the expected completion is roughly 12 × 2.4 = 28.8 days, or about six weeks. This method is transparent: anyone can verify the dates, and the forecast updates automatically as new tasks finish. It also surfaces waste – if a task repeatedly spikes to 7 days, you have a concrete case for process improvement.

Cycle-time data can be visualised with a cumulative flow diagram, a standard agile chart that shows work-in-progress limits and bottlenecks without any point system.

When t-shirt sizing still has a role

T-shirt sizing (XS-S-M-L-XL) is a quick way to get a shared sense of scale during backlog grooming. It works as a conversation starter, not as a metric. A common misconception is that a "Large" item will always take twice as long as a "Medium" one. In reality the size labels merely indicate "more work than the previous size" without a fixed ratio. Use sizing to cluster items, then apply task counting or cycle-time tracking to each cluster for real numbers.

If you need a rough filter before detailed breakdown, label items "M" or "L" and then immediately split them into tasks as described above.

How to transition without losing momentum

1. Pick a pilot epic and split every story into tasks of no more than one day of effort. 2. Record start and finish dates in your existing board – most tools support custom fields for cycle time. 3. After two sprints, calculate average cycle time and compare it to the historic velocity derived from story points. 4. Communicate the new numbers in the sprint review; show the team how the forecast became more accurate. 5. Retire story points from the board once the new metrics are trusted.

The transition costs a few hours of grooming time, but the payoff is measurable: you can now answer "when will we ship?" with a date range rather than an abstract point total.

For a deeper look at breaking down work, see the guide on Break Down a Feature Ticket with Engineering Planning.

Limitations of the alternatives

Counting tasks assumes tasks are roughly equal in size; if a team creates very large tasks, the count loses meaning. Cycle time requires a stable definition of "Done" – if quality gates shift, the metric skews. Both methods need disciplined data entry; otherwise the numbers become as noisy as story points. In very small teams, the overhead of tracking each task may outweigh the benefit, and a simple weekly capacity estimate can suffice.

When a lightweight approach is enough, the article Developer Productivity: Stop Overplanning, Start Shipping offers a minimal-process checklist.