01 — Sprint Cadence

The unit of the 13-month arc is not a month. It is a 2-week sprint. There are 26 sprints (S1–S26) from 2026-07-06 to 2027-08-06 with one buffer sprint absorbed into wedding season.

Sprints are how you convert 10–15 hrs/week of moonlight time into shipped rungs. They are also how you catch slippage early — a bad week is invisible, a bad sprint is a data point.

Why 2 weeks (not 1, not 4)

  • 1 week is too short for a shipping act. C++ builds are slow; a real 200-line project bleeds into a second weekend.

  • 4 weeks is too long to notice slippage. If you drift for 3 weeks and only wake up in week 4, that’s a whole rung lost.

  • 2 weeks = 1 shipping act per sprint = 26 shipping acts across the arc = 26 public artifacts by M13. That is your portfolio, one commit at a time.

Weekly split for a Zoho weekday + weekend

Target: 10–15 hrs / week, minimum floor 8.

Day

Slot

Hours

Notes

Mon

6:30 AM – 7:15 AM

0.75

Daily 30-min (see 04_daily_practice.md) + 15-min plan for the day

Tue

9:00 PM – 10:00 PM

1.0

Focused sprint work, single task

Wed

6:30 AM – 7:00 AM

0.5

Daily 30-min

Thu

9:00 PM – 10:30 PM

1.5

Focused sprint work

Fri

—

0

Protected rest. No C++. Do not touch the roadmap.

Sat

9:00 AM – 1:00 PM

4.0

Non-negotiable morning block. Deep work. Sprint core target.

Sun

10:00 AM – 1:00 PM + 8:00 PM – 8:30 PM audit

3.5

Deep work + Sunday audit

Total: ~11.25 hrs. Add 2–4 hrs of overflow on stretch weeks. Miss 1–2 hrs on slack weeks. Below 8 hrs for 3+ weeks = yellow flag (see slippage rules).

Sprint template

Copy this into a SPRINTS.md file at the roadmap root. Fill in at the start of each sprint (Sat morning of week 1).

# Sprint S<N>: <YYYY-MM-DD> → <YYYY-MM-DD>

Phase: P<n>
Current rung: <name>

## Targets (3 total)
- [ ] CORE:    <one thing that MUST ship this sprint>
- [ ] STRETCH: <one thing that would be great if core lands early>
- [ ] LEISURE: <one non-C++ thing — book, movie, family, hobby —
              this is not a reward, it is protected mental space>

## Lab-notebook entry
- [ ] At least ONE predict-then-measure entry logged in the notebook.

## Shipping act
- [ ] ONE commit pushed to public GitHub OR one post
      published (blog / X / r/cpp / LinkedIn). Even a 3-line
      README update counts if the code is real.

## Time budget
Planned: __ hrs   Actual: __ hrs   Delta: __

## Notes / carry-over
- ...

Sprint planning — Saturday morning of week 1 (30 min)

  1. Open the phase file for the current phase.

  2. Look at the rung you are on. Decompose it into 3–5 concrete tasks.

  3. Pick the CORE task — the one that, if it ships, makes the sprint a success even if nothing else lands.

  4. Pick the STRETCH — do not pick the second-most-important task. Pick something that only makes sense if core is done in week 1.

  5. Pick the LEISURE — write it down. If you don’t schedule non-work, work will eat it.

  6. Look at yesterday’s Sunday audit (07_motivation_sustainment.md). Any carry-over? Any flags?

  7. Write it in SPRINTS.md. Commit that file. That is the sprint’s opening shipping act.

Sprint retro — Sunday evening of week 2 (30 min)

# Sprint S<N> retro

## What worked
- <specific behaviour or setup>

## What broke
- <specific friction, timing, distraction, tooling>

## What I learned about my own brain this sprint
- <one line — this is the returning-dev calibration data>

## Slippage flag
[ ] Green  — core shipped, on-track
[ ] Yellow — core shipped but hours below 8, or shipping act late
[ ] Red    — core did NOT ship

## Next sprint
- Carry-over: <items to bring forward>
- Change one thing: <specific process tweak, not a wish>

Slippage rules

Green — core shipped, retro filed. Continue.

Yellow — core shipped BUT one of:

  • Hours < 8

  • Shipping act was skipped

  • No lab-notebook entry

Action: no scope change. Next sprint’s stretch becomes “catch the missed hygiene item.” Watch for a second yellow.

Two yellows in a row — promote to red. Run the red protocol.

Red — core did NOT ship. This is a real signal, not a failure identity. Do this, in order:

  1. Sunday audit (30 min quiet).

  2. Open 99_pre_mortem/README.md. Identify which of the 8 failure modes fired.

  3. Read the corresponding pre-mortem file.

  4. Cut the next sprint’s scope by 50%. If core was “finish P1.3 project,” next core is “finish half of P1.3 project.”

  5. Ship SOMETHING tiny within 7 days — a 20-line commit, a 100-word post. Restore momentum before restoring scope.

  6. If two reds in a row: pause 1 sprint. Full 2 weeks off the roadmap. Then restart the phase.

The 26 sprints — phase mapping

Sprint

Weeks

Phase

Notes

S1–S2

W1–W4

P0 refresh

HARD GATE: ship rung 1 by end S2

S3–S6

W5–W12

P1 modern C++ core

S7–S9

W13–W18

P2 DSA in C++

S10–S13

W19–W26

P3 systems + concurrency

S14–S16

W27–W32

P4 build/test/tooling

S17–S20

W33–W40

P5 C++ for ML/data

HARD GATE: rung 6 by end S20

S21–S23

W41–W46

P6 production systems

S24–S26

W47–W52

P7 capstone + signal

HARD GATE: 1 offer conversation live by S26

Wedding-season buffer: if S15–S17 (Nov 2026–Jan 2027) get eaten by weddings/family, S18 auto-becomes a catch-up sprint. Do not panic. Do not double-book. See 08_health_burnout.md.

Anti-patterns to avoid

  • The “just one more week” trap. If core did not ship at end of sprint, do NOT extend. Ship a partial version, retro honestly, and reset scope.

  • The 20-hour heroic sprint. Great feeling. Kills the next 3 sprints. Cadence beats intensity.

  • Sprint planning without retro. Retro is where calibration happens. Skipping retro is skipping the whole point of sprints.

  • Silent sprints. No commit, no post, no shared artifact = the sprint did not happen from a career-signal perspective. Even a bad ship beats a good private note.