A Kanban Queue of Eighteen Items Ready for Test
MediTrack is a Kanban team building a clinical-trial data capture system. Work items move from 'development done' to 'ready for test' and then to 'done'. The board shows 18 items in 'ready for test', a WIP limit of 5, and an average test wait time of 6 days. Two testers manually execute a 240-case regression suite for every release; releases occur every two weeks. Exploratory testing is skipped when the queue is long. Defects found in test often bounce between testers and developers because acceptance criteria omit audit-trail requirements. The team has automated 40 regression cases, but they are run only at release. The product owner wants predictable lead time and fewer late defects. A compliance auditor requires evidence that high-risk changes were tested. The team is considering raising the WIP limit and hiring a third tester.
1. Diagnose the flow problem using the board data and recommend changes. Evaluate raising the WIP limit versus hiring a third tester.
Read the worked answer
The board violates its own WIP limit: 18 items against a limit of 5. That queue is the bottleneck, and the 6-day test wait indicates work is arriving faster than it can be tested. Raising the WIP limit would make the queue larger and lead time worse; it treats waiting work as progress. Hiring a third tester adds capacity, but if batch size and late testing stay unchanged, the queue will refill and the underlying defect pattern remains.
Recommendations: enforce the WIP limit and stop starting new work when testing is full; swarm on the oldest items; reduce story and release batch size; include testing in the definition of done; automate the stable high-risk regression checks so they run at commit, not only at release; and involve testers in refinement so audit-trail criteria are written before development. Use a cumulative flow diagram to show where work accumulates. Hiring may be justified temporarily if the queue cannot be reduced, but only alongside flow changes; otherwise it masks the system problem.
2. Design a risk-based regression and exploratory testing approach that reduces the 240-case suite while giving the auditor evidence that high-risk changes were tested.
Read the worked answer
Start with a risk assessment: clinical impact of failure, likelihood of defect, frequency of change, regulatory exposure, and security. Score each functional area and map the 240 cases to those risks. Many cases will be redundant or low risk.
A workable split: automate roughly 80-100 stable, high-risk checks to run at commit or nightly; retain about 30-40 manual high-risk checks for release, especially audit-trail, role permissions, data integrity, and electronic-signature behaviour; retire or fold duplicate cases into these. Add exploratory charters for areas where scripts are weak, such as audit-trail completeness across workflows and unusual data entry. Record charter, time, coverage, findings, and reviewer.
For the auditor, keep the risk assessment, traceability from high-risk requirements to automated and manual tests, execution evidence, defect records, and exploratory session notes. Reducing the suite is defensible only if the rationale and coverage of high-risk areas are documented; do not simply cut the number.
3. Which metrics and governance should the team use to improve predictability without creating misleading incentives?
Read the worked answer
Track lead time from commitment to done, test wait time, WIP against limit, throughput, and the age of items in the test queue. Add quality measures: escaped defects, late defects found in test, audit-trail defects, regression-suite flake rate, and risk coverage by automated versus manual checks. Avoid ranking testers by defect count or rewarding the number of automated cases, which encourages volume over value.
Govern by reviewing the cumulative flow and blocked items weekly, not by status meetings. Make the definition of done explicit, including audit evidence for high-risk changes. Have a named compliance liaison review sampling and traceability each release. Use retrospectives to adjust WIP limits and automation priorities. The goal is predictable flow and documented risk coverage, not maximising the number of test cases executed.