Two teams, one test environment: limiting a shared constraint
Two feature teams (7 and 6 people) at a payments company deliver into one shared integration-test environment. It has two test lanes and completes about 8 items per week when healthy, but is unavailable roughly one day in five for resets and data refreshes. Team A produces about 5.5 testable items per week and Team B about 5.5. A single shared 'Ready for Test' queue holds 38 items; the oldest is 24 working days old and nobody owns the ordering. Each team keeps its own 'In Test' column, so 11 items are officially in test against two lanes. Releases are fixed to every fourth Friday. Test engineers describe themselves as 'always firefighting' and prioritise whoever escalates loudest; Team B's engineering manager has begun asking her developers to test in production behind a feature flag.
1. Where should WIP limits sit in this system and what values would you start with? Show the arithmetic.
Read the worked answer
Start from the constraint. Nominal test capacity is 8 items a week at 80% availability, so effective capacity is about 6.4 items a week against combined upstream arrival of about 11 - a structural deficit of roughly 4.6 items a week that no amount of local efficiency can absorb.
In Test: a limit equal to the lanes, 2, with a third slot allowed only for an item in setup or teardown if that genuinely does not consume a lane. Eleven items 'in test' on two lanes means most of them are actually waiting, which corrupts both the board and the metric.
Ready for Test: a limit belongs here too, and this is the critical design decision. Limiting only the working column leaves an unbounded queue that absorbs the mismatch invisibly. Size the queue to cover variability rather than to hold everything: a limit of 8 gives an average queue wait of roughly 8 divided by 6.4, about 1.25 weeks, which is defensible against a four-week release train. A queue of 38 gives an average wait near six weeks and guarantees items age out before they are tested.
Upstream: the teams' combined WIP must be throttled so that combined arrival does not exceed 6.4 a week. Where upstream cannot slow down, it should switch to work that does not need the environment - test design, data preparation, verification.
The constraint itself: the 20% downtime is lost throughput at the bottleneck and deserves its own improvement owner; recovering half of it is worth about 0.8 items a week, more than any local tweak upstream.
2. Should the shared test queue be managed as a continuous kanban or as a replenishment system? Justify the choice.
Read the worked answer
Use queue replenishment for the shared queue, with continuous kanban inside each team's own flow.
The reasoning is structural: a queue with two supplying teams and one constrained server cannot be governed by each supplier pushing work in. When both teams add to a shared queue independently, ordering is decided by whoever arrives last or escalates loudest - priority inversion by design. Replenishment converts that into a pull: the test activity consumes a slot, and at a fixed cadence the queue is refilled to its limit in an agreed order by a named owner.
What that buys in this situation:
- A real order based on a written rule - release-train items first, then FIFO by age, with a capped expedite class for production incidents - instead of escalation.
- A visible capacity decision. When the queue is at its limit, the replenishment meeting must decide what not to admit, which is where the two teams negotiate capacity rather than in production.
- Predictability for the fixed release. Items needed for the fourth Friday are admitted early enough to be tested; today they compete on equal terms with everything else.
- Less hidden WIP. The flag-based production testing becomes unnecessary as a workaround once the queue has a credible wait time; make it a time-boxed exception under risk review if it is kept at all, because it is untested work entering the value stream.
Keep the replenishment cadence short - twice weekly fits a 6.4-per-week throughput - and re-check the queue size whenever capacity or team output changes.
3. Write the allocation and escalation policies the test environment needs, and say how you would measure whether they are working.
Read the worked answer
Allocation. Reserve one lane per team as a baseline, with an explicit borrowing rule: a team may use the other lane only if the owning team is not ready, logged on the board so borrowing is visible and reversible. This prevents both the free-for-all and the deadlock of hard partition. During the release window, lanes are allocated by release-train membership rather than by team.
Ordering and classes of service. Release-critical items (fixed date, tied to the fourth Friday), expedite (production incident, capped at one concurrent item, approved by the on-call lead), standard (FIFO by age), and intangible (cost-of-delay based). Reclassification requires the approver named in the policy, and reclassifications are counted.
Readiness and completion. Definition of ready for test: build green, test data available, no open P1 defect, environment needs declared. Definition of done for test: evidence recorded against the item, environment reset checklist complete. Both are written on the board.
Escalation. Escalation is a class-of-service change, not a conversation with a test engineer. Anything that cannot move is flagged same day, owned, and taken to the operations review if older than three days.
Measures. Queue age p50 and p85; test throughput per week against the 6.4 baseline; environment availability; percentage of release-train items that were tested before the freeze; count of expedites and reclassifications; wait time split by class. Review monthly and change one policy at a time, so you can tell which change moved the numbers.