WIP Limits And Active Work
WIP limits cap the number of tasks you keep in progress at the same time. “In progress” means work that has started and has not finished, not tasks that are merely waiting for a meeting. In personal planning, this often shows up as too many open tabs: drafting, researching, and rewriting all at once. In team workflows, it shows up as multiple tickets assigned but not moving to completion.
A WIP limit changes behavior through constraints. When the cap is reached, you must either finish something or stop starting new work. That forces a choice between starting another task and reducing the age of work already in flight. If you track cycle time, you usually see older tasks stop accumulating, even when total effort stays the same.
For a concrete example, imagine you have 12 tasks in a backlog and you can only keep 3 active. When a fourth task is ready to start, you pause and finish one of the 3 first. The “pause” is not wasted time; it is the mechanism that prevents work from spreading thin.
Common Mistakes And Dependencies
People often treat WIP limits like a productivity slogan instead of a system rule. The most common failure mode is setting a limit but still letting tasks “count” as active only on paper. If you move a task to “in progress” and then keep it there while waiting on someone else, it still consumes WIP. Another failure mode is using WIP limits only for new work while ignoring stalled work already in motion.
WIP limits also depend on how work flows through states. If your workflow has vague statuses such as “doing” or “working on it,” you lose the ability to enforce the cap. A task that is “doing” for two weeks because requirements are unclear is still active work, even if progress feels invisible. Tools like Jira, Linear, or Trello can enforce limits with board columns and swimlanes, but the data quality depends on how consistently you update statuses.
Supporting technologies matter because they shape what you can measure. Cycle time and throughput require timestamps for when work enters and leaves a defined state. Many teams track “created” and “resolved,” but those timestamps can be misleading if tasks bounce between states. In my own experience reviewing workflow exports (I used a Jira Cloud board export in 2024-11), the biggest measurement gaps came from inconsistent transitions rather than missing features.
Finally, WIP limits interact with capacity. If you have a single person and a single bottleneck, a low WIP limit can reduce waiting. If you have multiple specialists and handoffs, a low WIP limit can also starve downstream steps. The dependency is not theoretical; it shows up as work sitting in “ready for review” because reviewers are the real constraint.
Choosing A Starting WIP Cap
Start with a cap that matches your ability to finish tasks without heavy waiting. A practical starting point for individuals is often 1 to 3 active tasks, depending on how independent the tasks are. If tasks require frequent external input, a cap of 1 may reduce the “waiting pile.” If tasks are self-contained and short, a cap of 3 to 5 can work, but only if you can finish within a predictable window.
For teams, a common approach is to set WIP per person or per role, not for the entire team. A shared team-wide cap can hide bottlenecks because one role may be overloaded while another role is idle. If you use per-role caps, you can keep work moving through handoffs. In a small team using Scrum boards, I’ve seen a per-developer WIP cap of 2 reduce “half-done” PRs, but only after they tightened the definition of “ready for review.”
To choose the number, look at your recent cycle times and the fraction of time tasks spend waiting. If tasks spend 60% of their time waiting on review, lowering WIP may not reduce cycle time unless you also fix review capacity. If tasks spend most of their time actively worked on, WIP reduction usually helps because context switching drops.
Measure Cycle Time And Throughput
Pick two metrics and track them for at least 2 to 4 weeks: cycle time (start-to-finish for a defined state) and throughput (completed tasks per week). Use the same definition every time. For example, define “start” as when a task enters “In Progress” and “finish” as when it enters “Done.” If your tool timestamps are messy, use manual sampling for a week to validate the automated numbers.
When WIP is too high, cycle time often rises because tasks wait longer for attention. Throughput may stay flat or drop as work becomes harder to finish. When WIP is too low, throughput can drop because capacity sits idle waiting for the next task to start. The goal is a middle point where tasks finish faster without starving the flow.
As a mild aside, I once compared two Jira exports from the same board and found that “In Progress” transitions were missing for about 8% of issues. That small gap made the cycle time chart look better than reality, so I corrected the workflow before making decisions.
Use A Simple WIP Rule For Start/Stop
Write a rule that governs when you can start a new task. Example: “You may start a new task only if active tasks are below the WIP cap and the task is ready with clear acceptance criteria.” The “ready” part matters because starting unclear work creates long-lived WIP. If you start tasks without acceptance criteria, you convert WIP into waiting and rework.
Then define what to do when the cap is reached. Common options include finishing the oldest active task, pairing on a bottleneck step, or blocking new starts until a review slot opens. The rule should be enforced consistently for a short experiment window, such as 2 weeks, before changing the cap.
In practice, teams often break the rule during urgent requests. If you do that, track “exceptions” separately so you can see whether the WIP limit still improves the baseline flow.
Adjust Based On Waiting And Handoffs
WIP limits work best when tasks move through a stable set of steps. If your workflow includes handoffs—like “engineering done” then “QA starts”—you need WIP limits at the handoff boundary too. Otherwise, engineering may finish quickly and then pile up in QA, which still increases cycle time.
Use a “wait time” breakdown if your data supports it. Many tools can show time-in-state, or you can approximate by sampling. If waiting dominates, the fix is often capacity at the waiting step, not just a lower WIP cap. For example, if QA review is the bottleneck, you can cap “ready for QA” and schedule review time rather than reducing engineering WIP alone.
When tasks are blocked on external dependencies like approvals, a WIP cap can reduce the number of parallel requests. That reduces the number of pending emails and follow-ups, but it does not remove the dependency. You still need a plan for how quickly you can resolve blocked items.
Run A Short Experiment With Guardrails
Change one variable at a time. If you lower WIP, keep your definitions of “start” and “done” stable and avoid changing acceptance criteria mid-experiment. Choose a guardrail such as “no more than 10% of tasks can be started without acceptance criteria.” Another guardrail is “no more than 1 exception per person per week,” which prevents the experiment from being dominated by urgent work.
After 2 weeks, compare cycle time and throughput to the prior period. If cycle time drops and throughput stays steady or rises, the cap is likely in the right range. If throughput drops sharply and active tasks finish quickly, the cap may be too low for your task arrival rate.
Version numbers can matter for measurement. If you use a workflow plugin or reporting dashboard, note the version and configuration date so you can reproduce the view later. I’ve seen dashboards change default filters after an update, which quietly altered the “completed” count.
Case Examples For Realistic Use
Individual Research And Writing
A freelance writer had 6 active items: outlines, interviews, draft sections, and fact-check notes. The tasks were all related, but they competed for attention and the writer often returned to older drafts after new research. They set a WIP cap of 2 active tasks and defined “active” as “drafting or editing,” not “collecting notes.” After 3 weeks, cycle time for completed articles dropped because drafts stopped getting interrupted by new research. Throughput improved modestly, but the biggest change was fewer half-finished drafts at any given time.
The writer still had to do research, yet research work moved to a separate “waiting” state until a draft was ready to start. That separation reduced the temptation to treat every new source as an active task.
Team Development With Review Bottlenecks
A small software team used a board with columns: Backlog, Ready, In Progress, In Review, and Done. They set a per-developer WIP cap of 2 for “In Progress” but left “In Review” unlimited. After lowering WIP, engineers finished work faster, yet QA queues grew and cycle time did not improve. The team then added a WIP cap for “In Review” of 3 per QA reviewer and scheduled review time blocks. After that change, cycle time decreased because work stopped piling up between engineering and QA.
This scenario shows a dependency: WIP limits must cover the bottleneck boundary, not only the start of work.
WIP Cap Checklist And Table
Use the table to pick a starting cap and the checklist to validate the workflow before enforcing it.
| Scenario | Starting WIP Cap | What To Watch | Likely Adjustment |
|---|---|---|---|
| Single person, self-contained tasks | 1–3 active tasks | Cycle time, rework, idle time | Raise if idle dominates; lower if cycle time rises |
| Single person, external waits | 1 active task | Waiting time and blocked items | Keep low until waits shrink; fix dependency capacity |
| Team, handoffs between roles | Per-role WIP caps | Queue growth at handoff states | Add WIP caps at bottleneck boundary |
| Team, frequent urgent exceptions | Lower cap + track exceptions | Exception rate and baseline metrics | Separate urgent work; keep experiment window clean |
Checklist before enforcing a WIP limit:
- Define “active” with a specific workflow state, not a vague label.
- Define “done” with acceptance criteria that match your real work.
- Confirm timestamps for state transitions or validate with manual sampling.
- Set a cap for at least one bottleneck boundary, not only the start column.
- Decide what happens when the cap is reached and document the rule.
- Run the experiment for 2 weeks and compare cycle time and throughput.
Common Mistakes That Undermine Trust
One mistake is changing the workflow definitions while testing. If “In Progress” starts meaning something different, the metrics stop comparing apples to apples. Another mistake is ignoring tasks that are active but blocked. A WIP limit that counts only tasks you are actively working on can hide the true load.
People also confuse WIP limits with deadlines. A WIP cap does not guarantee faster completion if acceptance criteria remain unclear. If tasks enter “In Progress” without a clear definition of done, the cap can reduce parallelism while increasing rework loops.
Another practical error is setting a cap so low that work arrival exceeds capacity. When that happens, you see idle time and throughput drops. The fix is not to abandon WIP limits; it is to raise the cap slightly or reduce task size so each active task finishes within a predictable window.
Finally, avoid promotional framing in your internal documentation. If you write “this will fix everything,” you lose credibility when the first week shows mixed results. A better approach is to record what you changed, what you measured, and what you observed.
FAQ
How Do I Define “Active” Tasks?
Use a specific workflow state such as “In Progress” and treat tasks as active from the moment they enter that state until they enter “Done.” Waiting states should not be counted as inactive if the task remains in the active column.
What WIP Limit Works For One Person?
Start with 1 to 3 active tasks when tasks are self-contained. Use 1 when tasks depend on external input that creates long waits, then raise the cap only after waiting time drops.
Should Teams Set One WIP Limit Or Per Role?
Per role usually works better because handoffs create different bottlenecks. A team-wide cap can hide overload in one role while another role sits idle.
How Long Should I Test A WIP Change?
Use 2 to 4 weeks so you can observe cycle time and throughput trends. Shorter windows often reflect random variation in task arrivals and review schedules.
What If Cycle Time Doesn’t Improve?
Check whether waiting time dominates and whether work piles up at a handoff state. WIP limits must cover the bottleneck boundary, and review or approval capacity may need adjustment.
Author's Insight
WIP limits function as a control mechanism on work-in-flight, not as a motivational rule. The most reliable way to choose a cap uses measured cycle time and throughput, tied to clear workflow definitions. When results disappoint, the cause often sits in state definitions, blocked work, or bottleneck handoffs rather than the numeric cap itself. A careful experiment with guardrails usually produces more useful learning than repeated guess-and-change.
Key Takeaways
Pick a WIP cap that matches how independent your tasks are and how much waiting you face. Define “active” and “done” with workflow states you update consistently. Track cycle time and throughput for 2 to 4 weeks, then adjust based on whether waiting dominates or idle dominates. Add WIP limits at bottleneck handoff states so work does not pile up between steps.
