Milestone map
Milestone map
3 milestones
Baseline Cycle Time and Identify Bottlenecks
2 weeks
Measure your team's current pull request cycle time (time from first commit to merge) and produce a breakdown by stage: coding time, review-waiting time, review time, and revision time. Use at least four weeks of historical PR data (minimum 50 PRs). Identify the top two bottlenecks with evidence — the stages where time is concentrated. Document the measurement methodology and present findings to the engineering team, soliciting their hypotheses about root causes.
Proof required
Submit the cycle time analysis (data visualisation or structured table showing median and 90th-percentile times per stage, based on at least 50 PRs over 4+ weeks), plus notes from the team presentation showing root-cause hypotheses raised by the team.
What gets checked
- Analysis covers at least 50 PRs over at least four weeks — smaller samples are unreliable
- All four cycle time stages are measured — not just total PR open-to-merge time
- Top two bottlenecks are named and supported by data — not guessed
Common mistakes
- Analysis uses too few PRs or too short a window — results don't reflect steady-state behaviour
- Only total cycle time is measured — stage-by-stage breakdown is what surfaces the actual bottleneck
- Team presentation is skipped — root-cause hypotheses come only from the submitter's perspective
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Ask the submitter to state the current median and 90th-percentile cycle time and which stage is the primary bottleneck
- Confirm the analysis covers at least 50 PRs over at least four weeks
- Check that root-cause hypotheses came from the team presentation — not just from the submitter
Implement Two Process Changes and Measure Impact
6 weeks
Select two specific interventions targeting the bottlenecks identified. Each intervention must have a clear theory of change (what behaviour changes, what measurement improves). Implement both changes — examples include: PR size caps with automated labelling, review assignment protocols, async review time windows, reviewer availability tracking, branch policies, or CI gate optimisation. Run both interventions for at least six weeks and produce a before/after measurement comparison.
Proof required
Submit the theory-of-change document for each intervention (one page per intervention), the implementation notes (what was changed, when), and the six-week before/after measurement comparison for both interventions. The engineering team must confirm both changes were implemented.
What gets checked
- Each intervention has a documented theory of change — not just a description of what was done
- Before/after comparison covers the same four cycle time stages as the baseline
- Engineering team confirmation is from a named engineer or tech lead — not the submitter alone
Common mistakes
- Only one intervention is implemented — the second bottleneck is acknowledged but not addressed
- Before/after measurement covers only total cycle time — stage-level improvement is not visible
- Interventions are implemented but theory of change is written post-hoc — not a genuine experiment
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Ask the submitter to explain the theory of change for one intervention — what behaviour was supposed to change and did it?
- Confirm both interventions ran for at least six weeks — not abandoned after two
- Ask what the before/after numbers show — a specific improvement (or lack of improvement) should be nameable
Achieve and Sustain a Measurable Improvement
8 weeks
After the interventions, demonstrate a sustained improvement in PR cycle time over at least eight additional weeks. The improvement must be statistically meaningful — a reduction of at least 20% in median cycle time or a specific agreed target. Produce a sustainability plan documenting how the improvement will be maintained (what monitoring is in place, what triggers a review if cycle time regresses). Present the results to engineering leadership.
Proof required
Submit the eight-week post-intervention cycle time data showing sustained improvement, the sustainability plan, and notes from the engineering leadership presentation confirming the results were reviewed. The improvement must show at least 20% median reduction versus baseline.
What gets checked
- Eight weeks of post-intervention data is presented — not just the first two weeks after the change
- 20% or greater median cycle time reduction versus baseline is demonstrated with data
- Sustainability plan names a specific monitoring trigger — what number causes a review?
Common mistakes
- Improvement is measured immediately after intervention but not sustained — Hawthorne effect not ruled out
- Improvement is less than 20% but framed as success — the target was not met but is not acknowledged
- Sustainability plan is written but monitoring is never actually set up
Resources
Foundationstart here
What a verifier looks for
- Ask the submitter to state the baseline median cycle time and the current median — the improvement must be specific
- Confirm eight weeks of post-intervention data exists — not a snapshot
- Check the sustainability plan has a named monitoring trigger — not just 'we'll watch it'