In plain English.

Given a few rates from your prior programs, the model projects two curves across the test window, total bugs found and total bugs fixed. You plot actuals against them daily. Divergence is caught at week 1, not week 4.

More important: if your developer-capacity is lower than your find rate, the model will tell you before the program starts. Dev-team-too-small is the single most common cause of system-test cycle slip. The model catches it every time.

Four things inside:

• Two daily rates (find, fix).
• Two headcount inputs (testers, developers committed to bug fixing).
• Cycle decay pattern (50% / 25% / 12.5% / …).
• Daily cumulative curves (the artifact you plot actuals against).

Bugs per tester-day × testers.

Bugs per day found = rate × testers. This is the maximum daily find rate the team can sustain.

Bugs per developer-day × developers.

Max bugs per day fixed = rate × committed. This is the ceiling on backlog burn-down.

Three plays. None of them good.

When find > fix and nothing changes, organizations end up in one of three places:

• Defer most bugs as minor. Release quality suffers, but the calendar holds.
• Extend the timeline. Costs balloon; downstream commitments break.
• Emergency shift developers from feature work to fix work. Feature backlog stretches; planning credibility drops.

All three are expensive. The model surfaces this before the program starts, where cheaper options exist.

Front-loaded. By design.

The canonical pattern assumes risk-ordered testing: highest-yield tests run first, later cycles mine a smaller fraction of the remaining defect population.

• Cycle 1, 50% of total.
• Cycle 2, 25% (half of what's left).
• Cycle 3, 12.5%.
• Cycle 4, 6.25%.
• Cycles 5–6, 3.1% and 3.0%.
• Acceptance, 0.12% (the residual).

The sum is 100%. Programs that don't match this shape usually have a scope problem (regression re-opens bugs) or a test-design problem (the same tests run cycle after cycle).

Your shape. Your signal.

Plateau in cycles 3–4. Same tests running repeatedly, add new scenarios, introduce exploratory sessions, rotate test responsibility across testers.

Two curves. Every status review.

• Cumulative bugs found (projected) vs. actual.
• Cumulative bugs fixed (projected) vs. actual.

The gap between found and fixed curves is the open-bug backlog, plotted as a third line, it tells you whether the program is tracking, bloating, or draining. Publish all three in every status review and in the test plan appendix.

Week 1 vs. week 2.

Metrics Part 3 whitepaper covers the full interpretation rule set. The curves are the trigger; the whitepaper is the playbook.

Typical versus your organization.

• Typical enterprise (2005-era data): 7–14 days from bug filed to bug closed.
• Over 21 days: process problem, triage latency, approval latency, retest latency. See Metrics Part 2.
• DORA-era continuous delivery: 3–7 days median, but higher variance because hard-to-reproduce bugs drag the tail.

Plot YOUR organization's distribution, not the 2,929-row sample. Calibration is yours. The sample is the methodology.

Estimate, find-side, fix-side.

1. Estimate total expected bugs first. Either a direct historical rate (bugs-per-developer-day × developer-days-until-test-entry) or a risk-weighted sampling estimate.
2. Populate the find side. Your team's measured rate from the last two programs. Industry range is a sanity check only.
3. Populate the fix side. Bugs per developer-day × developers committed. If find > fix, raise the flag now.

Verify, generate, plot.

4. Verify the cycle decay against your data. If prior programs show flatter decay (40 / 25 / 15 / 10 / 5 / 5), substitute. Any shape summing to 100% works.
5. Generate the daily curves. Publish in the test plan and in every status update so divergence is visible.
6. Plot actuals against projection, every status cycle. Below-projection at week 1 = readiness failure. Above-projection + flattening = scope creep or environment instability. Interpret fast, act faster.

Cycles become weeks.

Closure-period distribution matters more in CD because mean is lower but tail is fatter. The fat tail is what blocks releases.

Model, don't hope.

• Two rates and two headcounts set the whole cycle shape.
• Cycles decay geometrically. 50 / 25 / 12.5, for a reason. Your shape should match (or your test basis is unusual).
• Developer-capacity is the silent killer. Find > fix = growing backlog, every day.

Curves first. Arguments second.

• Plot actuals daily. Catch divergence at week 1, not week 4.
• Calibrate closure period against your org's distribution, not the 2,929-row sample.
• The model is method-agnostic. Waterfall, iterative, CD, same curves, different tempo.