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. Its published cadence spans week, month, quarter, year, three years, ten years and thirty years, with adjacent horizons roughly three to five times apart. (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.
Coordinate dependencies across cadences. 37signals documents a shared six-week build cadence. [Inference — implementation guidance.] Other functions may need different rhythms; define handoffs and review points rather than assuming that a single cadence is necessary in every organization. (Source)
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 — A multi-horizon cadence from weekly work to thirty-year mission, with quarterly OKRs and longer planning horizons. This is a nested set of horizons, not one shared build cycle for every function. (Source)
Todoist (formerly Doist) — Its September 2022 accountability article describes 1–5-person DO squads and objective cycles lasting one to six months, plus monthly reflection and end-project async retrospectives. The current onboarding guide still references DOs and cycle planning; the precise present cadence is not established by the publicly readable pages. (Accountability, onboarding)
Linear — Its October 2025 planning account describes continuous development of candidate projects, prioritized against customer demand, revenue impact and quarterly goals. Configurable cycles and optional cooldowns in the product do not establish a mandatory internal cycle for every Linear team. (Company planning, product settings)
Buffer — Its August 2026 Build Week is a dated example of a company-wide learning/building event, not evidence of a permanent cadence. (Source)
Implementation Guide
1. Pick a cadence for the work. [Inference — implementation guidance.] Test a fixed cadence long enough to evaluate delivery and coordination. The examples here support several approaches; they do not establish a universally optimal four-to-eight-week range.
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
Compare the mechanisms behind the cadence. In Scrum, Sprints have a fixed length of one month or less. Shape Up adds its own shaping, betting and cooldown practices. [Inference — implementation guidance.] Compare these mechanisms explicitly rather than assuming that renaming a Sprint a cycle changes how work is selected or reviewed. (Scrum Guide, Shape Up)
Skipping the shaping phase. Shape Up separates shaping (defining the problem and rough solution, identifying risks) from building. [Inference — implementation guidance.] Adopting its cycle length alone does not reproduce that preparation; assess how work is defined and selected. (Source)
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.
Related Frameworks
- Sync vs Async Decision Matrix — choose a communication mode for the work
- The 20–30 Person Fracture Point — a working hypothesis about coordination needs during growth
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
Todoist accountability (September 2022): https://async.twist.com/accountability-remote-workers/
Todoist onboarding: https://handbook.todoist.net/s/6ca6f66e-2d02-4e05-b629-b1c772f5ff23
Linear internal planning (October 2025): https://linear.app/now/continuous-planning-in-linear
Linear cycle configuration: https://linear.app/docs/use-cycles
Buffer Build Week (August 2026): https://buffer.com/resources/build-week-2026/
Scrum Guide 2020: https://scrumguides.org/scrum-guide.html
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.