We’ve recently transitioned to Kanban but our flow is constantly getting stuck at the testing phase. I’ve heard about Work In Progress (WIP) limits, but I’m struggling with how to set them without making the team feel micromanaged or idle. What are the best practices for identifying the right WIP numbers to ensure a smooth cycle time as our project scope begins to scale up?
3 answers
Setting WIP limits is more of an art than a science, Sarah. A common starting point is the "n-1" or "2n" rule, where n is the number of team members in a specific stage. The goal isn't to keep everyone busy 100% of the time, but to keep the work moving. If testing is your bottleneck, lower the WIP limit on the preceding "Development" stage. This forces developers to stop pulling new tasks and instead help the testers clear the backlog. It’s about optimizing the whole system rather than individual performance. Monitor your cumulative flow diagrams to see if the gap narrows over time.
Have you considered if the bottleneck is due to unclear "Definition of Done" criteria before items hit testing? If the quality varies, testers spend more time on re-work than actual verification.
Focus on the "Stop Starting, Start Finishing" mantra. Lowering WIP limits creates a healthy pressure to resolve blockers immediately rather than ignoring them for new work.
Totally agree, Amanda. It shifts the team culture from a push system to a pull system, which is the core essence of a mature Kanban implementation.
That is a great point, Robert. If the "Definition of Done" is lax, the "Testing" column becomes a graveyard for half-finished work. We actually implemented a peer-review checklist before any card moves out of development. This reduced our testing cycle time by nearly 30% because the bugs were caught earlier. It’s worth checking your hand-off quality.