Why your team is busy but not shipping

You have a team of 10 engineers. They are all working. The Slack channels are active. The stand-ups are full of updates. Yet, the release date keeps slipping. You check the project kickoff template you used three months ago, and the scope looks exactly the same as it did then. Nothing has moved to done.

This is the paradox of modern work management. We confuse activity with progress. We assume that if everyone is busy, the work is getting done. It is not. It is getting started. It is getting discussed. It is getting blocked. But it is not finishing.

The culprit is rarely laziness or incompetence. It is usually a lack of constraints. Specifically, a lack of Work in Progress (WIP) limits. Most teams treat their kanban boards like infinite buckets. They pull new tasks whenever they feel like it, regardless of what is already in the pipe. This creates a hidden tax on your velocity. Every open task fragments attention. Every context switch costs time. Every half-finished feature sits in limbo, consuming mental RAM without delivering value.

WIP limits are not about restricting your team. They are about protecting their focus. They force you to finish what you start before you begin something new. This page explains how to set those limits using real numbers, not vague advice. We will look at the math of flow, the cost of switching, and how to actually enforce these limits in Anabatic without becoming a micromanager.

The math of flow: why starting more slows you down

To understand WIP limits, you need to understand Little’s Law. It is a simple formula from queuing theory that applies directly to software development and marketing workflows. The formula is:

Lead Time = Work in Progress / Throughput

Let us break this down. Lead time is how long it takes for a task to go from start to finish. Work in Progress is the number of items currently being worked on. Throughput is the number of items you finish per unit of time.

Here is the counterintuitive part. If you increase your Work in Progress, your Lead Time increases. If you want to finish things faster (lower Lead Time), you must either increase your Throughput (which is hard to do sustainably) or decrease your Work in Progress.

Consider a small product team. Let us say they can realistically finish 5 tasks per week. That is your throughput. If they have 5 tasks in progress, the average lead time is 1 week. Now, imagine they pull in 10 tasks. They are now juggling double the work. The throughput does not magically double. In fact, it often drops because of context switching. If the throughput drops to 4 tasks per week due to chaos, and WIP is 10, the lead time jumps to 2.5 weeks.

You started more work, but you finished it slower. This is the trap. Teams see a backlog and think, “We need to get more people on this.” So they add more WIP. The lead time stretches. The anxiety grows. The team works harder. The lead time stretches further. It is a feedback loop of diminishing returns.

WIP limits break this loop. By capping the number of items in a column, you force the team to clear the pipe before filling it again. You trade the illusion of busyness for the reality of completion.

The hidden cost of context switching

The math above assumes that throughput is constant. It is not. Throughput degrades as WIP increases. Why? Because of context switching. When you move from Task A to Task B, you do not just switch windows. You switch mental models. You have to reload the variables, the constraints, and the history of Task A into your short-term memory. Then you do the same for Task B. Then you switch back.

Research suggests that it takes an average of 23 minutes to get back on track after an interruption. If you are juggling 5 tasks, you are interrupting yourself 4 times a day. That is nearly 2 hours of pure recovery time. That is time you are not shipping.

This is where the stop measuring output, start measuring lift mindset becomes critical. If you measure output by lines of code or tickets closed, you will ignore the quality of that output. A developer who switches contexts every hour will produce buggy, fragile code. They will miss edge cases. They will create technical debt. The cost of fixing that debt later is far higher than the cost of the initial context switch.

WIP limits reduce context switching by design. If you have a limit of 2 tasks per person, you cannot start a third task until one of the first two is done. You are forced to focus. You are forced to finish. The mental overhead drops. The quality rises. The throughput stabilizes.

This is not just about engineering. It applies to design, marketing, and sales. A designer who is toggling between three different brand guidelines will produce inconsistent work. A marketer who is writing three different email campaigns simultaneously will produce generic copy. Focus is a finite resource. WIP limits are the guardrails that protect it.

How to set limits that actually work

Setting WIP limits is not a guessing game. It requires data. You cannot just pick a number because it sounds good. You need to look at your team’s actual capacity and your current bottlenecks.

Start by looking at your board. Identify the columns. Usually, you have To Do, In Progress, Review, and Done. The most important limit is on the In Progress column. This is where the work happens. If this column is full, no new work can enter. The team must pull from the To Do column only when there is space.

Here is a practical way to set the number:

• Count your people: If you have 5 developers, a good starting point for WIP is 5 to 7. This allows for some overlap and handoffs but prevents everyone from starting new tasks at once.
• Look at your cycle time: If your average cycle time is 3 days, and you have 10 items in progress, your lead time is 6 days. If you want to reduce lead time to 3 days, you need to reduce WIP to 5.
• Check for bottlenecks: If the Review column is always full, your WIP limit on In Progress is too high. You are creating work faster than you can review it. Lower the In Progress limit. If the To Do column is always empty, your limit is too low. Raise it.

In Anabatic, you can set these limits directly on your Boards. When a column hits its limit, it turns red. You cannot drag a new card into that column until you move an existing card to the next stage. This creates a visual and mechanical constraint. It stops the habit of hoarding tasks.

Do not set the limit for the whole team. Set it per person or per sub-team. A global limit of 10 for a team of 20 is useless. It allows 10 people to be fully loaded while the other 10 are idle. Individual limits ensure that everyone is accountable for their own flow.

Also, remember that not all tasks are equal. A small bug fix takes less mental load than a new feature. You can use story points or complexity tags to adjust your limits. If you are working on high-complexity items, lower your WIP limit. If you are churning through small fixes, you can raise it slightly.

What to do when you hit the limit

When your team hits a WIP limit, they will feel uncomfortable. They will want to start something new. New tasks are exciting. They offer a dopamine hit. Finishing old tasks is often tedious. It involves debugging, polishing, and dealing with edge cases. Your team will resist the limit.

This is normal. The limit is working. It is exposing the friction in your process. Instead of raising the limit, you need to investigate why the work is stuck.

Is it blocked by a dependency? Is it waiting for feedback? Is it too large to finish in a reasonable time? If a task has been in In Progress for more than two days, it is a signal. You need to swarm on it. Get the whole team to help finish that one task. Clear the blockage. Do not let it stagnate.

This is where when to split an epic becomes relevant. If a task is too large to fit within your WIP limit, it is too large. Split it. Break it into smaller, shippable chunks. A task that takes two weeks is a risk. A task that takes two days is manageable. Smaller tasks move faster. They provide more frequent feedback. They reduce the anxiety of the unknown.

If the task is waiting for review, assign a reviewer. Make it clear that reviewing is part of the workflow. If you are the only one who can review, you are a bottleneck. Cross-train your team. Distribute the review load. The goal is to keep the flow moving.

Use your Dashboards to track this. Look at the aging of tasks. If you see tasks sitting in In Progress for too long, drill down. Find the root cause. Is it a process issue? A skill gap? A tool limitation? Fix the root cause. Do not just raise the limit to hide the problem.

A real-world example from a product team

Let us look at a real example. A product team of 6 engineers was struggling with their release cycle. They were using an agile framework, but their sprints were always chaotic. They would start 15 stories in a two-week sprint. By the end of the sprint, they had finished 8. The other 7 were partially done. They would carry them over to the next sprint. The next sprint, they would start 15 new stories. The cycle repeated. The team was exhausted. The stakeholders were frustrated.

We implemented WIP limits in Anabatic. We set the In Progress limit to 6. One per engineer. We also set a Review limit to 3. This meant that only 3 items could be in review at any time. If the review queue filled up, the engineers had to stop coding and help with reviews.

The first week was painful. The engineers felt like they were doing less. They had idle time. They were anxious. But we held the line. We did not raise the limit. We used the idle time to refactor code, write tests, and improve documentation. We also used it to swarm on the stuck tasks.

By the second week, the flow started to smooth out. The engineers finished their tasks faster because they were not switching contexts. The review queue cleared quickly because the reviewers were dedicated. The team started finishing 10 stories per sprint. The quality improved. The bug count dropped by 30%. The stakeholders were happy because they saw consistent delivery.

The team learned a valuable lesson. Doing less at once allowed them to do more overall. They stopped measuring their success by how many stories they started. They started measuring it by how many they finished. This shift in mindset was crucial. It aligned with the principle of stop measuring output, start measuring lift. They were no longer chasing vanity metrics. They were chasing value.

The takeaway: finish what you start

WIP limits are a simple tool. They are not a silver bullet. They will not fix a broken culture or a poorly defined strategy. But they will expose the bottlenecks in your process. They will force you to focus. They will help you ship faster.

Start small. Pick one team. Set a limit. Watch what happens. Do not be afraid of the discomfort. The discomfort is a sign that you are changing. You are moving from a culture of starting to a culture of finishing.

Use Anabatic to enforce these limits. Use the Boards to visualize your flow. Use the Automations to alert you when limits are hit. Use the Gust AI assistant to analyze your cycle time and suggest adjustments. Make the data visible. Make the constraints clear.

Remember, the goal is not to be busy. The goal is to be effective. Finish what you start. Clear the pipe. Ship the work. That is how you build momentum. That is how you win.

If you are struggling with visibility into your progress, check out our analysis on the cost of a stale dashboard. And when things go wrong, make sure you have a process for a post mortem that focuses on learning, not blaming.