Work in Progress (WIP) limits are curious things. Their core concept is paradoxical if you boil it down to its essence:
Get more done in the future by doing less right now.
A little counterintuitive, sure, but WIP limits are enormously powerful when put into action on an Agile marketing team.
When you sit down at your desk in the morning with a hot beverage, the list of things you could work on is practically limitless:
But if you start on one of those items, jump to the next one, rush off to a meeting, answer some emails, then start another project, and then the day is over, have you really done anything?
Not really.
WIP limits force you to finish something before you move on to something else, which makes them particularly useful on Agile marketing teams plagued by FOMO and ADHD and other irksome acronyms.
The goal of WIP limits, and really any limitations we place on our workloads, is to stop starting and start finishing.
By creating clearly defined limitations around how much work can be in any given state, we force ourselves to complete something before we can start something else. Let’s look at a content marketing example so you can see what I mean.
Our hypothetical team has four members: two full time content creators, one visual content specialist, and a content marketing manager.
Their simple workflow looks like this:
They’ve put WIP limits on each state their content passes through, which means if there are three pieces of content being created, as there are in the shot above, the team cannot start anything new until one of those pieces moves into the Review column.
It’s worth noting that these are fairly tight WIP limits.
Since there are four team members, and the board has a total WIP limit of 6 (3 Creating, 2 Review, 1 Publishing), nobody should be working on more than two things at once, with a preference for just one project at a time.
If you’re not comfortable starting with WIPs that low, that’s totally cool. You can start with something closer to your current situation and then slowly tighten things up as you get your workload under control.
In his book Why Limit WIP: We Are Drowning in Work, Jim Benson writes, “Limiting WIP is a simple, versatile tool, resulting in people examining their work, eliminating unnecessary tasks, and finishing valuable products faster. And that’s only the beginning.”
When we put a cap on the amount of work we’ll doing at any given time, he continues, “We optimize for throughput and quality, as opposed to utilization and politics...we are able to release more while doing less, simply because we are spending more time working and less time context-switching, politicking, status updating, and reacting to delay.”
In addition to all of these amazing benefits, here are just three of the many Agile marketing-specific WIP limit benefits:
Let’s say I have a major content project that will take me 20 hours to complete, but I’m also working on three or four other projects simultaneously.
Instead of focusing on my big project and getting it done in 2.5 days, those 20 hours get spread over several weeks as I jump back and forth among my various commitments.
In the meantime, nothing gets delivered, and our content marketing initiatives can’t gather any steam. These frequent stalls stymie the effectiveness of a content marketing initiative particularly badly, but they affect almost any kind of marketing campaign.
Think back on how many blog articles you’ve read that promised to be “the first in a three-part series” that never materialized. Does that broken promise make you trust the brand that runs the blog?
Of course not.
And how do you think their bosses feel about it?
Unmet deadlines and undelivered work erode audience trust, and that goes for external and internal audiences alike.
But clear, firm, and explicit WIP limits enforce completion, allowing us to keep our agreements with our audiences (and our bosses).
Delays in delivery reduce marketing’s effectiveness and damage trust, but let’s shift our perspective and look at things from a team point of view for a moment.
Here’s a different version of our hypothetical content team’s board:
In this example their WIP limits are much higher, and the bottleneck in their current workflow is painfully obvious.
They have eight pieces of content being created, four in review, and none in the publication process. Because their Creating and Review columns have both reached their WIP limit, no one can move a project from Creating to Review at this point, even if they finish a piece of content.
Clearly the team needs to stop starting new content and start finishing what they’re already doing by reviewing the content that’s been created and publishing as quickly as possible.
Only then can work resume its flow.
Without WIP limits and visual board of some kind, it’s much harder to get this kind of insight.
Even though nothing new is being published, everyone seems busy, so what’s a leader to do?
WIP limits create clarity and allow us to put our joint and individual efforts toward getting stuff done.
I hope you’re on board with the beauty and power of WIP limits at this point. They’re a very nifty Agile tool, but it’s important to remember that they work a little differently depending on what kind of team you’re on.
On a Scrum team, the Sprint acts as its own limiting factor. We have a set amount of time in which to work, and the team decides how much work it can complete within that timebox.
While this doesn’t explicitly demand that team members limit their work-in-progress, the number of projects available during the Sprint will be limited by time. When we combine this with a regularly updated burndown chart the team often pushes itself to complete work steadily throughout the Sprint:
If your team is scrambling at the end of every Sprint to get things done, you might consider a hybrid approach. Scrumban teams combine Sprint timeboxes with WIP limits (and other components of Kanban) to add a more explicit focus on finishing work before starting something new.
With Kanban, you’ll set your own state-specific WIP limits. In our first example, our imaginary content team chose 3 for their Creating state, 2 for their Review state, and 1 for their publishing state.
The first time you choose a WIP limit, you’re basically making an educated guess, so don’t worry about getting it right immediately.
It’s best to set things a little higher than you think you should and work down, especially if you’re just getting started with an Agile approach to marketing. Lower WIP limits may slow down your flow until you get the hang of things.
Scrum teams will sometimes end up with unplanned work that has to be incorporated into their Sprint, and Kanban teams will have extenuating circumstances that force them to violate a WIP limit.
Agile marketing happens in the real world, so sometimes our pretty systems get broken by reality.
If unplanned interruptions derail your Scrum team, be sure to document them in your burndown chart like so:
Then, in your retrospective, address the situation and decide if it warrants a change in planning your next Sprint. Should you leave more team bandwidth to deal with interruptions? Do you need to sit down with the person who brought in the interruption and explain its ramifications for the team’s output?
Kanban teams should flag any work item that causes them to break their WIP limit so it can be discussed in a retrospective too. Was it a one-time anomaly, or does the WIP limit need an adjustment? Have you made your work-in-progress policies clear to internal stakeholders, or did the person who brought in this work ignore them?
Whatever you do, don’t let a broken WIP limit slide by. It’s an important moment for process examination and improvement.
If you’re a solopreneur, freelancer, or one-person marketing machine, you’ve got a shot at making WIP limits work on your own (within a Kanban system, of course).
If you’re on a team of any size, however, you’re going to need some larger structural changes to support your newfound love of limiting WIP. Jim puts it this way:
Few workers feel they have the freedom to say “No” to any assignment given to them by a superior. Since they have no way of demonstrating that they are overloaded or need to focus on someone else’s priority, knowledge workers feel compelled to take on any work that comes their way.
Enthusiastically, they accept this additional work because they want to do a good job and they actually care.
This isn’t a bad thing, but if you can’t limit the incoming requests you have to deal with, your WIP limits will fail very, very quickly.
Our environment creates ambient WIP in the form of meetings, quick status update chats with colleagues, and the neverending pings of emails and chats. Each project you’re working on multiplies those interruptions, even if you’re tightly managing your own personal WIP.
Managers and leaders, that means it’s up to you to help your teams limit their work-in-progress. Become their protector, keep them from splitting their focus across too many projects, and their output will improve dramatically.
So, are you managing your Agile marketing workload with WIP limits? I’d love to hear what they are and how to stick to them in the comments!
