Weighted progress: why card counts mislead

Weighted progress: why card counts mislead is a short way to say that ten closed tasks out of twenty is not half a project. Cards differ in size and risk, so counting them treats a one-line copy fix the same as a database migration. On agent projects the distortion gets worse, because agents close small tasks quickly and the count races ahead while the hard work waits. Weighted progress fixes this by giving each task an explicit weight, fixing the total against a chosen baseline, and counting only work that is genuinely done. It also needs one discipline: when scope changes, the old baseline stops meaning anything and has to be reset. This article explains each part and when weighting is worth the effort. For the broader split between implementation and acceptance, see tracking built versus accepted.

What card counts hide

A card count answers how many items moved, which is rarely the question anyone is asking. Stakeholders want to know how much of the project is finished. Those two diverge whenever tasks differ in size, which is always.

Agent work makes the divergence systematic. Small, well-defined tasks are exactly what agents finish fastest, so they close first. Large, ambiguous or risky tasks need more human involvement and close last. A project can therefore show 70 of 100 cards closed while most of the real work remains, and the final stretch takes longer than everything before it.

Counts also reward splitting. Break one large task into eight small ones and the count looks better without any change in the work. Teams rarely do this on purpose, but agents that create follow-up tasks freely can inflate both the total and the closed figure. Neither tells you about the work that matters most.

Explicit weights against a baseline

A weight is a number you assign to each task that reflects its share of the whole: effort, risk, or a mix you choose. Keep the scale coarse. Weights of 1, 2, 3, 5 and 8 are enough; debating whether a task is a 4 or a 5 is wasted time.

Assign weights explicitly, in writing, before work starts. A weight chosen after the task is done tends to reflect how it went, which defeats the purpose.

Then fix a baseline: the set of tasks and their weights that define the project at a point in time. Progress is the weight of finished tasks divided by the total weight in that baseline. For example, a baseline of 30 tasks totalling 120 weight points, with 48 points finished, is 40 percent done regardless of how many cards closed.

Tasks without a weight should not be silently counted as zero or as an average. Either weight them or report that progress is unavailable until they are. A partial figure presented as complete is worse than no figure.

Why only finished work earns weight

It is tempting to give partial credit: half the weight for work in review, a quarter for work in progress. Resist it. Partial credit rewards starting, and agents make starting cheap, so the figure will rise with activity rather than with outcomes.

Work in review is a good example. An agent change waiting for review may be accepted as is, need a small fix, or be rejected entirely. Giving it half credit assumes an average outcome you have not observed. Worse, when review is the bottleneck, partial credit hides the bottleneck by turning a growing queue into apparent progress.

Count weight only when a task reaches your done state, and make sure done means something: checked and accepted, not merely closed by whoever built it. Then show work in review as a separate figure. Seeing 48 points done and 30 points waiting for review tells you exactly where to spend the week. Folding them together would hide it.

When scope changes, the baseline expires

A baseline is a snapshot of what the project was supposed to contain. When you add a feature, drop one, or discover that a task is twice as large as weighted, the old baseline no longer describes the project. Progress measured against it is misleading in either direction: adding scope without rebasing makes progress look faster than it is, and dropping scope makes it look slower.

The honest response is to declare a new baseline, with a date, and to restart the progress line from there. Keep the old figures for history, but do not draw them on the same chart as if the denominator never changed.

Agent projects change scope often, partly because agents surface work nobody planned. Treat each batch of accepted discovered tasks as a scope change: weight them, add them to a new baseline, and note why. If scope changes every few days, weighted progress may not be worth maintaining, and a simple built versus accepted read is more honest.

QUESTIONS

Why is counting closed tickets a bad measure of progress?

Tickets differ in size and risk, so counting them treats small and large work the same. Small tasks close first, especially when agents do the implementation, so the count runs ahead of real progress. Splitting tasks also inflates the count without any change in the work remaining.

Should in-progress or in-review work get partial credit?

No. Partial credit rewards starting work, which is cheap with agents, and assumes outcomes you have not observed. Count weight only when work is accepted, and show work in review as a separate figure so a growing review queue stays visible instead of looking like progress.

When should I reset a progress baseline?

Whenever scope changes materially: a feature added or dropped, or a task found to be much larger than weighted. Declare a new dated baseline and restart the progress line. Comparing against the old one makes progress look faster or slower than it really is.

RELATED GUIDES

• How to read project progress in BRAIN FLUID Build

RELATED HARNESS PAGES

• Tracking AI agent progress: built vs accepted Tracking AI agent progress: built vs accepted. Keep implementation, current evidence and acceptance as separate numbers and read them weekly.
• Milestones for AI-assisted projects Milestones for AI-assisted projects: define them by accepted outcomes and passing checks, not by cards closed, and keep release a separate decision.
• Managing tasks an AI agent discovers mid-work Managing tasks an AI agent discovers mid-work: record each as a new linked task, mark it required or optional and never widen the current task silently.
• WIP limits for AI agent work WIP limits for AI agent work: why agents make starting too easy, and why the limit belongs on review capacity rather than on running sessions.