I’m coaching in an organization new to agile practices. This challenges my assumptions, like explaining practices I’ve taken for granted. Recently, a dialogue unfolded:
Me: You’re doing a lot at once here… Product Owner: Yes, but we’ve promised to finish a lot by [date]. Me: Why not limit your work in process (WIP)? It speeds things up… PO: What do you mean? We can’t limit work. We must complete this [pointing to board] now, as fast as we can.
I realized I missed explaining WIP (work in process) and why stakeholders aren’t concerned about it.
First, what’s a WIP limit? It’s a team agreement on how much work to take on at once. It’s flexible and guides our work to flow smoothly.
In Scrum, teams commit to work for a sprint, ensuring balance and commitment. WIP limits serve the same purpose—controlling how much work to take on at once. It triggers discussion when exceeded.
Little’s law states more work slows each item. WIP limits prompt discussions on whether to accept new work, balancing speed and quality.
Kanban allows us to always say “Yes.” By doing less simultaneously, each item completes faster, offering more decision points and agility.
WIP limits focus on discussion triggers, enhancing flow and preventing overload.
Limit WIP doesn’t mean less work done
Limiting WIP sets a cap on simultaneous work, not total output. It helps work flow faster and manage more items concurrently.
Externally, stakeholders prioritize features and quality, not WIP limits. They want results quickly and reliably.
Conclusion
WIP limits aren’t strict rules; they spark discussions and improve workflow.
Limiting WIP doesn’t mean less total work; it means managing less simultaneously.
Stakeholders focus on results, not internal team practices.