01 — Sprint Cadence

The unit of work in this plan is not the day. It is the two-week sprint.

Days are noisy. Some days a bug at work eats your evening. Some days your mother wants you to come over for dinner. Some days the AC breaks in a June heat wave and you cannot think. Sprints smooth all of that out. Over 14 days, you either shipped what you said you would ship, or you did not. That signal is honest.

You get 26 sprints. That is 52 weeks of active work plus 4 weeks of buffer, spread across 13 months. Below is the mapping.

The 26 Sprints (July 2026 → August 2027)

Sprint

Weeks

Approx. dates

Anchored to

S1

W1-W2

Jul 2026 (early)

M1 — Fundamentals refresh, dev env, first 15 programs

S2

W3-W4

Jul 2026 (late)

M1 — Programs 16-35, collections, I/O

S3

W5-W6

Aug 2026 (early)

M2 — Programs 36-50, phase 1 project

S4

W7-W8

Aug 2026 (late)

M2 — DSA warmup, arrays + strings on LeetCode

S5

W9-W10

Sep 2026 (early)

M3 — DSA: linked lists, stacks, queues, hashing

S6

W11-W12

Sep 2026 (late)

M3 — DSA: trees, BFS/DFS

B1

W13

Oct 2026 (early)

Buffer week — Q1 recovery

S7

W14-W15

Oct 2026 (mid)

M4 — DSA: graphs, DP, tie off at ~100 problems

S8

W16-W17

Oct/Nov 2026

M4 — OOP + SOLID refactor project

S9

W18-W19

Nov 2026 (mid)

M5 — Design patterns catalogue, small implementations

S10

W20-W21

Nov/Dec 2026

M5 — Modern Java: streams, functional idioms

S11

W22-W23

Dec 2026 (mid)

M6 — Generics deep dive, Optional, records

S12

W24-W25

Dec 2026 (late)

M6 — Streams project

B2

W26

Jan 2027 (early)

Buffer week — Q2 recovery

S13

W27-W28

Jan 2027 (mid)

M7 — Concurrency: threads, executors, futures

S14

W29-W30

Jan/Feb 2027

M7 — Concurrency: locks, java.util.concurrent, virtual threads

S15

W31-W32

Feb 2027 (mid)

M8 — JVM internals: memory model, GC, class loading

S16

W33-W34

Feb/Mar 2027

M8 — Profiling: JFR, async-profiler, JMH benchmarks

S17

W35-W36

Mar 2027 (mid)

M9 — Spring core, Boot basics, layered app

S18

W37-W38

Mar/Apr 2027

M9 — Spring Data, JPA, transactions

B3

W39

Apr 2027 (early)

Buffer week — Q3 recovery

S19

W40-W41

Apr 2027 (mid)

M10 — REST API project, testing (JUnit 5, Mockito, Testcontainers)

S20

W42-W43

Apr/May 2027

M10 — Security basics, observability, dockerize the API

S21

W44-W45

May 2027 (mid)

M11 — Distributed: messaging (Kafka), caching (Redis)

S22

W46-W47

May/Jun 2027

M11 — Integration project, contract tests

S23

W48-W49

Jun 2027 (mid)

M12 — Capstone build (start)

S24

W50-W51

Jun/Jul 2027

M12 — Capstone build (finish + deploy)

B4

W52

Jul 2027 (mid)

Buffer week — Q4 recovery

S25

W53-W54

Jul/Aug 2027

M13 — Portfolio polish, resume, mock studies

S26

W55-W56

Aug 2027

M13 — Job/internal-move conversion, final talk/blog

The dates are approximate. Shift them by a week if S1 does not start on a Monday. The pattern matters more than the calendar.

Sprint Template (Copy This)

At the start of every sprint, spend 30 minutes writing this in a file called SPRINT_S{N}.md inside 13_MONTH_ROADMAP/13_discipline/log/:

# Sprint S{N} — {start_date} to {end_date}
# Anchored to: M{month} — {month theme}

## Goals (max 3, ranked)
1. …
2. …
3. …

## Deliverables (concrete, checkable)
- [ ] …
- [ ] …
- [ ] …

## Not doing this sprint (explicit non-goals)
- …
- …

## Time budget
- Weekday sessions planned: __ / 10 (weekday slots in 2 weeks)
- Weekend sessions planned: __ / 4
- Total hours target: __

## One sentence: what does success look like?
> …

Two rules for the goals list:

  • Max 3 goals per sprint. If you need 4, it is 2 sprints. Overpacking a sprint is the single most common way this plan fails at the process level (see 06_failure_modes.md F7).

  • Goals are outcomes, not activities. “Finish concurrency chapter of Java Concurrency in Practice” is an activity. “Write and benchmark a ConcurrentHashMap vs Collections.synchronizedMap comparison and publish the results” is a goal.

Sprint Planning Checklist

Before the sprint starts, walk through this in order:

  • Read last sprint’s retro

  • Read the current month’s README from the technical directory (e.g. 05_concurrency_multithreading/README.md)

  • Pick 2-3 goals from that README’s deliverables

  • Write the sprint file (template above)

  • Block calendar: weekday sessions, weekend deep-work slot, sabbath day

  • Write one specific micro-goal for tomorrow morning (the “first hour” hook)

  • Push the sprint file to git

Sprint Retro Template

On the last day of each sprint (Sunday works well) spend 20-30 minutes writing this at the bottom of SPRINT_S{N}.md:

## Retro

### Shipped
- …

### Slipped
- … (why? one honest sentence per item)

### What I got wrong (predictions vs reality — see 02_lab_notebook.md)
- …

### What surprised me
- …

### Health check
- Sleep avg this sprint: __ hrs
- Sessions completed: __ / __ planned
- Days with zero work: __
- Body: (energy, eye strain, anything hurting)

### Next sprint focus
> One sentence.

Do not skip the retro. The retro is where the calibration happens. Without it, you are just doing sprints with no feedback loop, and the whole cadence system collapses into an activity list.

Slippage Protocol

You will slip. Everyone slips. What matters is what you do next.

Slippage of 1-3 days within a sprint: Normal. Ignore. Adjust the remaining days.

Slippage of a full weekday session: Note it in the sprint file. Do not “make it up” on Sunday. Sunday is off (see 08_health_burnout.md).

Slippage of 3+ weekday sessions in one week: Warning. Check the failure modes file (06_failure_modes.md) — usually F2 (work load), F5 (shiny object), or F6 (isolation). Downshift the sprint scope. Do not extend the sprint.

Slippage of a full sprint goal: The goal moves to next sprint. Only one carry-over goal is allowed. If two goals slip, one gets dropped, not carried.

Slippage of 2+ full sprints: Reset protocol. See 99_pre_mortem/09_summary_and_reset_protocol.md.

The core rule: sprint boundaries are fixed. Sprint scope is variable. You never move the sprint end date to fit the work. You move the work to fit the sprint.

The Four Buffer Weeks

The four buffer weeks (B1-B4, one per quarter) exist for exactly three purposes:

  1. Recovery — if the previous 6 sprints ran hot, take the week light.

  2. Catch-up — if a sprint slipped, pull the slipped goal into the buffer.

  3. Reflection — a quarterly-review post, resume update, portfolio cleanup.

Do not use buffer weeks to “get ahead.” Getting ahead is a mirage. The cadence has 26 sprints, not 27, and if you use a buffer week to add more scope, you have nowhere to fall back when work explodes in the next sprint.

If a quarter went well and you don’t need catch-up or recovery, use the buffer week for reflection: write a quarterly retro blog post, update the resume, tidy the portfolio README.

When Life Explodes

If life explodes (family emergency, health scare, work crisis), you do not “power through.” See 08_health_burnout.md and 99_pre_mortem/08_fm_life_and_health.md. There is a formal pause protocol. The plan waits.

Next: 02_lab_notebook.md Previous: README.md