kanban

Start with WIP limit equal to team size minus one for each stage. For example, a four-person development stage gets a limit of three. Adjust downward if items stall or context switching increases, and raise slightly if the team has idle time.

Look for columns where work items accumulate faster than they exit. A stage consistently at or above its WIP limit while downstream stages starve indicates a bottleneck. Address it by adding capacity, reducing upstream WIP, or changing batch policies.

Lead time measures request to delivery from the customer perspective, while cycle time measures work started to done, reflecting team efficiency. Little's Law connects them: lead time equals WIP divided by throughput.

Avoid lowering WIP when the team already has idle time or when limits are so tight that collaboration and swarming become impossible. WIP limits should expose bottlenecks, not starve the workflow of parallelizable work.

Yes. Kanban pairs with Five Whys to find root causes of bottlenecks, hypothesis trees to investigate flow problems, and cognitive load principles to justify WIP limits based on context switching costs.