What It Is
A planning cycle is a fixed, company-wide time period in which teams commit to specific work. When the cycle ends, work is evaluated, and the cycle resets.
The key features that distinguish real planning cycles from ordinary project management:
- Fixed duration — the cycle length does not expand to fit the work
- Explicit commitment — work is “bet on” at the start of the cycle, not continuously added
- Deliberate pause — between cycles, there is a structured period for reflection and replanning
- Company-wide cadence — all teams operate on the same rhythm, enabling cross-functional coordination
The best-documented implementation is 37signals’ Shape Up methodology: 6-week cycles followed by 2-week cooldowns. But the principle applies at any cadence and organization size.
Why It Works
Fixed cycles force real prioritization. When a cycle is 6 weeks and there are 12 weeks of ideas, someone has to decide which 6 weeks of work gets done. This decision — the bet — is the planning discipline. Companies without fixed cycles accumulate roadmaps full of “in progress” work that never ships because nothing forces the hard choices.
The cooldown is the mechanism that makes cycles work. 37signals’ 2-week cooldown between cycles is not vacation. It is where bugs get fixed, documentation gets written, and the next cycle gets planned. Without a structured pause, cycles collapse into continuous flow — and continuous flow means no forcing function for reflection. (Source)
Cycles create predictability for teams. When every team knows the rhythm — work for 6 weeks, reflect for 2 weeks, start again — teams can plan their own work, estimate what is possible, and communicate expectations to stakeholders. The unpredictable interruptions that break distributed team coordination reduce dramatically.
“Appetite” versus estimates changes the conversation. In traditional project planning, the question is “how long will this take?” In Shape Up, the question is “how much time is this worth?” The shift from estimation to appetite means teams scope work to fit the available time — not the other way around. (Source) This produces scoped decisions, not scheduling nightmares.
GitLab uses multi-horizon cadences. Their cadence structure (week, month, quarter, year, 3-year) creates nested planning cycles where each horizon is approximately 4x the previous. This prevents the common failure mode where short-term planning drives out long-term thinking. (Source)
Where It Fails
Cycles without real prioritization are just theater. If every team bets on whatever they were already planning to do, the cycle structure adds overhead without adding discipline. The value of cycles comes from the hard decision-making at the betting table — which work does NOT get done.
Cycles do not work if teams operate on different cadences. 37signals’ insight: “All teams operate on the same 6-week cadence.” (Source) When engineering is on 2-week sprints, marketing is on quarterly plans, and sales is on monthly targets, coordination between functions becomes a scheduling nightmare instead of a collaboration model.
Cooldowns get colonized by new work. The most common failure: the cooldown period fills with expedited features, stakeholder requests, and “just one quick thing” that destroys the pause. This requires deliberate enforcement — the cooldown is protected time, not slack capacity. [Inference — practitioner observation across cycle-using teams; not measured cross-company, but a known failure mode in Shape Up adoptions.]
Cycles are poor fits for continuous-service work. Customer support, operations, security response, and infrastructure reliability do not map well to discrete cycles. These functions need a parallel operating model. 37signals handles this by having product cycles and leaving operational functions to run on their own cadence.
Best Examples
37signals / Basecamp — 6-week build cycles + 2-week cooldowns. The Shape Up methodology specifies shaping (defining the work), betting (deciding which shaped work to build), and building (executing with full team autonomy). All teams on the same cadence. Six bets per year maximum per team. (Sources, Shape Up)
GitLab — Multi-horizon cadence: week, month, quarter, year, 3-year, with each level approximately 4x the previous. OKRs govern the quarterly level. Annual strategy reviewed by the executive group. The structure explicitly prevents short-term planning from crowding out longer-horizon thinking. (Source)
Doist — Heroes vs. housekeeping system within cycles separates deep feature work from maintenance work. This prevents the common problem where support load continuously bleeds into creative work, destroying the planned cycle focus. (Source)
Implementation Guide
1. Pick a cycle length and hold it. For product teams, 4–8 weeks is the practical range. 2 weeks is too short for meaningful shaped work. 12 weeks is too long before the next reflection point. Pick a length, commit to it for at least three cycles before changing it.
2. Add a cooldown. Even one week between cycles changes the dynamic. This is where you fix the bugs, update documentation, and plan the next cycle. Do not let it become a continuation of the previous cycle.
3. Run a betting table. At the start of each cycle, leadership reviews shaped pitches and explicitly bets on what gets built. Work not bet on does not get scheduled. This is the prioritization mechanism.
4. Use appetite, not estimates. Instead of asking “how long will this take?”, ask “how much time is this problem worth?” Then scope the solution to fit the answer. If a problem is worth 2 weeks, the solution should be completable in 2 weeks.
5. Enforce a same-cadence rule. Align all teams — or at minimum, all teams that coordinate regularly — to the same cycle. Mismatched cadences create permanent scheduling friction.
6. Write Heartbeats and Kickoffs. A one-paragraph summary of what the team accomplished (Heartbeat) and what they plan to tackle (Kickoff) at the end and start of each cycle creates organizational visibility without meetings. (Source)
Common Mistakes
Treating cycles as sprints with a different name. Sprints are 2-week time boxes in an Agile process that continues indefinitely. Planning cycles are more deliberate: they include a betting mechanism, a structured pause, and a philosophy of appetite over estimates. Renaming sprints “cycles” without changing the underlying model gets you nothing.
Skipping the shaping phase. Shape Up separates shaping (defining the problem and rough solution, identifying risks) from building. Teams that skip shaping and go straight to building in cycles are just doing sprints. The shaping phase is where the real planning value comes from.
Using cycles for maintenance work. Bug fixes, on-call rotations, and customer support do not benefit from cycle planning. They require continuous attention. Trying to force them into a cycle structure creates a false sense of control.
Not enforcing the cooldown. The pause between cycles is the most important and most frequently sacrificed part of the model. It requires active protection from the pressure to start the next cycle early.
Sources
- 37signals Employee Handbook: How We Work: https://basecamp.com/handbook/how-we-work
- Shape Up (37signals): https://basecamp.com/shapeup
- GitLab Cadence: https://handbook.gitlab.com/handbook/company/cadence/
- How Doist Works Remote: https://doist.com/how-we-work/how-doist-works-remote
Inferences
- The companies that use planning cycles most effectively all share one underlying discipline: they treat “what doesn’t get done” as an equally important planning output as “what does get done.” Cycles force this. Continuous planning avoids it. The value of cycles is not what they enable — it is what they prevent.
- The cooldown is structurally undervalued in most implementations. Companies that adopt the cycle structure but not the cooldown are just running longer sprints. The cooldown’s value is not rest — it is the forced moment of organizational reflection that prevents companies from accumulating technical debt, communication debt, and strategic drift without noticing.
Work with Alex
If your roadmap feels like a graveyard of “in progress” work that never ships, and your team operates on three different planning cadences that never align, Alex helps leadership teams design planning systems that actually produce shipped decisions.