Why label sprints by ISO week numbers at all
Sprint names like "Sprint 17" need a separate index that the team has to keep up to date. Sprint names like "W22 sprint" use the calendar itself as the index. Anyone with a calendar can place "W22" in time without looking it up, and the label survives reorganizations, tool migrations, and team handovers because it is anchored to the year, not to a particular tracker.
ISO 8601 makes this work because every week has a unique, globally agreed code. The ISO 8601 guide covers the rules; this page is about choosing how many of those weeks to bundle into a sprint.
One-week sprints (W22, W23, W24…)
One-week sprints turn the ISO week and the sprint into the same unit. The cadence is unmistakable: the week starts, the sprint starts; the week ends, the sprint ends. Planning is short, demos are short, retros are short, and everything shifts with the calendar without translation.
Where it shines. Short, sharp work where direction can change with each cycle: incident-response teams, customer-support engineering, content teams with a weekly publish day, marketing teams running weekly experiments. It also works for very small teams, where the overhead of longer planning would dominate the actual work.
Where it strains. Larger features that genuinely take more than a week. Forced into a one-week cadence, they fragment into deliverables that look like progress but feel like churn. Planning meetings, demos, and retros also stack up — five hours of meetings each week is meaningful overhead on a four-day working week.
Calendar feel. You will live close to the current ISO week number. Each Monday is a real reset. Holiday weeks always trim the sprint, sometimes brutally; some teams skip them and document the gap as "no W52 sprint."
Two-week sprints (W22–W23, W24–W25…)
Two-week sprints pair consecutive ISO weeks. Each sprint covers exactly 14 days, which divides 364 cleanly and produces 26 sprints in a normal year. The label is a range: "W22–W23 sprint." The shorter "W22 sprint" usually refers to the sprint that begins on W22.
Where it shines. The most common cadence in product engineering for a reason: enough room to deliver something that matters, short enough to keep feedback fresh. Demos and retros happen often enough to course-correct without dominating the calendar. Planning becomes a serious conversation rather than a check-in.
Where it strains. Work that is genuinely two weeks long always seems to spill three days into the next sprint. The "carry forward" line item on the planning template is one of the warning signs. The overhead is also still real: four meetings per cycle adds up to more than half a day of structured ceremonies in many teams.
Calendar feel. Even-week starts feel different from odd-week starts. Some teams pick a fixed parity ("our sprints always start on even ISO weeks") so the next sprint date is always trivially known. The 53-week ISO year breaks this parity once every five or six years and needs a small accommodation.
Three-week sprints (W22–W24, W25–W27…)
Three-week sprints pair three consecutive ISO weeks. They split the year into 17 sprints with one week left over, which forces a small, deliberate handling of the leftover week (usually a planning or recovery week between two sprints, or a slightly shorter final sprint of the year).
Where it shines. Work that benefits from a longer arc inside a single sprint — discovery-heavy product work, infrastructure changes, larger refactors — without committing to the heavy ceremony of a monthly cycle. Teams that found two-week sprints too rushed often land here.
Where it strains. Three weeks is long enough that the start of the sprint feels distant by week three. Without a strong mid-sprint check, work can drift in week two and panic in week three. The cadence also fits less neatly into quarterly planning, because 17 sprints do not match four quarters as cleanly as 26 do.
Calendar feel. The leftover week each year is the defining feature. Treat it as a feature, not a bug: a planning week, a learning week, or a "no-sprint" week between releases is often the most valuable week in the year.
Comparison at a glance
| Cadence | Sprints / year | Best for | Watch out for |
|---|---|---|---|
| 1 week | 52 (or 53 in an ISO 53-week year) | Support, content, small teams, fast experiments | Meeting overhead and feature fragmentation |
| 2 weeks | 26 | Most product engineering teams | Carry-forward creep and 53-week-year parity drift |
| 3 weeks | 17 plus a leftover week | Discovery, infrastructure, larger refactors | Mid-sprint drift and quarterly alignment |
Decision criteria
Pick by the questions below, in order. Stop at the first one that gives a clear answer.
- How quickly do priorities change? If priorities can flip every few days, choose one-week. Anything longer is wasted commitment time.
- How long is a typical "deliverable unit" for the team? If meaningful work units routinely take 7–10 working days, choose two-week. If they routinely take 12–18 working days, choose three-week.
- How heavy are the ceremonies? Heavier ceremonies (longer demos, more stakeholders) push toward longer cadences so the overhead amortizes. Lighter ceremonies allow shorter cadences without pain.
- How distributed is the team? Heavily time-zoned teams often pick two- or three-week sprints so that planning and demo can be scheduled in the same week without pressure.
- How important is parity with finance? If quarterly targets dominate, a cadence that divides 13 weeks evenly (one-week, or a one-week-and- two-week alternation) makes reporting easier.
Common mistakes
- Changing cadence too often. Cadence is the heartbeat of the team. Changing it twice a year erases the muscle memory of when planning, grooming, demo, and retro happen. Pick one and stay with it for at least two full quarters before reassessing.
- Hiding the cadence change inside a tool migration. Switching from a Jira project that ran two-week sprints to one that runs three-week sprints is two changes, not one. Sequence them.
- Treating ISO week numbers as Sprint IDs only. Cross-team dependencies need a date range, not a label. "W22 sprint" alone does not tell another team when they need to be ready. Pair the label with the Monday-Sunday range from the ISO converter.
- Skipping the leftover-week question for three-week sprints. Decide in advance how the 52nd week is handled. "We'll figure it out in December" is a recurring source of late-year chaos.
- Letting the 53rd ISO week destroy parity for two-week sprints. The parity ("our sprints always start on even ISO weeks") drifts when the year has 53 weeks. Document the one-time correction up front. The 53-week year guide explains the broader consequences.
A short setup checklist
- Pick a cadence using the decision criteria above.
- Decide which ISO week the first sprint of the year begins in.
- Set a fixed parity for two-week sprints (always even, or always odd).
- Pick a rule for the leftover week in three-week-sprint years.
- Pre-label sprints in your tracker for the entire year so the schedule is visible.
- Cross-reference each sprint label with its Monday–Sunday range; consider keeping a small year sheet on the wall using the year-in-weeks planner.
With the cadence chosen, the labels in place, and the leftover-week rule written down, the calendar does the work. Each ISO week tells the team where it is in the sprint without anyone having to ask.