There's a belief that showing up with a full plate means you're productive. In scrum, it usually means the opposite.
When teams take on too much work at once, too much Work in Progress (WIP), focus drifts, quality slips, and the sprint goal quietly becomes an afterthought. The frustrating part? The team is working hard. They're just not finishing much.
This is a common anti-pattern in scrum, and it affects every level of an organization, not just the team.
What does too much WIP look like?
You might recognize this scene: It’s mid-sprint, the board is full of items in the “In Progress” column, and yet nothing seems to be moving to “Done.” Team members are busy, hopping between tasks, waiting on blockers, and picking up new work rather than pushing through a hard problem. The sprint review is approaching, and the team is scrambling.
That’s too much WIP in action.
Some specific signs to watch out for:
- Confusion about priorities. When there are too many active items and no clear focus, team members aren’t sure what to work on next. They’re spending energy deciding to do the wrong things rather than doing the most important thing.
- Constant context switching. Every time someone switches from one task to another, there’s a mental cost. Multiply that across a team and a sprint, and a huge chunk of capacity vanishes—not spent on actual work, but lost to the friction of context switching.
- Partially done work piling up. Unfinished work at the end of a sprint multiplies the delay of value delivery. It rolls into the next sprint and crowds out what was planned. One item carries over, then two. Soon, the team is perpetually playing catch-up.
- Defects and shortcuts. When teams are stretched across too many items, corners get cut. Quality suffers because there isn’t enough focus to do work well.
The real cost of unfinished work
If there's one thing to internalize about WIP, it's this: long work queues don't result in more work completed. They result in more unfinished work.
An item that's 80% done delivers zero value to a customer. It also consumes the mental overhead of everyone who touches it: the context, the history, the "where were we on this?" conversation that happens every time someone picks it back up.
The lean principle at the heart of limiting WIP is called one-piece flow: finish one thing before starting another. The agile expression of this is simple and worth repeating.
Stop starting, start finishing.
It sounds obvious. It's genuinely hard to do, especially when pressure to appear busy is high or when blockers make it tempting to pick up something new. But teams and organizations that learn to live by this principle consistently deliver more value, with less stress.
How to avoid too much WIP
Understand actual capacity
Before a team can limit WIP effectively, they need an honest picture of how much work they can actually take on in a sprint. That means accounting for real availability: who's out, who has competing commitments, what carryover work is already taking up space. Capacity isn't theoretical; it's the team you actually have this sprint.
Start small, finish strong
The shift toward limiting WIP doesn't require a new tool or a new process. It starts with a team agreement: we will not start something new until something in progress is done. Pull items into the sprint one at a time. Focus collective energy on getting things to "Done" before expanding the work queue.
Reflect on what you're delivering
Teams that regularly review not just whether they finished things but what value those things delivered tend to feel less pressure to pile on more work. When stakeholders see consistent, quality delivery sprint over sprint, the conversation shifts from "why aren't you doing more?" to "keep doing what you're doing."
Limit WIP from the start
Sprint planning is one of the best places to intervene on WIP, before it becomes a problem. Use this checklist as a team to set yourself up for a focused sprint.
Step 1: Clear the board. Before anything else, confirm that items from the previous sprint are truly done, or make a conscious decision about what carries over and why.
Step 2: Know who's here (and who isn't). Account for time off, part-time availability, or competing commitments this sprint. Capacity is real; plan for the team you actually have.
Step 3: Align on the sprint goal first. Agree on what success looks like before pulling any items. The goal shapes the work, not the other way around.
Step 4: Pull items one at a time. Bring backlog items in one by one, asking: Does this support the sprint goal? Is it small enough to finish this sprint? Who will work on it? Stop pulling when the team's capacity is genuinely full, not when the backlog runs out.
Step 5: Check for dependencies. Does any item require someone outside the team? Flag it now, not mid-sprint.
Step 6: Do a final gut check. Look at everything you've committed to together and ask honestly: Can we finish all of this? If the answer is uncertain, remove something. A smaller sprint done well beats an overloaded sprint done halfway.
What a team with healthy WIP actually looks like
Teams that limit their WIP share a few things in common. Their sprint boards have fewer items moving, but those items actually reach "Done." Their retrospectives spend less time on what went wrong and more time on how to get even better. Their stakeholders stop asking why things are late because things stop being late.
Perhaps most importantly, the pace of work becomes sustainable. Not slower, but more focused. Team members know what they're working on, why it matters, and when it will be done.
Everyone on the team has a part to play in this. The scrum master helps the team see the pattern. Team members make the daily choice to finish something rather than start something new. The product owner supports focus by protecting the sprint goal from competing priorities. When the board fills up, and nothing is moving, anyone can ask the question that matters: what would it take to finish one thing before we start anything new?
Cut the chaos and focus on delivery
Recognizing that your team is overloaded is the first step. Fixing the systemic habits that lead to high WIP and wasted effort requires a shift in how you manage flow and efficiency. If you are ready to eliminate wasteful processes and help your team focus on finishing, explore our specialized courses:
Scrum Better with Kanban: Connect the two frameworks with concrete, practical tools designed specifically to limit WIP, visualize bottlenecks, and dramatically improve delivery speed.
Lean Software Development: Go straight to the root of efficiency. Learn how to identify the hidden waste in your pipeline—like handoffs, defects, and context switching—so your team only spends energy on what truly adds value.