Calculate work-in-progress limits for your pod based on team composition
Engineers writing feature code
Software Dev Engineers in Test
Manual or automation QA
UI/UX — participates in UAT review
Participates in development?
(doesn't affect WIP)
| Role | Count | In E? | In R? |
|---|
| Pod Configuration | Devs | SDET | QA | Designer | TL Codes | E | R | Dev WIP | Review WIP |
|---|
The foundational queuing theory formula. Reducing WIP is the most direct lever to reduce cycle time. If throughput stays constant and you halve WIP, you halve cycle time.
Parallel projects destroy productivity exponentially:
| Projects | Loss | Available |
|---|---|---|
| 1 | 0% | 100% |
| 2 | 20% | 80% |
| 3 | 40% | 60% |
| 4 | 60% | 40% |
| 5 | 75% | 25% |
Dominica DeGrandis recommends starting with team_size / 2 as a WIP baseline. This encourages pairing and collaboration while preventing the anti-pattern of every person working solo on separate items.
Beyond 3 parallel reviews, context switching degrades review quality significantly. Reviewers lose the mental model of what they're reviewing. Capping at 3 ensures thorough, thoughtful code reviews even on large teams.