Column status distribution

Column status distribution is the share of work items sitting in each status column of a board at a given moment, expressed as a percentage of the total. If a board holds 40 items and 18 of them are in review, then the in-review column accounts for 45 per cent of the board. Doing this for every column gives you a profile of where work is concentrated right now.

The metric matters because a board is a queue, not a snapshot of effort. When one column holds a large and growing share of the work, items are arriving faster than they leave. That column is the constraint. A healthy board has work spread across stages in a way that matches how long each stage actually takes, and the distribution stays roughly stable from week to week.

Column status distribution is most useful read alongside flow over time. A single reading tells you where work sits today. A trend tells you whether a stage is filling up, draining, or holding steady. When the in-review or blocked share climbs week after week, that is a cycle time problem forming before it shows up in delivery dates.

To calculate column status distribution, count the active items in each column, then divide each count by the total number of active items on the board. The result is a set of percentages that sum to 100. The inputs below are all you need.

1. 1

   Items in each column

   The number of active work items currently sitting in a given status, counted at a consistent point in the day. Use the same time each day so daily readings are comparable.

2. 2

   Total active items on the board

   The sum of items across every column, excluding archived and closed work. This is the denominator that turns raw counts into shares.

3. 3

   Column definitions

   A clear, agreed meaning for each status. If different people interpret in review or blocked differently, the distribution becomes noise. Lock the definitions before you trust the numbers.

4. 4

   Sampling cadence

   How often you snapshot the board. Daily snapshots let you see a column filling up within a sprint. Weekly snapshots smooth out noise but react more slowly to a forming bottleneck.

A worked example. A board has 8 items in backlog, 6 in progress, 10 in review, 2 blocked, and 4 done, for 30 active items. The distribution is 27 per cent backlog, 20 per cent in progress, 33 per cent in review, 7 per cent blocked, and 13 per cent done. Review holds the largest share, which suggests reviewers are the constraint, not the people writing the work.

A metric tree turns column status distribution from a chart you glance at into a diagnostic you can act on. The headline metric is the shape of the board. The branches are the columns, and beneath each column sit the operational causes that make that column grow or shrink.

The first level splits the board into its columns. Each column then decomposes into arrival and departure. Items in a column grow when arrivals outpace departures, so the leaves describe what feeds the column and what drains it. The review column, for example, grows when more work is finished and submitted, and drains when reviewers have capacity and clear standards.

This structure lets you trace a bulge to its cause. If the blocked column is climbing, the tree points you to dependency waits and external approvals rather than to the team writing the work. Each leaf has a different owner and a different fix, which is exactly the information a status chart alone cannot give you.

There is no single correct distribution because the right shape depends on how long each stage takes. A useful rule is that a column should not hold a much larger share of items than its share of total cycle time. The ranges below describe what healthy and unhealthy distributions tend to look like across stages.

The most telling benchmark is stability, not a single target. A board whose distribution holds steady from week to week is in flow. A board where one column climbs by five to ten percentage points each week is heading for a missed deadline, and the column that is climbing tells you which team needs to act.

Improving column status distribution means moving work out of the column that holds the largest disproportionate share, then keeping the shape stable. The fix is almost always specific to the column that is bulging, so start by finding the constraint rather than spreading effort evenly.

The metric tree approach starts by identifying which column has the largest gap between its share of items and its share of cycle time, then drilling into that branch to find the binding constraint. If review holds a third of the board but should take a fifth of the time, the leaves under the review branch tell you whether the cause is reviewer capacity, turnaround, or submission timing.

KPI Tree models this by connecting each column to the team that controls its arrivals and departures. The team that writes work owns the in-progress branch. Reviewers own the review branch. The lead who clears dependencies owns the blocked branch. When the board shape moves, the change is pushed to the accountable owner for that column, so the right person sees the bulge forming and acts before it becomes a missed date.

1. 1

   Counting closed work in the total

   Leaving done and archived items in the denominator inflates the done column and shrinks every other share. Once an item ships and leaves the active board, drop it from the count.

2. 2

   Reading one snapshot in isolation

   A single reading shows where work sits but not whether a column is filling or draining. The signal lives in the trend, so track the distribution over time, not just today.

3. 3

   Letting column meanings drift

   If in review means code review to one person and design review to another, the distribution is noise. Agree what each status means and hold the definitions steady.

4. 4

   Treating every column the same

   A 30 per cent backlog is fine. A 30 per cent blocked column is a crisis. Judge each share against what that stage should hold, not against a single board-wide target.

5. 5

   Acting on share without checking item size

   A column with three huge items can hold more work than a column with eight small ones. Pair item counts with item size before deciding which column is really the constraint.