Sprint Cadence — The 2-Week Rhythm¶
Sprints are not deadlines. They are heartbeats. Miss one, you notice. Miss three, you’re in trouble.
Why 2-Week Sprints¶
Two weeks is long enough to build something real and short enough to course-correct before you’ve gone too far off track. One-week sprints create too much overhead. Monthly sprints create too much rope to hang yourself with. Two weeks is the cadence.
Sprint Template¶
Week 1: Learn + Experiment¶
Day |
Focus |
|---|---|
Mon–Tue |
Core concept intake — read, watch, take notes |
Wed |
First implementation attempt — code from scratch |
Thu |
Debug, run experiments, log in lab notebook |
Fri |
Paper or reference implementation review |
Weekend |
Optional deep work on sprint deliverable |
Week 1 output: Lab notebook entries for at least 3 experiments. Working (even if broken) code started.
Week 2: Build + Write + Reflect¶
Day |
Focus |
|---|---|
Mon–Tue |
Complete implementation; make it runnable end-to-end |
Wed |
Write the explanation (blog post draft, README, or Obsidian note) |
Thu |
Polish, test, commit to GitHub |
Fri |
Sprint review — complete the retrospective template below |
Weekend |
Sprint start ritual for next sprint (Sunday evening) |
Week 2 output: Committed artifact on GitHub. Written explanation. Completed retrospective.
Sprint Start Ritual (Sunday Evening, 30 Minutes)¶
Run this every other Sunday before a new sprint begins.
SPRINT START CHECKLIST
======================
[ ] Review previous sprint retrospective (5 min)
[ ] Set 3 sprint deliverables — be specific (10 min)
Deliverable 1: ________________________________
Deliverable 2: ________________________________
Deliverable 3: ________________________________
[ ] Check KPI dashboard — where are you vs. plan? (5 min)
[ ] Block study time in calendar for the next 14 days (5 min)
[ ] Write one sentence: What will I understand in 2 weeks that I don't understand now?
________________________________________________________________
[ ] Open lab notebook, create new sprint entry (5 min)
The entire ritual takes 30 minutes. If you skip it, the sprint drifts. If you do it, the sprint has a spine.
Sprint End Ritual (Saturday Afternoon, 45 Minutes)¶
SPRINT END CHECKLIST
====================
[ ] Demo to yourself — run the code, show the outputs (10 min)
[ ] Write lab notebook sprint summary entry (10 min)
[ ] Commit everything to GitHub — no "I'll do it tomorrow" (5 min)
[ ] Complete the retrospective template below (20 min)
Sprint Retrospective Template¶
Max 20 minutes. Answer these 6 questions. Don’t overthink them.
SPRINT [NUMBER] RETROSPECTIVE
Date: ________________
Sprint topic: ________________
1. WHAT DID I SHIP?
(List what actually exists and is committed. Not what I planned — what I built.)
________________________________________________________________
2. WHAT DID I LEARN THAT SURPRISED ME?
(One thing I predicted incorrectly and had to update.)
________________________________________________________________
3. WHERE DID I LOSE TIME?
(Specific: "I spent 3 hours debugging a CUDA version mismatch" — not "I got distracted.")
________________________________________________________________
4. WHAT SHOULD I DO DIFFERENTLY NEXT SPRINT?
(One behavioral change. Specific and testable.)
________________________________________________________________
5. AM I ON THE PHASE SCHEDULE?
[ ] Ahead [ ] On track [ ] 1-2 weeks behind [ ] >2 weeks behind
If behind: ________________________________________________________
6. IS MY MENTAL/PHYSICAL STATE SUSTAINABLE?
[ ] Yes, fine [ ] Tired but manageable [ ] Warning: need rest [ ] Red: invoke recovery protocol
Notes: ___________________________________________________________
Sprint Slippage Rules¶
Slippage is measured against your sprint plan at the end of Sprint Week 2.
Slippage Level |
Definition |
Action |
|---|---|---|
Green |
< 30% of sprint deliverables incomplete |
Absorb. Roll incomplete items into next sprint. No protocol change. |
Yellow |
30–60% of sprint deliverables incomplete |
Adjust. Descope next sprint. Identify root cause in retrospective. Check if pattern. |
Red |
> 60% of sprint deliverables incomplete |
Trigger Reset Protocol. See 99_pre_mortem/09_summary_and_reset_protocol.md |
One Yellow sprint is normal. Two consecutive Yellow sprints = structural problem. Three or more = Red.
Buffer Sprint Rules¶
4 buffer sprints are allocated across 13 months. They are already in the master plan.
What a Buffer Sprint Is¶
A full 2-week period with no new learning objectives. You use it to:
Complete items that spilled from previous sprints
Take a genuine rest (recommended for at least 1 of the 4)
Consolidate understanding before a major phase transition
Handle life interruptions without panicking
When to Use a Buffer Sprint¶
USE A BUFFER SPRINT WHEN:
[ ] You are carrying > 3 weeks of accumulated slippage
[ ] You just completed a major phase (Foundations → Core Algorithms, etc.)
[ ] A significant life event has disrupted your rhythm for > 1 week
[ ] Your lab notebook shows no genuine surprises in 4 consecutive weeks
(means you're going through motions, not actually learning)
[ ] Your quality metrics are declining while hours are increasing
(a sign of fatigue, not laziness)
When NOT to Use a Buffer Sprint¶
Because you’re mildly tired (that’s normal — keep going at reduced pace)
Because a new paper dropped and you want to explore it (use the 2-hour frontier scan)
Because you feel “behind” without checking the actual metrics
Important: Using all 4 buffer sprints means the plan is working as designed. Not using them means you’re either superhuman or lying to yourself.
Sprint Tracking Template¶
Copy this into your lab notebook or Obsidian at the start of each sprint:
SPRINT TRACKER
==============
Sprint #: ____
Dates: ____ to ____
Phase: ____
Roadmap Month: ____
PLANNED DELIVERABLES:
1.
2.
3.
HOURS LOGGED:
Week 1: _____ hrs
Week 2: _____ hrs
Total: _____ hrs (target: 20-30 hrs)
COMPLETION STATUS: Green / Yellow / Red
Buffer sprint needed? Y / N
NEXT SPRINT PREVIEW:
Topic: ____
Key risk: ____