Milestone map
Milestone map
3 milestones
Measure cycle time and find bottlenecks
2 weeks
Measure your team's pull request cycle time, from first commit to merge. Split it into four stages: coding, waiting for review, review, and revision. Use at least four weeks of history and at least 50 PRs. Name the two stages where most time goes, with data. Present the findings to the team and collect their ideas on root causes.
Proof required
Submit a chart or table of median and 90th-percentile time per stage. Base it on 50+ PRs over 4+ weeks. Add notes from the team presentation listing their root-cause ideas.
What gets checked
- At least 50 PRs over at least four weeks.
- All four stages measured, not just total time.
- Top two bottlenecks named and backed by data.
Common mistakes
- Too few PRs or too short a window. The numbers won't reflect normal weeks.
- Only total time is measured. The stage breakdown is what shows the bottleneck.
- The team session is skipped. Root causes then reflect only your view.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Ask for the median and 90th-percentile cycle time, and the main bottleneck stage.
- Confirm the data covers 50+ PRs over 4+ weeks.
- Check the root-cause ideas came from the team session, not only the submitter.
You'll sign in first, then come straight back here.
Run two process changes and measure
6 weeks
Pick one change for each bottleneck. For each, write what behaviour should change and which number should improve. Examples: PR size caps with automatic labels, or review assignment rules. Others: set review windows, reviewer availability, branch policies, or faster CI. Run both changes for at least six weeks. Then compare before and after.
Proof required
Submit a one-page plan per change: what should change and why. Add implementation notes with dates. Add the six-week before-and-after comparison. A named engineer or tech lead confirms both changes went live.
What gets checked
- Each change has a written plan made before it started.
- Before and after use the same four stages as the baseline.
- A named engineer or tech lead confirms the changes, not the submitter alone.
Common mistakes
- Only one change is made. The second bottleneck is noted but left alone.
- Only total time is compared. Stage-level change stays invisible.
- The plan is written after the fact. Then it isn't a real test.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Ask them to explain one plan: what should have changed, and did it?
- Confirm both changes ran for six weeks, not two.
- Ask what the comparison shows. They should name a specific result, good or bad.
You'll sign in first, then come straight back here.
Sustain a measurable improvement
8 weeks
Show the improvement holds for at least eight more weeks. Median cycle time must drop at least 20% from baseline, or meet an agreed target. Write how you'll keep it: what you monitor, and which number triggers a review. Present the results to engineering leadership.
Proof required
Submit eight weeks of cycle time data after the change. It must show a median drop of 20% or more. Add the upkeep plan. Add notes from the leadership review.
What gets checked
- Eight weeks of data after the change, not two.
- A median drop of at least 20% from baseline, shown with data.
- The upkeep plan names the number that triggers a review.
Common mistakes
- The gain is measured right away but not held. Novelty alone can cause it.
- The drop is under 20% but called a success. Say the target was missed.
- The upkeep plan is written but monitoring is never set up.
Powstik Guide
Eight weeks of data showing a 20%+ median drop.
Steps
- Keep measuring the same way as baseline.
- Plot weekly median cycle time.
- Compare with the baseline median.
- Document how the change is maintained.
Template
Baseline median: New median: Change: | Week | Median cycle time | |------|-------------------| Upkeep plan:
What gets sent back
- Under eight weeks.
- Drop under 20%.
- Measurement changed.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Ask for the baseline median and today's median. The gap must be specific.
- Confirm eight weeks of post-change data exists, not one snapshot.
- Check the upkeep plan names a trigger number, not just 'we'll watch it'.
You'll sign in first, then come straight back here.
Part of