The reading room · Digna Legi
Story Points are Pointless, Measure Queues
/100
80–100: high value. 70–79: worth the time. Below 70: below the usual publication threshold.
Evidence-reviewed score based on available publisher text. Evidence is sampled with gaps, so the score reflects the visible argument and cannot verify the full article's completeness, pacing, or unsupported sections.
Scores reflect one reader’s profile, not an objective quality rating. Best is a separate personal selection.
How scoring works →This brief · about 3 min with detail
Why read this
Story points blur effort, uncertainty, complexity, and time, then get converted into deadlines despite pretending not to be temporal.
AI brief · Checked against source text
The main idea
The author argues that story points fail because they mix complexity, uncertainty, effort, and time while pretending to be team-specific and non-temporal, then inevitably get summed, compared, and converted into deadlines. The proposed replacement is to break work into concrete tasks as a team, remove or document uncertainties, track queue size and average task rate, and update the task list as reality changes.
Some background helpful. Basic familiarity with software teams, agile planning, backlogs, and estimation meetings.
Go a little deeper
The metric invites its own misuse
Story points are introduced as relative team measures, but their numeric form makes them easy to add, average, compare, and target. That creates a predictable failure mode: once management sees velocity reports, the distinction between one team's scale and another's collapses. The author treats this not as accidental misuse but as a design flaw, because the metric constantly needs contextual warnings to prevent bad decisions.
Planning should create durable artifacts
The author does not dismiss planning conversations; he objects to wasting them on a number that preserves almost none of the reasoning. His alternative keeps the valuable part: the team talks through implementation, tests, dependencies, knowledge gaps, architecture, validation, and open questions. The output becomes a task map that future team members can inspect, revise, and use for projection.
Uncertainty is work, not a rounding factor
Instead of hiding uncertainty inside a larger Fibonacci number, the proposed process identifies unknowns explicitly and either resolves them during planning or creates exploratory work. This changes the economics of estimation: the team spends effort acquiring information where it reduces future variance. Once visible uncertainties are removed, job size becomes less mystical because it is grounded in known tasks rather than guessed complexity.
Queues expose trouble earlier than velocity
Velocity, cycle time, and average task rate describe what already happened; queue size shows accumulating work before the damage fully appears. If a feature grows from 250 tasks to 500, the organization can reconsider scope, split delivery, or stop work before downstream metrics sag. The same logic applies to support work: uncontrolled incoming issues can consume buffer and congest feature development unless quality and response mechanisms reduce that flow.
A case from the article
The home inspection miss
Before buying a house, the author received inspection notes suggesting that specialists examine plumbing, HVAC, and electrical issues. He did not investigate those uncertainties before proceeding, assuming the house mainly needed cosmetic work. After moving in, each unresolved unknown became expensive enough to require a home equity loan. The example illustrates why flagged uncertainty should trigger exploration before commitment, not be treated as harmless background risk.
How the case is made
The case is made through practitioner observation, agile-process critique, cited definitions, named quotations, and queueing-theory concepts such as capacity utilization and Little's Law.
Where the idea has limits
The author allows that small, stable teams may succeed with time estimates or points; the argument targets larger, changing organizations where estimates age, queues interact, and management consumes metrics.
A question to take away · from Digna Legi
Which planning conversations in your organization produce reusable knowledge, and which merely produce numbers that later become pressure?
What the original adds
The original gives a longer attack on velocity arithmetic, several alternative estimation methods, and a fuller queueing discussion, including support work as an uncontrolled arrival stream.
About this brief
AI-written, then separately checked for source support, useful detail and clarity. The author’s claims and our editorial question are kept separate. The original remains the author’s work. How we select and summarise →
How was this brief?
Rate this summary, separately from the author’s article.
Optional. Saved in this browser; shared only if you allow analytics.
How was the original article?
Rate the author’s original after reading it.
Optional. Saved in this browser; shared only if you allow analytics.
Digna legi. Worth reading.