Mastering WIP Limits: How to Control Workflow in t0ggles

A WIP limit (work-in-progress limit) is a cap on how many tasks can be in one stage of your workflow at the same time. If your "In Progress" column has a WIP limit of 3, the team may not start a fourth task until one of the three is finished and moved on. WIP limits are the core practice of Kanban, and they work because of a simple fact about flow: the more items you juggle at once, the longer each one takes. Capping the number of open tasks forces the team to finish work before starting more, which shortens cycle time, exposes bottlenecks, and cuts the multitasking that quietly burns teams out.

Here is the whole idea in one table:

The rest of this guide covers why WIP limits work, how to set WIP limits step by step (including the exact setting in t0ggles), worked examples for different team types, and the mistakes that make teams give up on them.

#What Are WIP Limits?

WIP stands for work in progress: any task that has been started but not finished. A WIP limit is a maximum number of such tasks allowed in a specific stage of your workflow at any moment.

The practice comes from Kanban, where it is one of the four core practices alongside visualizing work, managing flow, and making policies explicit. It is the practice that turns a board of columns into a pull system. Without limits, work is pushed: whoever has a request drops it into "In Progress" and it joins the pile. With limits, work is pulled: a task only enters a stage when there is capacity in that stage, which means somebody just finished something.

A limit of 3 on "In Progress" means:

• Three tasks are in that column and being actively worked.
• A fourth cannot enter until one of the three moves forward.
• The team's job when the column is full is to finish, not to start.

It is a simple idea with a big impact: less multitasking, more finishing.

#Why WIP Limits Matter

The case for WIP limits is not about discipline. It is about how queues behave.

Every open task costs more than its own work. Each task you juggle adds context switching, half-remembered state, and a longer wait for every other task in the queue. A person "working on" six things is progressing on none of them at full speed. Cutting that to two does not halve throughput; it usually raises it, because far less time is lost between tasks.

Cycle time tracks WIP. Little's Law, from queueing theory, says the average time a task spends in a system equals the number of items in the system divided by the rate they complete. If your team completes ten tasks a week and has twenty in progress, the average task takes two weeks. Drop WIP to ten with the same completion rate and the average task takes one week. Nothing about the team changed. Only the queue did.

Bottlenecks become visible. When "In Progress" is capped and "In Review" keeps filling up, you have learned something specific: review is the constraint, and the fix is more reviewer capacity, not more developers. Without limits, the same bottleneck shows up as vague lateness.

Priorities get decided on purpose. A full column forces the conversation "which of these matters more?" at the moment it is useful, instead of letting the answer be "whichever one got started first".

Without WIP limits, teams tend to start too many things at once, leave work half-done, create pile-ups in QA and review, miss deadlines through context switching, and burn out from a workload that is invisible because it is spread across so many open cards. With WIP limits, focus improves, delivery becomes predictable, and the board tells the truth about capacity.

#How to Set WIP Limits

There is no universal number, but there is a reliable method. Follow these steps and expect to adjust after two or three weeks.

#1. Pick the Columns to Limit

Limit the stages where work is actively being done or actively waiting on someone: In Progress, In Review, QA, Blocked. Do not limit Backlog (it is meant to hold options) or Done (it is meant to grow). If a column is a queue between two teams, such as "Ready for QA", limit it too. Those are the queues that hide handoff problems.

#2. Calculate a Starting Number

Two rules of thumb, use whichever fits:

• Per-person method: the number of people who work in that stage, plus one. Three developers pulling from "In Progress" gives a limit of 4. The extra slot absorbs blocked tasks without stalling everyone.
• Baseline method: count what is in the column today, then set the limit slightly below that. If "In Review" usually holds seven tasks, start at 5. The limit should bite a little on day one, or nobody learns anything.

For stages that depend on a single person (one designer, one QA engineer), start at 2. For a solo freelancer, 1 or 2 for the whole "In Progress" column is realistic.

#3. Set the Limit in Your Tool

In t0ggles, WIP limits live on statuses, so they apply in every view and every project on the board:

1. Open your board and click Board Settings.
2. Go to Statuses.
3. In the Max tasks column, enter the limit for each status you want to cap.
4. Close settings. Changes save automatically.

The limit is checked per project and status. In Focus Mode it caps the column for that project, and in multi-project view each project's group of tasks in that status is checked separately, so on a shared board you see exactly which project is over. See the statuses documentation for the full settings reference.

#4. Agree on What Happens at the Limit

Write the policy down where the team can see it, because the tool will only warn you. t0ggles highlights a column in red when it exceeds its Max tasks value; it does not block the move. That is deliberate. A hard block hides the real situation, while a red column starts a conversation. The policy most teams settle on:

• When a column is red, nobody starts a new task in it.
• Whoever is free helps finish something already in the column: pair, review, test, unblock.
• If the column is red for more than a day, raise it at standup or in the retro. Something upstream or downstream is out of balance.

#5. Tune After Two Weeks

Look at two signals. If the column is never red, the limit is too high and is not doing anything. If it is red every day and the team is constantly blocked, the limit is too low for the current stage capacity, or the stage after it is the real bottleneck. Adjust by one, wait another two weeks, and watch cycle time in board reports. Cycle time going down while throughput holds is the signal that the limits are working.

#WIP Limit Examples by Team Type

Concrete numbers help more than principles. These are realistic starting points for common team shapes.

#A Startup Dev Team, Before and After

A common pattern: the QA engineer is permanently overloaded, developers keep shipping into "Ready for QA", and releases slip because untested work piles up. Setting "Ready for QA" to a WIP limit of 5 changed the dynamic. When the column turned red, developers had to stop starting features and either help test or fix the failed tests already in the queue. Dev throughput looked slower for a week. Release throughput went up, because the constraint was test capacity all along and the limit made everyone work on it.

#A Creative Studio, Before and After

Eight design tasks active across four designers, every deadline at risk, and a team that felt busy and behind at the same time. "In Progress" capped at 3 felt impossibly low for a week. Then tasks started completing in days instead of weeks, because each designer was on one thing, and the client feedback column got attention because nothing else could start. The cap did not reduce the amount of work delivered. It reduced the amount of work simultaneously half-finished.

#WIP Limits in Kanban, Scrum, and Scrumban

WIP limits are a Kanban practice, but they fit every Agile method.

Our Kanban vs Scrum comparison covers when to pick each method, and the Scrumban hybrid is often the best fit for teams that want sprint rhythm with WIP-limited flow. For the wider picture, the Agile project management guide puts WIP limits alongside the other Agile practices.

#Common WIP Limit Mistakes

• Setting limits too high. A limit of 10 on a three-person team's "In Progress" column is decoration. The limit should be hit occasionally, or it teaches nothing.
• Ignoring red columns. If exceeding the limit has no consequence, the team learns the limit is fictional. The consequence does not have to be a block. It has to be a conversation.
• Limiting every column. Backlog and Done should not be limited. Limiting columns nobody works in adds noise without changing behavior.
• Limiting people instead of stages. "Everyone has max 2 tasks" sounds equivalent but is not: it lets one stage fill up with everyone's second task. Limit the stage.
• Raising the limit to make the red go away. The red is information. Raise the limit only after you have checked whether the bottleneck is really in that stage or the one after it.
• Treating the limit as a target. A column with a limit of 4 does not have to hold 4 tasks. Fewer is fine. The limit is a ceiling, not a quota.

#How WIP Limits Improve Flow

What changes when limits are in place:

#How to Introduce WIP Limits to Your Team

1. Explain the why. Frame it as a way to reduce overwhelm and finish more, not as a restriction. Show the cycle time math: fewer open tasks means each one ships sooner.
2. Start with one column. Usually "In Progress" or whichever queue is most obviously backed up. Add more once the team has felt the first one work.
3. Set soft limits first. t0ggles warns rather than blocks, which suits this phase. Discuss every red column at standup for two weeks.
4. Measure and iterate. Track cycle time and throughput in reports. Adjust limits by one at a time, and give each change two weeks.
5. Pair limits with automation. A due date automation that escalates overdue tasks and a WIP limit on the review column together catch most stuck work before it becomes a missed deadline.

#Why t0ggles Works Well for WIP Management

Unlike tools that require paid add-ons or per-team board configuration, t0ggles has WIP limits built into every board:

• One setting per status, applied across multi-project and Focus Mode views.
• Visual, not blocking: red columns start conversations instead of hiding the situation.
• Per-project checks on a shared board, so an agency or a multi-team board sees exactly which project has overloaded a stage.
• Cycle time and throughput in board reports to check whether the limits are working.
• Board automations to escalate what is stuck, and task dependencies to see why.

The free plan includes 1 board, 3 team members, and 100 tasks, with WIP limits included, so you can run the two-week experiment without paying anything. The paid plan is $5 per user/month (billed annually) with everything unlimited.

#Frequently Asked Questions

#Additional Resources

• Kanban vs Scrum: Which Agile Methodology Is Right for Your Team?
• Agile Project Management Guide
• Top 7 Project Management Methodologies for Startups
• Project Management Automation: What to Automate and How
• Board Statuses Docs
• Board Reports Docs
• Free Sprint Retrospective Generator

Ready to finish more? Set your first WIP limit in t0ggles - free, no card required.