Skip to content

WIP-limit overload detection

The board’s silent-WIP-creep alarm. Per-column WIP limits drive a three-band visual escalation, and moving a task into a column that would push it past its limit triggers a confirmation prompt.

Step 6 (Execute) of the hybrid PM flow. Companion to the Capacity preflight panel: capacity catches over-commitment at plan time; this catches WIP creep at execution time.

Three column states:

StateConditionVisual
Undercount < limitneutral chip {N}/{limit} — no special chrome
Atcount == limitsemantic-at-risk chip {N}/{limit} WIP + amber column header band
Overcount > limitsemantic-critical chip {N}/{limit} — over WIP limit + red column header band

Moving a task into a column that would push it past its limit:

This column is at its WIP limit (3/3). Move anyway? [ Cancel ] [ OK ]

Both drag-and-drop and the keyboard “Move to…” menu route through the same guard. Declining cancels; accepting proceeds with the existing status mutation.

  • Route: /projects/:projectId/board
  • Configure WIP limits in board settings (board column config panel)

Columns with wip_limit=null render the unchanged neutral count chip. The default board ships with WIP limits on IN_PROGRESS=5 and REVIEW=3; everything else is unlimited.

  • ADR-0039 — Board column config (where wip_limit lives)
  • Tom (engineer) — the over-limit chip says “this column is full.” Don’t pile on; finish what’s in flight first.
  • Maya — the at-limit / over-limit chips are your standup signal. If REVIEW is over-limit two days running, something downstream is blocked.