Roadmap progress tracking

Roadmap progress tracking is the measure of how much of a committed product roadmap has been delivered against plan over a given period, expressed as a percentage of completed scope. If a quarter has 20 planned roadmap items and 14 are shipped and accepted, roadmap progress is 70 per cent. The number gives leadership and delivery teams one comparable figure they can read at a glance.

It matters because a roadmap is a set of promises, and promises drift. Without a tracked number, teams substitute optimism for evidence and discover slippage only at the deadline. A progress figure measured weekly shows the trajectory early, while there is still time to reprioritise, add help, or renegotiate scope. It also separates real delivery from busywork, because only completed and accepted items count.

Roadmap progress is the share of planned items that have actually been delivered. Decide on the unit first. Counting items is simplest, but items vary wildly in size, so many teams weight by estimated effort instead, which gives a fairer picture when a roadmap mixes small fixes with large bets.

Fix the period and the scope baseline at the start, then hold them. If new items are added mid-quarter, track them separately rather than quietly expanding the denominator, otherwise progress can stall even as the team ships steadily. The cleanest practice is to record the original commitment and the changes to it as two distinct numbers.

1. 1

   Count completed roadmap items

   Items shipped and accepted in the period. Exclude anything still in review, blocked, or hidden behind a flag.

2. 2

   Count total planned roadmap items

   The scope committed for the period at the baseline. Hold this fixed and log mid-period additions separately.

3. 3

   Divide and convert to a percentage

   Completed divided by total planned, multiplied by 100. Weight by effort estimate instead of raw count when item sizes differ a lot.

A single progress percentage tells you the score but not the cause. When the number stalls, the useful question is which part of the delivery pipeline is leaking. A metric tree decomposes roadmap progress into the drivers beneath it, so a flat week traces to a specific bottleneck rather than a general sense that things are slow.

The drivers are concrete: how much scope is committed, how fast items move through the pipeline, how often work is blocked, and how much unplanned work crowds out the roadmap. Each of these is itself made of smaller, ownable causes.

There is no universal target, because a healthy figure depends on how a team plans. Teams that commit cautiously and pad estimates will post high completion rates that mean little. Teams that commit ambitiously will run lower but learn more. As a rule of thumb, mid-period progress that tracks close to the share of the period elapsed is healthy.

Improving the number is rarely about working harder. It is about committing to scope the team can realistically deliver and removing the friction that stalls items once they are underway. Address the drivers that show up in the tree, starting with the largest leak.

1. 1

   Counting in-progress work as done

   Items in review or behind a flag are not delivered. Counting them inflates progress and hides slippage until the deadline.

2. 2

   Letting the denominator drift

   Quietly adding mid-period items to total planned scope makes a steady team look stalled. Track additions separately.

3. 3

   Treating all items as equal

   A one-line fix and a quarter-long bet count the same under a raw item count. Weight by effort when sizes vary.

4. 4

   Reading the number without the drivers

   A flat percentage does not say why. Without decomposition the team debates causes instead of acting on the one that moved.