Setting and Enforcing Work-in-Progress Limits: How to Use Kanban for Better Flow
This skill teaches you how to calculate, set, and enforce WIP limits for each stage of your kanban board so work flows smoothly, bottlenecks surface early, and your team stops context-switching between too many items at once.
Start by counting your team members and setting each column's WIP limit to the number of people who work in that stage, plus one buffer item. Run with these limits for two weeks, then adjust based on where work piles up or starves. If a column consistently hits its limit while downstream columns sit empty, your limit is correct and revealing a real bottleneck. If a column never reaches its limit, tighten it until you feel productive tension.
Outcome: Your team completes work faster with less context-switching because each workflow stage has a tested, enforced cap on concurrent items that makes bottlenecks visible the moment they form.
Prerequisites
- A working kanban board with defined workflow columns (see designing-kanban-boards)
- Basic understanding of kanban flow concepts and pull-based systems
- Access to historical data on how long items spend in each stage, or willingness to collect it for 1-2 weeks
- Authority or team agreement to enforce limits (not just display them)
Overview
Work-in-progress limits are the single most important mechanism in Kanban. Without them, a kanban board is just a to-do list with columns. WIP limits are the constraint that transforms a passive visualization into an active management system. They cap the number of items allowed in any given workflow stage at any given time, forcing the team to finish existing work before pulling in new work. This simple rule creates a pull system where work flows downstream based on capacity rather than being pushed in based on demand or wishful thinking.
The problem WIP limits solve is deceptively common: teams take on more work than they can actually process. A developer might have six items "in progress," a designer might be juggling four reviews, and a QA analyst might be testing three features simultaneously. Each individual feels busy, but the system is clogged. Items age in queues, context-switching drains productivity, and lead times balloon. Setting WIP limits makes this invisible overload visible and actionable. When a column hits its limit, no new items can enter until something exits. This forces conversations about priorities, surfaces bottlenecks in real time, and creates the productive tension that drives continuous improvement.
The concrete artifact you produce when applying this skill is a set of per-column WIP numbers displayed on your board, along with a written enforcement policy the team has agreed to. The WIP numbers themselves are the easy part. The hard part, and the real skill, is choosing the right starting numbers, adjusting them based on flow data, and building the team discipline to respect them when pressure mounts. This skill walks through all three. By the end, your board will have calibrated WIP limits that match your team's actual throughput, and your team will have clear protocols for what happens when a limit is reached. You will see measurable reductions in cycle time and a noticeable decrease in the number of stale items sitting untouched in intermediate columns.
How It Works
WIP limits work because of a principle from queuing theory called Little's Law: the average number of items in a system equals the average arrival rate multiplied by the average time each item spends in the system. In plain language, if you want items to move through your board faster (lower cycle time), you have two options: increase throughput capacity or reduce the number of items in the system. Adding capacity is expensive and slow. Reducing WIP is immediate and free. That is why WIP limits are the highest-leverage change you can make to a Kanban workflow.
The mental model is a highway. A highway has a maximum throughput at a specific density of cars. Below that density, adding more cars increases total throughput because there is unused capacity. Above that density, every additional car slows everyone down, throughput drops, and you get gridlock. Your kanban board behaves the same way. There is an optimal number of concurrent items per stage. Below that number, people have idle capacity. Above it, context-switching and handoff delays choke the flow. WIP limits keep you at the productive sweet spot.
The formula for a starting WIP limit is straightforward: count the number of people who actively work in a given stage, then add a small buffer. The buffer exists because real workflows have natural variation. Sometimes a developer finishes a task and the next one is not quite ready for pull. A buffer of one or two items prevents that developer from sitting idle while still keeping the system constrained. A common starting formula is: WIP limit = (number of workers in that stage × 1) + 1. For a team of three developers, the "Development" column would start with a WIP limit of 4.
Why not just set the limit to the exact number of workers? Because a zero-buffer system assumes perfect synchronization, which does not exist in knowledge work. Items are different sizes, people get pulled into meetings, dependencies create wait states. The small buffer absorbs this variance without opening the floodgates. But the buffer should stay small. A buffer of three or four items per person means you effectively have no limit at all.
WIP limits also serve as a forcing function for systemic improvement. When a column consistently hits its limit, it reveals a bottleneck. The team must then decide: should we add capacity to that stage, simplify the work entering it, or improve the handoff from the upstream stage? Without WIP limits, bottlenecks hide beneath the surface. Work piles up invisibly, and the team compensates by starting more new items upstream, which makes the problem worse. WIP limits make the pain visible and create urgency to address root causes rather than symptoms.
Finally, WIP limits create accountability for the whole team, not just individuals. When the "Code Review" column is full, the developers writing new code are responsible for helping clear the review queue before pulling in new development work. This shared ownership of flow is what separates a kanban team from a group of individuals working in parallel columns.
Step-by-Step
Step 1: Map your workflow stages and identify who works in each
Before you can set WIP limits, you need a clear picture of which people do work in which columns. Open your kanban board and list every active column that represents real work being done, not waiting states or buffers. For each active column, write down the names or roles of team members who pull items into that column and do the work. If your board has both active and waiting sub-columns (for example, "Development: Active" and "Development: Waiting for Review"), treat the active sub-column as the constrained stage.
Some people will appear in multiple columns, especially on small teams where a developer also does code review. Note those overlaps because they affect your capacity calculations.
Tip: If you are unsure whether a column represents active work or a queue, ask: does someone need to take an action for an item to leave this column? If yes, it is an active stage. If items sit here until someone from the next stage pulls them, it is a queue, and you should still limit it but with a different logic.
Step 2: Calculate starting WIP limits using the n+1 formula
For each active column, apply the starting formula: WIP limit = number of people who work in that stage + 1. If three developers work in the "Development" column, set the initial WIP to 4. If two designers handle "Design," set it to 3. For queue or buffer columns between active stages (like "Ready for Review"), set the WIP limit to 1 or 2 items.
Queues should be small because their purpose is to prevent downstream starvation, not to stockpile work. 5 in each stage. A person who splits time between Design and Development contributes half a unit to each column's capacity.
Tip: If your team has fewer than four people total, consider using a single WIP limit for the entire board (a global WIP limit) rather than per-column limits. Per-column limits on a three-person team can create artificial rigidity because one person often spans multiple stages.
Step 3: Write down your enforcement rules before announcing the limits
WIP limits without enforcement rules are suggestions, and suggestions get ignored under pressure. Before you reveal the numbers to the team, draft a short written policy that answers three questions: What happens when a column reaches its WIP limit? Who is allowed to grant an exception, and under what conditions? How does the team signal that a column is blocked?
For the first question, the default answer should be: "No new items may be pulled into a column that has reached its WIP limit. " For exceptions, designate a single person, usually the team lead or product owner, who can temporarily allow a limit breach with a documented reason. For signaling, use a visual indicator such as turning the column header red or adding a "blocked" tag to the item causing the constraint.
Tip: Write the enforcement policy as three bullet points, not a page-long document. If people have to look it up, they will not follow it. Pin it next to the board or in the team's chat channel.
Step 4: Apply the limits to your board and brief the team
Add the WIP numbers to your kanban board. Most digital tools have a dedicated WIP limit field per column. " Then hold a brief 15-minute team meeting to explain three things: what the numbers mean, what happens when a limit is hit, and why you are doing this (faster delivery, less context-switching, fewer stale items). Be transparent that the starting numbers are estimates and will be adjusted.
Ask the team to commit to respecting the limits for a two-week trial period. Do not debate the exact numbers in this meeting because you do not have flow data yet. Promise to revisit and adjust based on evidence.
Tip: Frame WIP limits as a team experiment, not a management mandate. Teams resist limits that feel imposed. Teams rally around limits they helped test and tune.
Step 5: Observe flow for two weeks and record what happens at the limits
For the next two weeks, track every time a column hits its WIP limit. Record the date, which column was full, how long it stayed full, and what the team did in response. Did they swarm to help clear the bottleneck? Did they wait idle?
Did someone override the limit? Also track your basic flow metrics during this period: how many items were completed per week (throughput), how long items took from start to finish (cycle time), and how many items were in progress at any given time (total WIP). You will need this data to make informed adjustments. Pay special attention to columns that never come close to their limit because these are candidates for tightening.
Tip: Keep a simple log in a shared spreadsheet with columns: Date, Column Name, Event ("limit hit" / "limit breached" / "swarming occurred"), Notes. This log is your evidence base for the tuning conversation in Step 6.
Step 6: Adjust limits based on observed flow patterns
After two weeks, review your log and flow metrics with the team. Look for four patterns. First, a column that hits its limit frequently while the column downstream is usually empty. This means the bottleneck is real and in the right place, so keep the limit and invest in improving that stage's throughput.
Second, a column that hits its limit but items are aging because they are blocked, not because the team is actively working on the maximum number. This means blocked items are consuming WIP capacity, so add an explicit "blocked" sub-state and consider whether blocked items should count against the limit. Third, a column that never reaches its limit. Tighten it by reducing the WIP by one.
Continue tightening until you feel mild tension. Fourth, a column where the team routinely overrides the limit with justification. Consider whether the limit is too tight or whether the override reasons reveal a process problem to fix. Make one adjustment at a time, wait another one to two weeks, and measure again.
Tip: The right WIP limit feels slightly uncomfortable. If the team never bumps up against it, the limit is too generous. If the team is constantly fighting the limit and work stalls completely, the limit is too tight. Aim for the zone where the limit surfaces problems without paralyzing progress.
Step 7: Handle common resistance and exception requests
Within the first month, someone will ask to exceed a WIP limit. This is expected and healthy because it means the limits are working. The correct response is not to refuse outright but to make the cost visible. When someone requests an exception, ask: which of the items currently in progress should we deprioritize or pause to make room?
This forces a priority conversation rather than just adding more work. If a stakeholder or executive pushes for a WIP override, show them the data from your observation log. Explain that adding an item to a full column will slow everything in that column, not just the new item. If they still insist, grant the exception, document it, and track the impact on cycle time.
Over time, the data will show that exceptions consistently increase lead time, which makes the case for limits stronger.
Tip: Create a visible "exception count" metric on the board. Teams that track exceptions publicly tend to reduce them naturally because the social visibility creates gentle accountability.
Step 8: Institutionalize limits with regular review cadences
WIP limits are not set-and-forget. As your team size changes, as work types shift, and as process improvements take effect, the optimal WIP limit changes too. Build a WIP limit review into your regular cadences. In your retrospective or service delivery review, look at your cumulative flow diagram to spot where work accumulates.
If a stage's average WIP has drifted well below its limit for several weeks, tighten it. If a stage is constantly at its limit and you have verified the bottleneck is genuine, either invest in that stage's capacity or accept it as the system's constraint and protect it from interruptions. Document any changes to WIP limits and the reasoning behind them. This creates a historical record that helps new team members understand why the limits are set where they are.
Tip: A quarterly WIP limit review is sufficient for stable teams. Teams going through significant changes (new members, new product areas, reorganizations) should review monthly until flow stabilizes.
Examples
Example: Five-person product engineering team building a SaaS product
A team of five, consisting of one product designer, three software developers, and one QA engineer, uses a kanban board with columns: Backlog, Design, Development, Code Review, QA, and Done. Items are taking 14 days average cycle time. The team feels overloaded, with developers juggling 3-4 items each. The team lead wants to introduce WIP limits to get cycle time under 7 days.
The team lead maps workers to columns: Design has 1 person, Development has 3, Code Review is done by the same 3 developers, and QA has 1 person. Using the n+1 formula, starting limits are: Design = 2, Development = 4, Code Review = 2 (lower because it competes with Development for the same people's time), QA = 2. The buffer columns "Ready for Dev" and "Ready for QA" each get a limit of 2. After one week, the team observes that Code Review hits its limit almost daily, while Development rarely reaches 4.
The developers are spending so much time writing new code that reviews pile up. In the tuning session, the team decides to lower Development to 3 and keep Code Review at 2, forcing developers to review before pulling new work. After three weeks, cycle time drops from 14 days to 9 days. The Code Review bottleneck is clearing faster, and the team decides to try Development at 2 for one more iteration to see if further tightening improves flow.
Example: Marketing content team with variable work types
A marketing team of six people, including two writers, one editor, one designer, and two marketing managers, runs content production on a kanban board with columns: Ideas, Drafting, Editing, Design, Review, and Published. Some items are blog posts (small), some are whitepapers (large), and some are social campaigns (tiny). The team has 30 items in various stages with no limits, and nothing feels like it is finishing on time.
The team lead counts workers per column: Drafting has 2 writers, Editing has 1 editor, Design has 1 designer, and Review involves 2 managers. Starting WIP limits: Drafting = 3, Editing = 2, Design = 2, Review = 3. The "Ideas" column is not limited because it functions as a backlog, but the team agrees that only the top 10 ideas remain visible to prevent overwhelm. In the first week, Editing immediately hits its limit because the single editor is the bottleneck.
5 capacity to that stage. After two weeks, the team notices that whitepapers (large items) dominate the WIP for days, crowding out smaller items. They create a separate swim lane for large items with a dedicated WIP limit of 1 across the board, meaning only one whitepaper can be in progress at any time. Blog posts and social campaigns share the remaining WIP capacity.
Cycle time for blog posts drops from 12 days to 5, and whitepapers, though still taking 15 days each, are no longer blocking the rest of the pipeline.
Example: Enterprise team with 15 people across time zones
A distributed team of 15 engineers across three time zones maintains a large kanban board for a platform product. The board has columns: Refinement, Development, Code Review, Integration Testing, Staging, and Release. With no WIP limits, the board shows 40+ items in progress. Lead times are averaging 28 days, and stakeholders are frustrated. The engineering manager needs to introduce WIP limits without creating gridlock across time zones.
The manager maps the team: Refinement involves 2 senior engineers, Development has 10 engineers (split across 3 pods of 3-4), Code Review is handled by the same 10 engineers, Integration Testing has 2 QA engineers, and Staging/Release is managed by 1 DevOps engineer. Rather than one board-wide WIP limit, the manager sets limits per column: Refinement = 3, Development = 12 (slightly above 10+1 because time zone handoffs mean some items sit idle during off-hours), Code Review = 4 (intentionally tight to force priority), Integration Testing = 3, Staging = 2. The manager also sets a global WIP limit of 20 as a safety net. The first week is chaotic because 40 items need to drop to 20.
The team triages: 12 items are deprioritized back to the backlog, 8 are already near done and get fast-tracked. Within two weeks, the active WIP stabilizes at 18-20 items. The biggest win is that Code Review, previously a graveyard where items waited 5+ days, now clears within 48 hours because engineers across time zones pick up reviews during their morning overlap. After one month, lead time drops to 16 days.
The manager tightens Development to 11 and sets a target of getting lead time under 12 days by the end of the quarter.
Example: Solo founder using personal kanban for a B2C app launch
A solo founder building a mobile app uses a personal kanban board with columns: Backlog, This Week, In Progress, Waiting (for external dependencies like app store review or API approvals), and Done. They have 8 tasks marked "In Progress" but realistically can only make meaningful progress on 2-3 per day. Items linger for weeks in the "In Progress" column.
Since there is only one person, per-column limits would be overly rigid. The founder sets a global WIP limit of 3 for all active columns combined (In Progress + Waiting). The "This Week" column gets a limit of 5, functioning as a weekly sprint-like commitment. The Waiting column gets a separate limit of 2 because the founder cannot control external timelines but can control how many items they send out for external action simultaneously.
In the first week, the founder struggles to keep WIP at 3 because they are used to switching between tasks whenever they feel stuck. By mid-week, they notice that forcing themselves to finish one item before starting another means they are completing 4 items per week instead of their previous average of 2. The Waiting limit of 2 proves especially useful because it prevents the founder from submitting three app store builds simultaneously and then having to context-switch between fixing issues on all three when feedback arrives. After a month, the founder tightens global WIP to 2, finding that the focus boost outweighs any idle time.
Best Practices
Start with limits that feel slightly too tight rather than too loose. A generous limit will never reveal problems because you will never hit it. A tight limit creates productive friction that surfaces bottlenecks and forces the team to collaborate on clearing them. You can always loosen a limit that proves genuinely too tight, but teams rarely voluntarily tighten limits that are too loose because comfort feels like success.
Apply WIP limits to the team, not to individuals. Setting a per-person WIP of two items might seem logical, but it defeats the purpose. Kanban WIP limits constrain the system to create flow, and when a column is full, anyone on the team should pitch in to clear it. Per-person limits turn a team system into individual task management and prevent the swarming behavior that makes kanban effective.
Make WIP limits physically visible on the board, not buried in tool settings. A WIP limit that you have to click into a settings menu to see will be forgotten within a week. Whether you use a digital or physical board, the limit number should be visible at a glance next to the column name. Many teams use the format "Column Name [3]" or color the column header yellow when it reaches 80% of its limit and red when full.
Count blocked items against WIP limits. Teams sometimes argue that a blocked item should not count because "we are not actively working on it." But blocked items consume the team's attention, carry context-switching costs, and occupy space in the workflow. Counting them against the limit creates urgency to unblock them. If blocked items routinely eat up WIP capacity, create a separate "blocked" swim lane and add an explicit escalation policy for unblocking.
Set WIP limits on queue columns too, not just active work columns. Unlimited queues between stages defeat the purpose of WIP limits on the active stages. If your "Ready for Development" queue can hold 20 items, then upstream stages will keep feeding it, and developers will cherry-pick easy items instead of pulling the highest priority one. Cap queue columns at one to three items to maintain pull discipline.
Never change WIP limits in the middle of a crisis. The temptation to raise the limit when the team is under pressure is strong, but this is exactly the moment when limits provide the most value. The limit is telling you that your system cannot absorb more work at its current capacity. Adding items will make the crisis worse, not better.
Changing limits should be a deliberate, data-informed decision made during a retrospective, not a reactive move during a crunch.
Use WIP limits as a conversation starter, not a conversation ender. When someone asks "why can't I start this new item?", the answer is not "because the WIP limit says no." The answer is "because we have four items in progress and finishing any one of them will free up capacity. Which of those four should we focus on first?" Limits should redirect energy toward completion, not create frustration.
Common Mistakes
Setting WIP limits too high to avoid team pushback
Correction
A WIP limit of 10 on a column where five people work is not a limit. It is decoration. This happens because teams negotiate the limit upward until it never triggers. " If that conversation has never happened, your limits are too high.
Lower each column's limit by one every two weeks until the team hits the limit at least twice per week. That is the zone where limits start revealing real flow problems.
Applying WIP limits without enforcement, treating them as guidelines
Correction
Teams often set WIP limits in their tool but then routinely exceed them without discussion. Digital tools typically allow you to add items past the limit with no friction beyond a color change. This creates what practitioners call "decorative WIP limits," numbers on the board that nobody respects. The cause is usually a missing enforcement protocol.
Fix this by requiring that any WIP limit breach be announced in the team's standup or chat channel with a stated reason. Track breaches as a metric. Teams that make breaches visible reduce them by 60-80% within a month because social accountability is a powerful motivator.
Setting a single global WIP limit instead of per-column limits
Correction
A global WIP limit (for example, "no more than 12 items in progress across the whole board") is a useful starting point for very small teams, but for teams of five or more it hides the location of bottlenecks. You might have 12 items total, which sounds fine, but 8 of them could be stuck in code review while the other columns sit empty. Per-column limits make the distribution of work visible. The exception is teams of three or fewer, where per-column limits can create artificial gridlock because one person often spans multiple stages.
For these micro-teams, a global limit of n+1 where n is the team size works better.
Never adjusting WIP limits after the initial setup
Correction
Teams set WIP limits once and treat them as permanent fixtures. But your optimal WIP depends on team size, work type, and process maturity, all of which change. The sign that your limits are stale is that your cycle time has plateaued despite process improvements, or a team member has joined or left without the limits being recalculated. Build a WIP review into your retrospective cycle.
Look at your cumulative flow diagram: if bands are consistently thin and even, your limits are working. If one band is widening steadily, that column's limit may be too high or its throughput is degrading.
Exempting "small" or "quick" items from WIP limits
Correction
Teams often argue that a tiny bug fix or a quick config change should not count against the WIP limit because it will be done in minutes. But small items still consume attention, still require context switches, and still carry risk of expanding scope. Once you allow exceptions for "small" items, the definition of small creeps upward until half the work bypasses the limit. Instead, if truly trivial items are a category, create an explicit expedite lane with its own small WIP limit (typically one item).
Anything that does not qualify for the expedite lane follows normal WIP rules regardless of estimated size.
Focusing WIP limits only on development stages and ignoring upstream columns
Correction
Product teams frequently set WIP limits on "Development" and "Testing" but leave "Backlog Refinement" or "Design" unconstrained. This creates an imbalance where upstream stages overproduce refined or designed items that pile up waiting for development capacity. The result is wasted design effort when priorities change and a false sense of productivity in upstream stages. Apply WIP limits to every active column on the board, from the earliest refinement stage through to the final review before done.
The entire system must be constrained for pull to work end-to-end.
Other Skills in This Method
Managing Projects with Kanban
How to apply Kanban principles to plan, execute, and deliver projects using pull-based scheduling and continuous delivery instead of fixed sprints.
Running Kanban Cadences and Feedback Loops
How to facilitate the seven Kanban cadences — including standups, replenishment meetings, delivery planning, and service delivery reviews — to enable continuous improvement.
Designing Effective Kanban Boards
How to structure columns, swimlanes, and card layouts on a Kanban board to accurately visualize your team's workflow from intake to completion.
Measuring Kanban Flow Metrics
How to track and interpret lead time, cycle time, throughput, and cumulative flow diagrams to continuously improve delivery performance.
Creating Explicit Pull Policies and Workflow Rules
How to define clear entry and exit criteria for each Kanban column so the team knows exactly when and how to pull work forward through the system.
Comparing Kanban and Scrum for Your Team
How to assess the differences between Kanban's continuous flow and Scrum's sprint-based approach to choose or combine the right method for your context.
Choosing the Right Kanban Tools and Software
How to evaluate and select digital Kanban tools like Trello, Jira, and Asana based on team size, workflow complexity, and integration needs.
Frequently Asked Questions
How do I set WIP limits when team members work across multiple columns?
Count shared team members as fractional capacity in each column they serve. 5 in each column when calculating the n+1 formula. 5) + 1 = 2. The key insight is that shared workers mean the columns compete for the same capacity, so their combined WIP limits should reflect that competition. If both columns are consistently full, the shared workers are spread too thin, and you should consider dedicating someone to the bottleneck column.
Should blocked items count against WIP limits?
Yes, blocked items should count against WIP limits. This is counterintuitive because blocked items are not being actively worked on, but counting them creates urgency to resolve the blocker. If blocked items do not count, teams lose incentive to unblock them quickly, and the items age silently while consuming mental overhead. If blocked items frequently fill your WIP capacity, that is a signal that your blocking rate is a systemic problem. Create a visible "blocked" tag, track the reasons items get blocked, and address the top blocking causes in your retrospective. Some teams add a small "blocked" sub-lane with its own WIP limit of 1-2 to make blockers hyper-visible.
How long should I run with initial WIP limits before adjusting them?
Run with your initial limits for at least two full weeks before making any adjustments. Shorter observation periods do not give you enough data because work items have natural variation in size and complexity. You need to see at least one full cycle of items flowing through the board to understand the pattern. During these two weeks, resist the urge to change limits reactively when the team feels uncomfortable. The discomfort is the limit working correctly. After two weeks, make one adjustment at a time, changing one column's limit by one item, and observe for another week before changing anything else. Changing multiple limits simultaneously makes it impossible to understand which change had which effect.
What is the difference between per-column WIP limits and a global WIP limit?
Per-column limits cap the number of items in a specific workflow stage. A global limit caps the total number of items in progress across all active stages of the board. Per-column limits are more granular and better at revealing exactly where bottlenecks live. Global limits are simpler and better suited for very small teams (1-3 people) where per-column limits create artificial rigidity. For teams of 4+, use per-column limits as your primary mechanism and optionally add a global limit as a safety ceiling. The global limit catches situations where every column is near its individual limit, which means the total system WIP is higher than the team can sustain even though no single column appears overloaded.
Should I set WIP limits before or after measuring flow metrics?
Set rough WIP limits first using the n+1 formula, then refine them using flow data. Waiting to collect flow data before setting any limits creates a chicken-and-egg problem: you cannot observe meaningful flow patterns in a system with unlimited WIP because the flow is distorted by overload. Set initial limits based on team size, run for two weeks, and measure cycle time, throughput, and cumulative flow during that period. The data you collect under constrained conditions is far more useful than data from an unconstrained system. See [measuring flow metrics](/skills/measuring-kanban-flow-metrics) for the specific metrics to track during this calibration period.
How do I convince my manager or stakeholders that WIP limits won't slow us down?
Frame the argument around finishing, not starting. Most managers track how much work is being started, but what matters is how much is being completed. Show them the current state: X items are "in progress" but only Y items were completed last week. That gap between started and finished is the waste WIP limits address. " After the trial, present the before-and-after data. In nearly every case, throughput stays the same or increases while cycle time drops significantly. The team is not doing less work. They are finishing more of what they start.
Why does my WIP limit keep getting overridden during sprint or release crunch?
This happens because the team has not internalized that WIP limits exist to protect throughput, especially under pressure. When a deadline looms, the instinct is to start more work to "go faster," but starting more items actually slows delivery because of context-switching and coordination overhead. Fix this by tracking the outcomes of overrides. Every time a WIP limit is breached, note the date, reason, and resulting cycle time for items in that column during the breach period. After two or three incidents, you will have data showing that overrides consistently increase cycle time, not decrease it. Present this data in your retrospective. Additionally, review your [pull policies](/skills/creating-kanban-pull-policies) to ensure they explicitly address crunch scenarios.