A build slips and your test window halves — how do you re-plan depth and scope mid-cycle?

### The first move is arithmetic When a build slips, the instinct is to promise the same coverage in less time. Resist it and compute. Take measured throughput from the cycle so far — not the rate the plan assumed — multiply by the working days that genuinely remain after the new build lands, and compare with the unexecuted remainder. An online bookstore checkout cycle baselined 418 cases over eleven days. On day six, 263 are executed at a measured 34 a day, and the build for the payment rework arrives four days late, leaving three days instead of six. Capacity is roughly 102 cases; the remainder is 155. The shortfall is 53 cases, and every conversation that follows is about which 53 and who agrees. Stating it that way changes the discussion from "can you go faster" to "here is what does not fit". It also gives you a number to renegotiate against if the date itself is movable. ### Depth versus breadth There are two shapes of cut and they fail differently. **Cutting depth** keeps every planned area but reduces how hard each is exercised: one representative pass instead of the full data-variation set, boundary values kept and mid-range repeats dropped, one configuration instead of four, one locale instead of six. Every area still yields an observation, so the cycle report can make a statement about all of them. What you lose is the chance of finding the defect that only the second or third variation would have surfaced. **Cutting breadth** drops whole areas. The areas you keep are covered properly; the areas you drop produce no information at all, and their status in the report is honestly "unverified". This is sometimes the better trade — an area unchanged by the build and rarely used may genuinely deserve zero minutes — but it turns into a real gap when the dropped area shares data or a code path with the changed one. The usual default is depth first, breadth only where an area has a defensible reason to receive nothing. In the bookstore example the payment rework itself argues the opposite way for one area: the tax-and-currency formatting path is precisely where the late change landed, so it keeps its full depth while the untouched catalogue-browse cases drop to a single pass. ### Re-ordering what remains A window that halved once can halve again. Order the surviving cases so that the highest-exposure paths execute first and anything with a long setup runs while the environment is warm. Move confirmation of recent fixes early, because a fix that fails re-test consumes a whole further round and you want to know on day one, not day three. Batch cases that share expensive setup so the fixed cost is paid once. And front-load the cases most likely to *find* something, because information arriving on the last afternoon rarely changes anything. ### Re-baseline the tracking This is the part that gets skipped. If the plan shrank from 418 to 365 cases, the burn-down must be redrawn against 365 with a note saying when and why, or the chart shows a team failing to hit a target that no longer exists. Progress reported against a stale baseline is worse than no chart: it is a chart that lies in a specific and confident direction. The dropped 53 do not vanish — they move to an explicit list of what this cycle will not cover. ### Make the trade visible Re-planning is not a private act of triage. The output is a short statement to whoever owns the date: capacity is 102 cases against 155 remaining; the cut is depth across five areas plus two areas dropped entirely; the consequence is that the receipt-formatting and refund paths get no observation this cycle. Then let the people who own the schedule choose between the shortened window, a later date, or accepting the gap. The mistake is quietly absorbing the slip — running fast, reporting a healthy pass rate against the old plan, and letting everyone believe the same testing happened in half the time. ### What separates a senior answer A junior answer says "prioritise". A senior answer produces the capacity number, names the shape of the cut and its cost, keeps the tracking baseline honest, and hands the residual decision to the person who owns it — with the un-run scope written down rather than implied.