Action item velocity

Action item velocity is the rate at which a team completes action items over a defined period, such as a week or a sprint. If a team closes 24 items over four weeks, its velocity is six items per week. The metric translates raw output into a steady rhythm you can plan against and compare from one period to the next.

Velocity matters because a list of open items tells you nothing about whether they are getting done. Two teams can each hold 30 open items, yet one clears 10 a week while the other clears two. The first will be empty in three weeks; the second is heading for a backlog crisis. Velocity is the number that separates a moving team from a stuck one.

Velocity should be read together with how many new items arrive. A team completing eight items a week looks healthy until you see 12 new ones land each week. The gap between intake and completion is what grows or shrinks the backlog, so velocity is most useful when you watch it next to creation rate rather than on its own.

Count the action items completed in a window, then divide by the number of periods in that window. A team that closed 30 items over the last six weeks has a velocity of five items per week. Use a window of several periods rather than a single one, because a single week is noisy and a four to six week average is far more stable.

The main decision is whether to count items equally or weight them by size. Counting each item as one is simple and works when items are roughly comparable. If your items range from a five-minute fix to a two-week project, weight them by an effort estimate so a burst of trivial items does not look like a productivity surge.

Keep the definition of done fixed. If an item only counts when it is verified rather than merely marked complete, apply that rule every period. A shifting finish line makes the trend meaningless.

1. 1

   Choose a measurement window

   Pick a rolling window of four to six periods so the number is stable. A single period swings too much to plan against.

2. 2

   Count completed items

   Count every action item that reached the done state within the window. Optionally weight each item by an effort estimate if item sizes vary widely.

3. 3

   Divide by the number of periods

   Divide the completed count by the number of periods in the window to get the average items completed per period.

4. 4

   Compare against creation rate

   Place velocity next to how many new items arrived in the same window. The difference tells you whether the backlog is growing or shrinking.

Velocity is an outcome of how much work arrives, how much capacity the team has, and how much friction sits between starting an item and finishing it. Decomposing it shows which of those three levers is actually holding the number back.

Raw velocity numbers do not transfer between teams, because item sizes and team sizes differ. The useful benchmark is the relationship between velocity and intake. The ranges below frame that ratio so you can read whether a backlog is shrinking, holding, or growing.

The fastest way to raise velocity is usually to remove friction rather than to push the team harder. Blocked items, oversized items, and constant reprioritisation drain throughput more than any lack of effort. Address the flow first, then the capacity.

1. 1

   Reading a single period

   One week of velocity is noise. A holiday, a launch, or a single large item distorts it. Always read a rolling multi-period average.

2. 2

   Ignoring intake

   High velocity feels like progress, but if new work arrives even faster the backlog still grows. Velocity is only meaningful next to creation rate.

3. 3

   Treating velocity as a target to maximise

   Pushing velocity as a goal invites gaming through trivial items and corner-cutting. It is a planning measure, not a performance scoreboard.