Story points are pointless, measure queues

Original Article ↗ Hacker News Discussion ↗

Many engineers argue that “story points” in agile software development have drifted from a loose proxy for effort into a misused, pseudo-precise metric that managers treat as time and productivity. Commenters debate whether points can work if kept strictly as a team-internal tool for relative complexity and forecasting, or whether teams should instead break work into small, similarly sized tasks and reason in terms of queues, throughput, and variability. Across viewpoints, there is broad agreement that overloading any metric for performance comparisons and deadlines creates perverse incentives and that the real value lies in collaborative planning, clear priorities, and controlling work-in-progress rather than in the numbers themselves.

Scope of the debate

  • Thread centers on whether “story points” are useful and whether queue-based thinking is a better alternative for planning and forecasting.
  • Many argue the core problem is not the unit itself, but how organizations use it (commitments, performance metrics, inter‑team comparison).

Critiques of story points

  • Often become a de‑facto time unit despite claims they represent “complexity” or “uncertainty.”
  • Numerical form invites arithmetic (velocity, burn‑down charts) and managerial misuse: turning estimates into promises, productivity scores, and cross‑team comparisons.
  • Easily gamed: inflate points, hyper‑split stories, or redefine baselines.
  • Relative “complexity” is seen as fuzzy; large tasks collapse risk, unknowns, and effort into a single scalar.
  • Many report big variance in velocity and little predictive power, especially with changing teams, domains, or ops load.

Defenses of story points

  • Advocates say points are relative size/complexity, not time, and are team‑local.
  • Main value is the conversation: surfacing hidden assumptions, disagreements, unknowns, and the need to break down oversized work.
  • When protected from misuse (no performance scoring, no cross‑team normalization), teams report decent forecasting of sprint capacity and better shared understanding.
  • Some use Fibonacci or small caps on story size to force decomposition and highlight uncertainty.

Queues, tasks, and alternatives

  • Article’s queue‑based approach: break work into small, roughly uniform tasks; track task throughput and queue length instead of summed points.
  • Supporters like its alignment with queuing theory (full queues amplify variability) and focus on limiting WIP and flow, not abstract scores.
  • Critics claim tasks still vary in size and complexity; breaking everything into “1‑point” atoms can create busywork and artificial micro‑tasks.
  • Other suggested approaches:
    • Time ranges (orders of magnitude: day/week/month), sometimes adjusted via empirical data.
    • Kanban with WIP limits and minimal forecasting.
    • WSJF / cost‑of‑delay for prioritization.
    • “Just estimate in days” or even “no estimates” for some teams.

Management, culture, and misuse

  • Recurrent theme: story points become harmful when upper management uses them for control, comparisons, or rigid deadlines.
  • Several argue any metric will be abused under bad incentives; the real issue is trust, statistical literacy, and realistic expectations about uncertainty.
  • Others suggest that with a good culture and leadership, almost any lightweight estimation scheme can work; without that, none will.