As anyone working in engineering, software, or product development knows, work in progress limits (or WIP limits) determine the maximum amount of work allowable for each sprint or period of work. Limiting WIP is a common best practice in Agile development processes that allows teams to adapt to change.

When a team exceeds its WIP limits for a specific work period, each in-progress item must be swarmed on and quickly finished before any new items can move into that status.

While this is straightforward enough in theory, it’s harder in practice. Shiny new projects can tempt teams into initiating new work before meeting their definition of done on existing projects, creating bottlenecks and inefficiencies.

At its core, WIP limits are about committing to a culture of shipping work—because teams that ship are teams that innovate and drive meaningful results for their business. So if you’re struggling with bloated Kanban boards and a traffic jam of incomplete work, consider this your guide to getting your WIP under control.

But first:

Why do you need WIP limits?

Explaining the need for limiting WIP can be summed up simply with a common Agile mantra: Stop starting and start finishing.

WIP limits do more than simply encourage teams to complete work that's already in process before introducing more work into the system. WIP limits also provide an effective way for you to:

• Identify ongoing inefficiencies and bottlenecks: Implementing Kanban WIP limits is a great way to reveal wastefulness and oversights in your workflow. With WIP limits in place, an excess amount of cards within a column will expose any existing (or potential) bottlenecks causing excessive context switching that’s slowing your team down.
   
• Clear the pipeline to help prevent multitasking: Multitasking is impossible, yet remains a pervasive myth that costs organizations time, money, and accuracy in completing tasks. By shifting focus to another task before completing the first one, teams often lose momentum. WIP limits keep active tasks manageable by prioritizing finishing what you started. 
   
• Deliver added value quickly to your customers: Limiting WIP not only makes your team more efficient—it improves the quality and quantity of usable product you can get in front of your customers. By reducing the amount of active work on your Kanban board, you can improve your delivery rate (or throughput) to help meet customer expectations or regular releases.
   
• Create balance between idleness and overload: Kanban WIP limits give your team a sense of consistency by maintaining the ideal work pace and not exceeding that capacity. Limiting WIP becomes a safeguard for ensuring that unfinished work doesn’t pile up, and people start only as many tasks as they can finish.

Realizing the benefits of limiting WIP is only the beginning. The next step? Setting up WIP limits.

How to determine WIP limits

Limiting WIP will require experimentation on your part. Whether you’re overly cautious or not exercising enough restraint, there’s a good chance mistakes will be made. That’s okay.

WIP limits are easily changeable. Take time to track your results and regularly assess what works during sprint retrospectives.

Two factors to consider when limiting WIP are the number of people on your team, and how many tasks are necessary to work on at once. Best practices vary by organization, but a general guideline for setting a WIP limit is to fall within the range of:

• Your team size plus one, and
• Your team size multiplied by two

So for a team of 10 people, your WIP limit should fall somewhere between 11 (10+1) and 20 tasks (10x2).

Remember, setting work in progress limits is a work in progress in and of itself. Plan to iterate until you land upon what WIP limits work best for your team. Then get their buy-in on the WIP limits you’ve outlined. Give your team two weeks to follow your suggestion before changing.

During this initial period, take note of what’s going on while limiting WIP for the first time:

• Are tasks continually piling up or is the team underwater? WIP limits are probably too high.
   
• Is there too much inactivity or complaints about not enough work? WIP limits are probably too low.
   
• Are projects getting finished and new tasks moving ahead? You’re on the right track.

Reevaluate as needed and stay in constant contact with your team to get a feel for WIP limits. When initiating a new workflow, try to get a team consensus on appropriate WIP limits for each column on your Kanban board.

If breakdowns become consistent, either your WIP limit is too restrictive or something is wrong with the process itself. Once you’ve got a baseline for limiting WIP, the next part is implementation.

How to implement WIP limits on your team

Carrying out WIP limits means applying them to your Kanban board with the understanding that workflows are dynamic in nature, don’t live in a vacuum, and are likely to change accordingly. Kanban WIP limits, like any Lean practice, should maximize customer value and eliminate waste.

Monitoring variables like new business requirements, changing demands, unexpected technical issues, and fluctuating team size or capacity is key to successfully implementing any WIP limits. 

WIP limits involve a process of continuous improvement. Like most new activities, limiting WIP won’t come naturally to most teams. However, this short-term awkwardness is not only normal, but a good thing. Experiencing those pain points is part of defining a team's WIP limits.

Implementing, visualizing, and observing WIP limits are even easier if everyone can access your Kanban board online—especially when you oversee a hybrid or remote team.

Besides providing a high-level view of a project, virtual, collaborative Kanban boards allow everyone to easily see the status of all the components in the workflow. If someone is waiting for a team member to finish a task before they can work on the next thing, they can check the status of the colleague’s work from anywhere and in real time.

Other strategies to employ when implementing WIP limits on your team include:

• Sizing individual tasks in a consistent manner: When you break down user stories and requirements, it’s critical to keep individual tasks to no more than 16 work hours. Using this guideline helps team members estimate WIP limits with accuracy and confidence.
   
• Base WIP limits on the skill sets of your team: If your team is composed of specialists with different expertise, WIP limits will vary. This means you’ll need to create statuses specific to each work specialty. Let the team know how this will affect overall capacity.
   
• When limiting WIP, course correct if necessary: Even with consistent finetuning, WIP limits don’t always apply. When team members experience downtime, look for ways they can help someone else upstream or downstream in the workflow to keep up productivity.
   
• Maintain Agile engineering practices: Implementing WIP limits should not be a reason for developers to needlessly rush through work simply to avoid task overload in a particular Kanban board column. The quality of the product or code base comes first.

Building a culture that ships

If your organization is pretty good about time management, or you have an experienced team that doesn’t tend to get overwhelmed with tasks, WIP limits might seem pointless. Adhering to WIP limits is still worthwhile, as it essentially gives teams permission to focus and become more proficient by unifying their entire efforts on a smaller amount of tasks.

Over time, limiting WIP will give your team the ability to isolate and eliminate some of the more costly (and hidden) sources of waste within your organization and its workflow process. Although setting up WIP limits can seem tedious, counterintuitive, and unnecessary at first, ultimately they become essential for determining your team’s true potential and helping everyone work better together.