As much as everybody loves to talk about the importance of solid business strategy or proper discovery, at the end of the day, execution is everything.
It doesn’t really matter how great your idea is if you can’t ship it fast enough. Better execution leads to faster go-to-market, thus faster learning, thus better product. No amount of discovery or strategic work can replace actually putting the product in front of users and seeing how they react.
For this reason, various delivery tactics, strategies, and “hacks” have gained popularity. Among these, work-in-progress (WIP) is one of the most widespread ones.
Let’s dig deeper into what WIP limits are and why they’re so popular.
To better understand WIP limits, let’s first cover what work in progress actually is. In short, one could define WIP as anything that you’ve started, but haven’t finished yet.
To put it in context, if a developer coded a new feature and the pull request is waiting for the code review from another team, the work is still “in progress.” Although you might not be actively working towards the project, it still occupies your team’s mental capacity because they have to remember and follow up on the topic.
As the name suggests, WIP limits how much work can be in progress simultaneously.
Those limits can be enforced by software (for example, having Jira limit the number of tickets in a given status) or just informally agreed upon by the team:
There’s more than one way to embrace work-in-progress limits in agile development. On a high level, you can differentiate WIP limits based on:
From this, you’ll have four common WIP limit configurations:
Since I believe in a team’s cross-collaboration, I’m a proponent of team-based limits. My approach is to start with global WIP limits to get the hang of things, see how particular delivery metrics stabilize, and then take the learnings and implement more precise, status-based limits.
You might be thinking to yourself, why would one artificially limit the amount of work your team can pick up? At first, it might even sound counterproductive. Yet, there’s a solid case for limiting work in progress.
There’s no bigger productivity killer than multitasking, especially in digital product development. Constant context-switching simply consumes too much time and energy.
Multitasking doesn’t necessarily mean working on multiple things at the same time, but having multiple open loops at the same time. Say you have three tickets in QA and one in development. Although you are actively working only on one ticket, you must constantly talk with QA, fix bug fixes occasionally, and answer potential questions and doubts. That requires lots of mental effort.
By limiting the overall work in progress, you naturally limit this context-switching.
Having work-in-progress limits to follow means you can’t just say that something is blocked and pick up a new task as easily.
Instead, team members are forced to more proactively engage with their peers by:
Collaboration flourishes when there’s a solid incentive to unblock the work faster. Trust me, there’s no better cure for constant “blocked” items than WIP limits.
With thirty tickets in the QA column, it’s hard to predict whether you’ll get all of them as a single batch the next day or receive none of them for the next two days. Tracking the work becomes messy.
However, with stricter, smaller limits, key delivery metrics such as time in status, cycle time, and lead time tend to stabilize and become more predictable, which makes the whole execution process significantly more predictable.
Work-in-progress limits force you to take a closer look into each step of the end-to-end workflow, and if you use per status limit, it helps you spot where the bottleneck actually is.
Most importantly, WIP limits force you to proactively work on those bottlenecks. Normally, if, for example, a code review takes a couple of days to complete, you can just ignore it and start working on new work items. However, with work-in-progress limits, it’s not as easy and you often have to stop and focus on resolving the code review bottleneck.
WIP limits give extra pressure and incentive to actually work on bottlenecks and improve the delivery process.
Last but not least, after the initial aversion to change is gone, teams tend to be happier and less stressed with WIP limits.
Imagine being QA and having thirty tickets in the “ready for testing column.” WIP limits force the team to build a sustainable process that avoids stressful situations like this.
Although there’s no silver-bullet solution for WIP limits, there are a few universal rules worth following when starting with WIP limits for the first time.
Before implementing any type of WIP limit, start with understanding the current state of things by asking yourself:
These will not only help you identify adequate limits, they’ll also help you track if you actually improve and determine which areas are slowest to catch up.
The general consensus is to start with lenient WIP limits and make them stricter as you improve. If your average WIP count is 30, making the WIP limit five is a recipe for disaster. As a rule of thumb, make your first WIP limit 20 percent stricter than your average WIP count and review monthly.
Create some basic guidelines for “what should happen if […].” For example, how should team members behave if they can’t pull a new work item and are blocked?
I once had a developer that did nothing for two days “because there was a WIP limit he couldn’t cross,” yet he didn’t escalate that in any way.
The exact limits, procedures, and principles should come from team collaboration. Explain to the team how WIP limits can make their life easier and enhance learning and improvement and then establish a starting point together.
If you just come to the team and slap a set of new rules, they might become defensive and perceive WIP limits as a new way to micromanage their work.
Work-in-progress limits can be a great tool with numerous benefits. However, they also have challenges. Some factors that can make it hard to maintain WIP limits are:
I won’t go into detail about how to tackle each of these challenges. Instead, there’s one single solution for all of them — common sense.
I firmly believe that WIP limits should work as an important guide in helping the team inspect, adapt, and manage their work and processes, not as a non-negotiable limitation.
The truth is that agile development is unpredictable. My teams tend to break WIP limits half of the time. However, each time we do so, we cover these cases in retrospectives and see if there was a process problem, a people problem, or an unexpected case.
Don’t allow yourself to become a hostage to a process that’s supposed to help you.
Limiting your team’s WIP is a great way to strengthen team focus, enhance collaboration, improve predictability, and identify bottlenecks in the product delivery process.
Start by collecting key delivery metrics, such as cycle time, time in status, and average WIP count, to establish an initial benchmark and define meaningful limits. Begin lenient (as a rule of thumb, I start with a global WIP limit 20 percent below the current average) and make the limit stricter over time. Remember to set some guidelines for what should happen if the team hits the limits and make sure to make the process as collaborative as possible.
Although WIP limits come with their own set of challenges, most of them are easily resolved by simply embracing common sense and breaking the limits if needed. WIP limits should serve as a guideline that helps the team in the inspection and adaptation process, not super strict rules that slow everyone down.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
An IPT isn’t just another team; it’s a strategic approach that breaks down unnecessary communication blockades for open communication.
Learn more →
