Linear Cycles are time-boxed iterations of one to eight weeks, enabled per team, that skip most of the ceremony built into Jira sprints: no manual “start sprint” step, no carry-over wizard, no release binding. Unfinished issues roll forward automatically, and a cooldown window sits between cycles for retros and backlog work.
I’ve run this across four teams and roughly sixty cycles, two of which failed badly enough that we nearly reverted to plain kanban. Most Cycles content online either repeats Linear’s marketing or invents features that don’t exist. I’ve seen guides describe a “priority-based Autopilot” that auto-rolls urgent issues and flags others for triage. That’s not a real Linear feature. All unfinished work rolls to the next cycle the same way, regardless of priority. Forget that if you’ve read it, before it costs you a confused retro.
Cycles vs. sprints: what’s actually different
The mechanical similarity is real: both are fixed windows where a team commits to scope and reviews it at the end. What changes day to day is smaller than the marketing suggests.
A Jira sprint requires clicking “Start Sprint” and, at close, walking through a completion wizard asking what to do with every unfinished ticket. Linear skips that. Cycles generate on schedule once enabled, and at close, any issue not in a completed or canceled state rolls forward without anyone touching it. There’s no per-issue decision. That’s a feature until your team stops treating “the cycle ended” as a meaningful event, because nothing forces the conversation.
The other real difference: cycles aren’t tied to releases. A sprint in most Jira setups implies “we ship at the end of this.” A cycle is just a planning window — what ships and when is a separate conversation, usually handled through Projects. Teams that import their Jira mental model wholesale keep waiting for a “cycle ships” moment Linear was never built to produce.
For a deeper look at ceremony overhead differences, see our Jira vs. Linear comparison.
Enabling and configuring cycles
Cycles are off by default and enabled per team, so a workspace running five squads can have five different cadences. Here’s the actual configuration path.
- Open Team Settings > Cycles for the specific team — not a workspace-level setting.
- Toggle Enable cycles. Linear walks you through required settings with defaults filled in.
- Set “Each cycle lasts” to a number of weeks between 1 and 8. Two weeks is default and right for most product teams.
- Turn on Cooldowns after each cycle for a buffer where issues can’t be assigned to any cycle. Retros and grooming happen here without competing against active delivery. Linear enforces this structurally — issues literally cannot be added to a cooldown.
- Pick a starting day of the week. Cycles begin at 12:01 AM in your team’s timezone. Monday is the sane default; a mid-week start fragments your standup rhythm.
- Set the number of upcoming cycles to pre-generate (up to 15), controlling how far ahead issues can be assigned.
Two things worth knowing before you touch anything else. You cannot run varying cycle lengths on one team — every cycle is the same duration by design. Sub-teams also inherit the parent team’s cycle schedule: past cycles stay put when a team is designated a sub-team, but future cycles snap to the parent’s cadence.
Choosing cycle length: why two weeks is default
Two weeks works for most teams because it’s long enough to finish something a user would notice, and short enough that a bad planning call only costs ten working days before correction. That’s the actual tradeoff, not tradition.
One-week cycles suit high-frequency, low-uncertainty work — a growth team running experiments, a team clearing a steady stream of small bugs. I ran one-week cycles with a five-person growth team and it was the right call; the same cadence on a platform team doing infrastructure migrations would have burned a disproportionate share of the week in planning meetings relative to output.
Four-week cycles fit platform and infra teams where task lead time is genuinely longer — a database migration doesn’t decompose cleanly into two-week chunks without artificial checkpoints. The failure mode at four weeks: scope drift is harder to catch. If priorities shift in week two, you carry a stale plan for two more weeks. I’ve never seen six or eight weeks work well outside research-heavy teams that aren’t really doing sprint-style delivery.
Planning your first cycle from velocity
Linear shows a capacity dial on cycles that haven’t started, calculated from the velocity of your last three completed cycles — issue count or estimate points, depending on your settings. With no cycle history, Linear estimates capacity roughly from headcount, which is a placeholder, not a number to plan against.
Once there’s real history, I pull completed totals from the last three cycles and plan to roughly the average, not the best of the three. Teams that plan to their best cycle are assuming every future cycle goes that well, which is optimism, not a plan. If the last three closed at 34, 29, and 38 points, I’d scope the next one around 30-32, leaving room for the inevitable mid-cycle interrupt.
On estimates: you don’t need them. Linear tracks cycles by raw issue count if estimates are off, which is fine if your issues are naturally similar in size. The problem shows up when sizes vary widely — a one-line config fix and a two-week feature both count as “1,” and your velocity trend becomes noise. If you enable estimates (Team Settings > General > Estimates), Fibonacci is the most common choice and maps cleanly from Jira story points. T-shirt sizes are faster in grooming and, in my experience, produce less arguing over whether something is a 5 or an 8. Whichever you pick, decide whether unestimated issues default to one point or zero — that setting quietly shifts your scope totals if half the backlog is never touched.
Running the cycle: triage, not swapping
The biggest behavioral mistake I see once cycles are configured correctly: treating a mid-cycle priority change as a 1:1 swap. Product comes in on day four with something urgent, and the instinct is to pull one committed issue and drop the new one in, keeping scope flat. That feels disciplined. It just hides the churn.
The swapped-out issue goes back to the backlog half-planned, and the engineer who’d already context-switched onto it burned time that shows up nowhere in your metrics. Treat it as a triage decision instead: does this genuinely have to happen this cycle, and what commitment are we breaking to make room? Say it out loud in standup. Let the scope-creep number go up. A cycle that visibly absorbed an urgent request is more honest than one that looks clean because you quietly reshuffled it.
This is also where Linear’s lack of a “lock the sprint” ceremony cuts both ways. Nothing stops anyone from adding issues to an active cycle — the tool won’t protect your commitment for you. That’s deliberate, not a gap, but it means cycle discipline is a team-culture problem, not a tool-enforced one. Teams that skip the conversation about who’s allowed to add scope mid-cycle end up with a cycle graph that never resembles the plan.
If your team runs code review through GitHub, keeping PR status in sync with cycle issues is where things break down for a lot of teams; see our Linear-GitHub sync troubleshooting guide if status isn’t updating when PRs merge.
Reading the cycle graph and rollover data
Open the cycle sidebar (Cmd/Ctrl+I) on an active cycle and you’ll see four lines plus a bar overlay, regenerated hourly. The gray line is total scope. The blue dotted line is the target — an even burn-down of estimated points across remaining days, flattening over weekends. The yellow line is issues started. The solid blue line, backed by blue bars, is issues completed.
The line worth watching isn’t completion — it’s the gap between the gray scope line and where it started. If scope crept up mid-cycle and the gray line sits meaningfully higher on day ten than day one, that’s your scope-creep signal, and it’s a planning conversation, not an engineering one. A cycle finishing at 70% against original commitment but 95% against its final (creeped) scope didn’t fail; it got re-planned without anyone calling it that.
Cycle Success is a weighted percentage: completed issues count fully, started issues count as 25% done. Ten issues, five complete and four started, reads as 60% success. That formula matters — a cycle can look mediocre on raw completion while reflecting healthy in-flight work, or look fine while nothing actually finished cleanly. Check the underlying split before trusting the single number.
On rollover: every unfinished issue moves forward automatically, no exceptions, no sorting by priority. What I actually track across cycles is the rollover rate — how many issues, or how much estimated effort, moved forward untouched. A rollover rate creeping from 10% to 30% over three or four cycles is a more honest planning-quality signal than completion percentage alone, because it shows the team consistently over-committing rather than occasionally missing a hard cycle. I bring that number into every retro now; it ends more “we just had a bad week” conversations than anything else I’ve tried.
For the full mechanics of the graph, Linear’s cycle graph documentation is accurate and worth reading directly. The core Cycles documentation covers configuration in full.
Anti-patterns: when cycles are the wrong answer
The most common failure: importing Jira’s full ceremony stack — a planning meeting, a mid-cycle check-in, a demo, and a retro, every two weeks, for a five-person team. Linear’s design point is removing ceremony the process doesn’t need: no sprint board to configure, no burndown chart to build, no separate “start sprint” click. If your team spends more time in cycle meetings than Jira ever demanded, you’ve rebuilt the overhead the tool was supposed to remove.
The second failure is running cycles when the team has no planning horizon worth fixing. A two-person team doing pure support-ticket triage, or a team where work arrives unpredictably and gets picked up in arrival order, gets nothing from a two-week commitment structure — it just adds a meeting to a workflow that worked fine as a plain priority-ordered kanban queue. Cycles solve coordinating committed capacity against competing demands. If nobody’s competing for that capacity, skip cycles.
Third: enabling estimates because “serious teams do it” without deciding what problem estimates solve. If nobody uses the velocity data to set planning ceilings, estimates are just an extra field filled in inconsistently — worse than no estimates, because false precision misleads more than an honest issue count.
For how Linear’s issue model compares to a lighter-weight approach, see our Linear vs. GitHub Issues comparison, and for where cycles earn their keep versus add overhead for smaller teams, our full Linear review.
Frequently Asked Questions
Can I run cycles of different lengths on the same team?
No. Linear enforces a single fixed duration per team, chosen once in cycle settings. For a one-off exception like a holiday week, adjust that specific cycle’s start or end date rather than the underlying duration.
What happens to unfinished issues when a cycle ends?
They roll to the next cycle automatically, regardless of priority, as long as they’re not marked completed or canceled. There’s no manual sorting step and no way to leave an issue stranded in a closed cycle. Issues you complete after the cycle closed can be manually reassigned back to it.
Do I need estimates for cycles to be useful?
No. Without estimates, Linear tracks progress and the capacity dial using raw issue counts, which works fine if issues are roughly similar in size. Turn estimates on when issue sizes vary enough that count-based tracking misrepresents actual effort.
Can different teams in the same workspace run different cadences?
Yes. Cycle settings are configured per team, so a two-week product team and a four-week platform team coexist in one workspace with no conflict. The exception is sub-teams, which inherit the parent’s cycle schedule once designated, even though their historical cycles stay untouched.
How is cycle success actually calculated?
Completed issues count fully; started-but-unfinished issues count as 25% done. Ten issues with five completed and four started reads as 60% success, not 50%. Check the completed/started split behind the number before treating it as the whole story.
