WIP Limits for Creative Teams: Why Starting Less Ships More Work

A creative team with forty projects open and nothing shipping on time rarely has a talent or tooling problem. It has too much work in flight at once. Here is how to set work-in-progress limits that fit creative work, and what to measure while you tune them.

• Why more projects in flight means every project finishes later
• How to set a first limit and a rule for starting work
• The three numbers that prove it works: WIP, cycle time, throughput

The Arithmetic Nobody Does Before Saying Yes

Take three campaigns that each need ten working days of effort. Finish them one after another and they land on days 10, 20 and 30, an average of 20. Run them side by side, giving each a slice of every day, and they land on days 28, 29 and 30, an average of 29. Same team, same total effort, and nothing is finished until almost everything is. TechTarget's walkthrough of WIP limits uses the same arithmetic with software projects, and that is before counting the cost of switching between them.

Creative teams live inside this arithmetic. A request arrives, nobody says no, and a project starts. Forty open projects feels like momentum. It is forty queues.

What Switching Costs, and What Nobody Has Measured

Every switch has a price. Scrum.org's guide to context switching links it to more errors and less creativity, and names WIP limits as one of three ways to reduce it. Estimates of the penalty vary. Nave's Kanban guide cites at least 10% per switch, while DevOps.com contrasts roughly 5% overhead for focused work with 20% or more under heavy multitasking.

Treat those figures as an order of magnitude. They come from software and IT teams, and we found none that measure a creative studio directly. The direction is not in dispute: the more projects a person juggles, the more of the day goes to reloading context instead of making work.

Why Creative Teams Drift Into Overload

Starting is cheap. A brief lands, a stakeholder pings, and with generative tools a first draft exists within minutes. Nothing in the system slows the starts, which is part of why creative profusion moves the bottleneck to approval and why top-performing teams burn out first.

The Project Management Institute community's WIP wiki lists the habits that make it worse, and each will sound familiar: aiming for maximum utilization of people, treating each addition as "only one more small thing," answering a delay by starting more work, and not counting all the work. The same page warns that managers who push more work into the pipeline to use people fully end up slowing their teams down.

Little's Law, Translated for a Creative Studio

Nave explains that Little's Law connects the three numbers: cycle time equals work in progress divided by throughput. A studio that finishes five deliverables a week with forty in progress takes about eight weeks, on average, to take one from start to done. The same studio with fifteen in progress and the same five-a-week rate takes about three. Nobody works faster. Less simply waits.

One caveat: the calculation assumes throughput holds steady. It often rises when switching falls, but treat that as something to confirm with your own data, not something to promise up front.

Set the First Limit in Five Moves

1. Count everything. Define "in progress" as everything from accepted brief to final approval, including work waiting for feedback. The PMI wiki names not accounting for all work as an anti-pattern, and hidden work is what quietly breaks a limit.
2. Pick a starting number. Nave suggests two items per team member as a starting point. For creative teams, count deliverables or projects, not tasks. TechTarget recommends reviewing throughput and delays every two weeks and running small experiments, and the PMI wiki adds that experiments should stay small and isolated.
3. Limit the review stage on its own. TechTarget's example gives the code review column a single slot. In creative work the equivalent is approval, which is often the real constraint. Cap how many items can wait for review so the team cannot flood its reviewers.
4. Pull, don't push. Once a stage is full, nothing new enters until something leaves. Write the rule down so anyone can point to it.
5. Decide what happens to blocked work. Items waiting on client feedback still occupy a slot in practice. Mark them as blocked, keep them visible, and agree a number of days after which the blocker is escalated. This one is our recommendation, not a published rule.

Real emergencies need an explicit lane with a stated cost, not a quiet exception. Our guide to processing urgent creative requests without disrupting core sprints covers it.

Measure Three Numbers While You Tune

Track throughput (deliverables finished per week), cycle time (days from start to approval), and WIP (items in progress, plus the age of the oldest). TechTarget points out that measuring release time before and after introducing limits gives you evidence of what side projects and multitasking cost. Compare two-week windows, change one thing at a time, and keep the board in front of everyone.

When every project, its stage and its age sit in one view, as on the platform MTM builds, counting WIP is a lookup instead of a workshop.

Where WIP Limits Fall Short

Limits do not create capacity. If demand truly exceeds what the team can do, a limit moves the queue out of the studio, where it becomes visible. That is the point: it forces a decision about priorities, which is what a planning tool that manages priorities without fragmenting the team is for, instead of a silent overload.

Limits also work poorly when roles cannot swap. Nave recommends separate limits by role, through swimlanes, when team members cannot collaborate on the same items. And a limit cannot fix a vague definition of done: if work sits "in review" for weeks because nobody owns the decision, the limit will only expose it. Our piece on balancing resources and deadlines covers the planning side.

What to Change on Monday

Count what is open. Set a limit you can defend, even if it starts too high. Refuse the next start until something finishes, and review in two weeks with three numbers. The question to settle is how much work the team can carry before everything gets slower.

FAQ

What is a good starting WIP limit for a creative team? Nave's rule of thumb is two items per team member. Count deliverables or projects rather than tasks, then adjust every two weeks based on cycle time and throughput.

Do WIP limits slow down urgent requests? Not if urgent work has its own lane. Give it one slot, state its cost to the requester, and let it displace a planned item visibly instead of silently.

Should limits apply to tasks or projects? To the unit a stakeholder would call a piece of work: a deliverable or a project. Tasks inside it inherit the limit. Limiting tasks separately adds paperwork without changing flow.

How do we count work waiting on client approval? Count it, tag it as blocked, and track its age. If blocked items vanish from the count, the limit stops reflecting reality. If they stay with no trigger, they clog it. An escalation after an agreed number of days solves both.

How long before we see results? Plan for at least two review cycles, roughly a month. TechTarget suggests reviewing throughput and delays every two weeks and adjusting through small experiments. Compare cycle time before and after to see the effect.

Sources

• https://techtarget.com/searchsoftwarequality/tip/The-benefits-of-WIP-limits-in-Kanban
• https://www.scrum.org/resources/blog/how-measure-and-tackle-context-switching-practical-guide
• https://getnave.com/blog/?p=575
• https://devops.com/failings-multitasking/
• https://www.projectmanagement.com/wikis/295485/WIP-limits