How to Use Linear Cycles in 2026: Sprint Planning, Backlog Triage & Team Velocity

Updated June 2026 • 12 min read • By a senior engineering manager who has shipped 50+ sprint cycles across four product teams in Linear

1. Why structured cycles matter more than tool features

Most teams adopt a sprint tool and immediately ask the wrong question: “how do we use it?” The right question is: “what problem are we trying to solve with time-boxed iterations?” The answer — for every team I have managed — is the same: without a fixed planning horizon, engineers context-switch constantly, product managers reprioritize mid-stream without consequence, and stakeholders have no reliable date to rally around. A cycle is not a bureaucratic formality. It is a forcing function that turns a continuous flow of requests into a committed contract the team can actually honor.

If you are coming from Jira, you already understand sprints conceptually. Linear Cycles cover the same territory but with meaningfully different defaults and, as of March 2026, a substantially smarter way to handle the end-of-cycle chaos that kills retrospectives in every other tool. The rest of this guide walks you through every configuration decision you will face: cycle length, cooldown duration, estimate type, Autopilot behavior, and the Insights data that should inform every planning session you run from this point forward.

2. What are Linear cycles? Active phase vs. cooldown explained

A Linear cycle is a fixed-length iteration assigned to a team. Every cycle has two distinct phases that most guides never explain clearly, which is why teams end up running their cooldown period as a second sprint rather than using it for what it was designed to do.

Active phase

This is the sprint proper. Issues are scoped in, engineers are working, and the cycle progress bar in the sidebar reflects completion against the committed scope. The active phase runs for the duration you set (1–6 weeks) and ends when the cooldown begins. During this phase, scope changes are visible in the Cycle Insights panel as scope creep percentage — a metric that, if you are tracking it, will immediately reveal whether your planning discipline is improving or eroding over time.

Cooldown phase

This is not downtime. Cooldown is a configurable buffer (0–7 days) between the end of one active cycle and the start of the next. Its purpose is threefold: it gives you dedicated time to run a retrospective without cannibalizing the first day of the next sprint, it lets Cycle Autopilot complete its rollover and triage logic before new commitments are made, and it creates a structured window for backlog grooming that does not bleed into engineering execution time.

This is a meaningful structural difference from Jira, where cooldown has no first-class representation — teams either bolt on a formal grooming ceremony that sits awkwardly inside an active sprint, or they skip it entirely and wonder why their backlog grows uncontrollably. In Linear, cooldown is a named phase with its own UI state and, as of 2026, its own Autopilot behaviors.

3. How to enable cycles in Linear

Cycles are disabled by default in Linear. They are enabled per team, which means if you run multiple squads in one workspace, each team can operate on a different cadence. Here is the exact sequence to turn cycles on and configure them correctly from day one.

1. Settings → Teams → [Your Team] — Navigate to your workspace Settings using the gear icon in the bottom-left sidebar, then select Teams and click on the specific team you want to configure. Each team has independent cycle settings.
2. Cycles tab → Enable Cycles toggle — Within the team settings, locate the Cycles tab. Flip the “Enable Cycles” toggle to on. This immediately adds a Cycles entry to the left sidebar under that team and creates the first draft cycle.
3. Set cycle duration — Select a duration between 1 and 6 weeks. Two weeks is the default and is appropriate for most product teams. Platform or infrastructure teams often benefit from three or four weeks due to longer task lead times. Do not use six-week cycles unless your work genuinely has six-week lead times — the feedback loop becomes too slow for useful retrospectives.
4. Set cycle start day — Choose which day of the week cycles begin. Monday is the default and the right choice for most teams. Avoid mid-week starts; they fragment the planning session across the week boundary and create confusion about which standup belongs to which cycle.
5. Set cooldown duration — Input the number of cooldown days (0–7). This buffer inserts automatically between each active cycle. For two-week cycles, set this to 1 or 2 days.
6. Save settings — Click Save. Linear will generate the upcoming cycle schedule based on your configuration. You can now navigate to the Cycles view in the sidebar to see the current and upcoming cycles.

Once cycles are enabled, you will see three views in the Cycles sidebar section: Active (the current cycle), Upcoming (future cycles), and Completed (historical cycles, which feed the Insights panel). You will spend most of your planning time in the Active and Upcoming views.

4. How to configure estimates for accurate velocity tracking

This is the configuration step that most teams skip, and it is the reason their velocity data is meaningless within two cycles. By default, Linear Cycles track progress by issue count. An issue is either complete or it is not. If every issue in your cycle is roughly the same size, this works. In practice, it never is. A one-line config change and a three-line copy PR are both “one issue.” Your velocity number will be noise.

Linear supports two estimate types that you can enable to add weight to issues: numeric points (equivalent to story points in Jira) and T-shirt sizes (XS, S, M, L, XL). Both are valid. Numeric points give you more granularity and are compatible with the velocity trend calculations in Cycle Insights. T-shirt sizes are faster to assign during planning and reduce the false precision that story points tend to invite. The right choice depends on your team’s estimation culture.

1. Settings → Teams → [Your Team] → Estimates tab — Navigate to the Estimates tab within your team settings. This is separate from the Cycles tab. You must configure both independently.
2. Enable estimates toggle — Flip the toggle to enable estimates for this team. This adds an estimate field to every issue created by this team going forward. Existing issues will have no estimate until manually assigned.
3. Choose estimate type: Exponential, Fibonacci, Linear, or T-shirt — Linear (the company) offers four estimation scales. Fibonacci (1, 2, 3, 5, 8, 13) is the most commonly used and maps directly to Jira story points, making it familiar for teams migrating from Jira. T-shirt sizing is faster for grooming sessions. Exponential is rarely useful in practice unless you are on an extremely mature team that has calibrated it intentionally.
4. Set your estimate scale values — If using numeric points, confirm the values for each size level. These values are what Cycle Insights uses to calculate velocity in points per cycle rather than issues per cycle. Without this step, the Insights panel defaults to issue count regardless of whether estimates are enabled.
5. Save settings and backfill estimates — After saving, schedule a one-time backlog grooming session to apply estimates to all issues currently in your backlog. This is a time investment upfront, but it is what makes your Cycle 2 velocity data meaningful. If you skip it, your first Insights velocity reading will reflect only the issues estimated in Cycle 1, skewing the trend line.

5. How to set up Cycle Autopilot (the 2026 feature that changes everything)

If you have run sprint cycles in any tool for more than six months, you know the conversation that happens every two weeks: “We have fourteen issues that did not get done. What do we do with them?” In Jira, the answer is: manually drag issues to the next sprint, one by one, while someone argues about whether they should be re-estimated. In every other tool, the answer is some variant of the same tedious manual process. Linear’s Cycle Autopilot, released in March 2026, automates this entirely based on issue priority.

Here is how Autopilot handles incomplete issues at the end of each active cycle:

The practical implication is significant. In a team of six engineers running two-week cycles, you might end 10–20% of your issues incomplete. Without Autopilot, that is a manual review of 8–15 issues every fortnight. With Autopilot configured correctly and your priority labels maintained consistently, that review collapses to a focused triage of only the P2/P3 issues — typically 3–6 items — during cooldown. The P0/P1 issues are already in the next cycle before your retro starts.

How to enable Cycle Autopilot

1. Settings → Teams → [Your Team] → Cycles tab — Return to the Cycles settings tab for your team. Autopilot is a cycle-level setting, not a workspace-level one. Each team configures it independently.
2. Scroll to “Cycle Autopilot” section — This section appears below the basic cycle duration settings. If you do not see it, confirm you are on Linear version 2026.3 or later. Autopilot was released in the March 2026 product update.
3. Enable Autopilot toggle — Flip the toggle on. A confirmation dialog will explain the priority-based rollover rules. Read it carefully if this is your team’s first cycle with Autopilot enabled — the behavior at cycle close is immediate and cannot be undone for the current cycle.
4. Confirm priority label accuracy — Autopilot is only as good as your priority labels. Before enabling, audit your current active cycle issues and confirm every issue has an accurate priority set. Issues with no priority set are treated as P4 by Autopilot and will be moved to backlog at cycle end. This is the most common Autopilot surprise for teams who have not maintained priority hygiene.
5. Set triage notification preference — In the Autopilot settings, choose who receives the triage notification at cycle end for P2/P3 flagged issues. Setting this to the team lead or project manager rather than all engineers keeps the triage decision centralized and avoids notification fatigue.
6. Save and communicate to the team — Save settings and run a brief team sync to explain Autopilot behavior before the next cycle closes. Engineers who did not know Autopilot was running will be confused when they see issues moving without human action. A five-minute explanation eliminates this entirely.

For a broader look at how Linear’s 2026 AI-driven features work together, see our deep-dive on Linear Agent features in 2026, which covers how Autopilot interacts with Linear’s issue triage suggestions.

6. How to run sprint planning in Linear

Sprint planning in Linear centers on the Upcoming cycle view. The workflow is deliberately simple: you drag issues from the backlog into the cycle, review the capacity signal in the sidebar, and lock scope. What makes Linear planning meaningfully better than Jira for most teams is the absence of the sprint configuration ceremony — there is no sprint board to configure, no velocity chart to manually set up, no burn-down chart wizard to complete. You open the upcoming cycle, add issues, and start the cycle when ready.

1. Open the Upcoming cycle in the sidebar — Click on the Upcoming cycle under the Cycles section of your team. This shows the blank cycle with its date range and an empty issue list. If Autopilot ran at the end of the previous cycle, your P0/P1 rollovers will already be here.
2. Review Cycle Insights velocity recommendation — Before adding any new issues, open the Cycle Insights panel (top right of the cycle view). Look at your average velocity over the last 4–8 cycles. This is your planning ceiling. Do not commit more than 80–90% of this number to leave buffer for unplanned work.
3. Add issues from the backlog using drag-and-drop or right-click → Add to Cycle — Drag issues from the team backlog view into the upcoming cycle, or right-click any issue and select “Add to Cycle.” As you add issues, the cycle total estimate updates in the sidebar progress indicator.
4. Review total estimate against velocity target — Watch the cycle estimate total. Stop adding issues when you reach your velocity target. If you are over-allocated, remove the lowest-priority issues first rather than reducing estimates to fit — reducing estimates to hit a number is a planning anti-pattern that corrupts your velocity trend data.
5. Assign issues to engineers — Use the assignee field in each issue or the bulk-edit functionality (select multiple issues → right-click → Assign) to distribute work. Linear does not enforce capacity limits per engineer, so this is a judgment call for the planning facilitator.
6. Set the cycle to Active — When planning is complete, click “Start Cycle” in the cycle header. This locks the cycle start date, begins the cooldown countdown for the previous cycle if it was still in that phase, and makes the cycle progress bar live in the sidebar.

If your team is also using GitHub for code review, the cycle view integrates with branch and PR status. See our guide on Linear GitHub sync troubleshooting if your PR status is not updating correctly inside cycle issues — this is one of the most common workflow blockers for engineering teams.

7. Backlog triage during cooldown

Cooldown is where teams either build or destroy their planning discipline. Teams that treat cooldown as “the time before the next sprint starts” and immediately begin working on upcoming issues are defeating the purpose of the buffer. Cooldown is a structural guarantee that the team has time to look backward (retro) and forward (grooming) without competing against active delivery pressure.

With Autopilot enabled, the P2/P3 flagged issues appear in a triage queue during cooldown. Here is how to work through them effectively:

1. Open the Cycle Autopilot triage queue — During cooldown, a triage banner appears at the top of the completed cycle view listing all P2/P3 issues that Autopilot flagged. Click “Review triage issues” to open the queue.
2. For each flagged issue, choose: Roll to next cycle, move to backlog, or close — These are the only three options. Avoid the temptation to add more options — decision paralysis during triage is what causes it to consume the entire cooldown window. If you cannot decide in 30 seconds, it goes to backlog.
3. Update priority labels if the issue’s urgency has changed — If a P2 issue is less urgent now than when it was created, downgrade it to P3 or P4 before making a rollover decision. Autopilot uses current priority at cycle close, so keeping labels accurate is what makes every future Autopilot run more autonomous.
4. Groom the broader backlog while the triage queue is fresh — After clearing the Autopilot triage queue, spend the remaining cooldown time reviewing the top 20–30 backlog issues. Update estimates, refresh priorities, and remove issues that are no longer relevant. A groomed backlog is what makes the next planning session take 30 minutes instead of 90.

8. How to run a cycle review with Cycle Insights

The Cycle Insights panel is the most underused feature in Linear. Most teams glance at the completion percentage, feel good or bad about it, and move on. That is leaving the majority of the panel’s value unused. Insights tracks three metrics across the last 8 cycles that, when read together, tell you whether your team’s planning process is improving or stagnating.

The three Cycle Insights metrics explained

Velocity trend — The rolling average of completed estimates (points or issues) per cycle over the last 8 cycles. A flat or rising velocity trend is healthy. A declining trend is a diagnostic signal that something systematic is slowing the team: unclear requirements, increasing interruptions, technical debt accumulation, or team capacity changes. The 8-cycle window is deliberate — it is long enough to smooth out one anomalous sprint but short enough to reflect recent team changes.

Completion rate — The percentage of committed scope that was completed within the cycle. According to Linear’s 2025 team performance report, teams that set a velocity target using Insights data reduce missed cycle goals by an average of 34%. A sustainable completion rate is 75–85%. Teams targeting 100% completion are almost always gaming the number by under-committing. Teams below 70% are either over-committing or experiencing systematic scope creep.

Scope creep percentage — The percentage of issues added to the cycle after it started, relative to the total committed scope. Scope creep under 10% is normal and expected. Scope creep above 20% means your planning session is not the real planning session — someone with enough authority is re-prioritizing mid-cycle, and your committed scope is not actually committed. If you see persistent scope creep above 20%, the conversation to have is not with your engineers; it is with whoever is adding issues after cycle start.

1. Open Cycle Insights via the Cycles view header → Insights tab — After a cycle completes, navigate to the Completed cycles section and open the most recently finished cycle. Click the Insights tab in the top navigation of the cycle detail view.
2. Review the three metric panels in sequence — Read velocity trend first, then completion rate, then scope creep. Each metric contextualizes the next. High completion rate with high scope creep means you completed more than you planned, not that you planned well.
3. Note the trend direction for each metric over 8 cycles — The trend line matters more than the point value. A completion rate of 72% that has risen from 58% over six cycles tells a very different story than a completion rate of 72% that has fallen from 89%.
4. Record the velocity number for the next planning session — Copy the rolling average velocity from Insights. This is your planning input for the next sprint. Write it in your planning doc, your Notion page, wherever your planning context lives. Do not rely on memory — it degrades between cooldown and planning day.
5. Present the three metrics at retrospective as the data foundation — Open Cycle Insights in the retro meeting before any team discussion starts. Let the data frame the conversation rather than letting anecdote drive it. This single habit change reduces the time teams spend relitigating the previous sprint from 20–30 minutes to under 10.

9. Setting velocity targets that teams actually hit

A velocity target is not a quota. It is a planning anchor that prevents both over-commitment and sandbagging. Teams that plan without a velocity target tend to add issues until the planning session runs out of time, which is a terrible heuristic for capacity. Teams that set targets based on aspirational output rather than historical data consistently miss goals and erode confidence in the planning process.

Here is the velocity target formula I use across teams. It produces a realistic, defensible planning ceiling in under two minutes:

If your 8-cycle rolling average is 42 points, your planning ceiling is 35–36 points. You add issues until you reach 35–36 and stop. Any issue that does not fit goes back to the backlog or gets split. This is non-negotiable. The value of the ceiling comes from its firmness.

For teams comparing Linear’s planning workflow to alternatives, our Linear vs. Shortcut 2026 comparison covers how each tool handles velocity tracking and whether Shortcut’s iteration model offers comparable Insights depth. For a full platform review including cycles, see our comprehensive Linear review for 2026.

For deeper reading directly from Linear’s documentation, Linear’s official Cycles documentation covers the foundational configuration, and Linear’s estimates documentation explains the full set of estimate scale options in detail.

If you encounter configuration issues with cycles not updating or the progress bar not reflecting completed issues, our Linear not working troubleshooting guide covers the most common cycle-related bugs and their fixes.

Frequently Asked Questions