How should a product team limit work in progress?

A product team may have a long list of valuable requests and several people eager to start them. When each request becomes active, review, testing and decisions can become queues. The team needs a way to say how much it can genuinely progress at once.

Why too much active work slows decisions

Work in progress means items that have crossed the team’s commitment point and are still unfinished. A draft idea in a discovery list is different from a feature being built or a defect being investigated. Count work that consumes shared attention, including blocked items. A board can show where work waits, but the number of cards alone does not tell the team whether it has the skills or access needed to finish them. The useful question is which active items are competing for the same reviewers, environments and decisions.

Common ways teams handle competing requests

Teams often rely on priority labels, an ordered backlog or a planning meeting. These methods help choose what matters, but they do not by themselves prevent too many items entering delivery. A fixed sprint forecast can provide a near-term boundary when the team works in Scrum. Kanban systems make permissible work explicit through work-in-progress limits. Either approach needs a policy for urgent work and a visible account of what gets displaced when priorities change.

Agree a limit and a replenishment rule

Map the stages where work accumulates, then agree a small initial limit for active items at each constrained stage or for the team as a whole. When a stage is full, help finish, test or unblock current work before pulling the next item. Product chooses which outcome to pursue next; Engineering explains dependency and technical risk. Keep a separate, explicit path for genuine incidents, but record their effect on planned work. Review the limit after observing wait time, unfinished work and quality. A limit is a learning device, not a target to keep every person busy.

Check the policy in real conditions

Define when an item enters and leaves active work, who can authorise an exception, and what happens to paused work. If one specialist serves many teams, a local limit may simply move the queue elsewhere; coordinate at the shared constraint. Do not game the limit by splitting one unresolved feature into many cards or moving blocked work off the board. If priorities change daily, investigate demand and decision rights as well as the number on the board.

Example

Hypothetically, a subscriptions team has six features under development and only one person able to approve changes to billing rules. It agrees to start no new billing change while two await that approval. Product orders the next requests, while Engineering helps finish tests and resolves the review queue. An urgent billing defect enters through an agreed exception path; the team records which planned item pauses and reviews the interruption at its next planning session.

FAQs

• Should the limit equal the number of engineers?

  No. Work passes through shared review, testing and decisions. Start from observed flow and adjust the limit where work waits.

• Does blocked work count?

  Yes. Keep it visible so the team can remove the blocker or consciously pause and replace the item.

• What if an incident breaches the limit?

  Use an explicit urgent-work policy and record what it displaces. Repeated exceptions suggest the plan or service capacity needs changing.