How to Set Up Cycles in Linear (Duration, Cooldown, and Rollover)

Cycles are configured per team, not per workspace. Open Settings, pick the team under Teams, and go to Cycles. Turn cycles on. Because each team has its own schedule, a platform team can run two-week cycles while a growth team runs one-week cycles. Decide this deliberately: if teams frequently hand work to each other, aligned start days make cross-team planning much easier.

• Open Settings and select the team you want to configure
• Open the Cycles section and enable cycles
• Check whether other teams already run cycles and note their start day
• Agree with adjacent teams on whether to align schedules

Linear lets you pick the cycle length in weeks and the day the cycle starts. Two weeks is the common default, but one-week cycles work well for teams shipping small increments with frequent releases, and longer cycles suit teams with heavier integration or QA work. Pick a start day that does not collide with your release day; starting on Monday and releasing on Thursday or Friday gives a clean planning-then-ship rhythm.

• Pick a duration that matches how long a typical feature slice takes to ship
• Choose a start day that avoids your release and on-call handoff days
• Set how many upcoming cycles Linear should create in advance so you can plan ahead

A cooldown is a gap between cycles where no cycle is active. Teams use it for bug fixing, tech debt, exploration, or simply to plan the next cycle without the current one bleeding into it. If your team constantly ends cycles with half-finished work and starts the next one already behind, a short cooldown is often a better fix than shorter cycles. If you skip the cooldown, schedule planning inside the last day or two of the cycle instead.

In the same settings, Linear offers options to automatically add issues to the active cycle when they move into a started or completed state, and to move unfinished issues into the next cycle when a cycle ends. Auto-add keeps the cycle an accurate record of what the team actually worked on, including unplanned work. Rollover saves manual cleanup, but it can hide chronic overcommitment, because nothing forces a conversation about why an issue slipped twice.

• Enable auto-add for started issues so unplanned work shows up in the cycle
• Enable rollover of incomplete issues if you want Linear to carry work forward
• Agree on a rule for issues that have rolled over more than once, such as re-scoping or moving back to the backlog

Open the upcoming cycle from the team's Cycles page and pull issues in from the backlog. Use estimates if your team has them enabled; Linear shows the total scope of the cycle so you can compare it with what the team completed in recent cycles. Keep the cycle anchored to one or two outcomes, and resist filling every slot. A cycle loaded to 100% of past throughput leaves no room for bugs or review cycles.

• Filter the backlog by priority and project to find candidate issues
• Drag or assign issues into the upcoming cycle
• Compare total estimated scope to what the team completed in the last few cycles
• Leave headroom for bugs, review feedback, and interrupts

The cycle view shows a graph of scope against started and completed work over time. A rising scope line mid-cycle is the clearest signal of scope creep. A flat completed line for the first half of the cycle usually means work is too large or blocked in review. Check the graph at standup a couple of times a week rather than only at the end, when it is too late to adjust.

When a cycle closes, look at what was completed, what rolled over, and what was added after the start. These three numbers tell you more than velocity alone. If added scope is consistently high, your intake process needs work. If rollover is consistently high, the team is overcommitting or issues are too large. Use the review to adjust the next cycle's commitment, not to assign blame.