Linear cycles vs scrum sprints: the four places they really differ

Most arguments about Linear cycles versus scrum sprints are arguments about vocabulary. Put a two-week cycle and a two-week sprint side by side on a calendar and you cannot tell them apart. The difference only shows up at the edges: on the last day, in the progress number, and in the week after.

Here is the short answer. A Linear cycle is a repeating time box, one to eight weeks long, that Linear schedules for you and closes for you, carrying unfinished work forward on its own. A scrum sprint is a time box built around a goal, and the team closes it by hand: a review, a retro, and a decision about every unfinished story. Everything else in this post is what that difference does to a team over a few months.

We have written about setting up Linear for scrum and about where Linear stops fitting. This one is narrower. It is the mechanics, laid next to each other, so you can decide whether cycles are enough for your team or whether you actually want sprints.

What is a Linear cycle, mechanically?

You turn cycles on per team. You pick a length between one and eight weeks and a start day, and each cycle begins at midnight in the team's timezone. Linear then creates the upcoming cycles itself, up to fifteen ahead, on a repeating schedule. Nobody starts a cycle. It starts because it is Monday.

Linear's own docs are clear about the intent: cycles are compared to sprints, but unlike sprints they are not tied to releases. The Linear Method describes the goal as healthy momentum, "not to rush towards the end", and tells you to let unfinished work move to the next cycle automatically. That is not a missing feature. It is the design.

Where cycles and sprints actually differ

There are four places, and they matter in roughly this order.

	Linear cycle	Scrum sprint
Who ends it	The calendar	The team
Unfinished work	Rolls forward automatically	Decided story by story
Goal	Cycle name and description; goals live on projects	A sprint goal is part of the sprint
Progress	Started issues count as 25% done	Done or not done

If the table does not survive wherever you are reading this, the prose below says the same thing.

Who ends it

A cycle closes on schedule whether anyone is looking or not. You can shorten one or start the next one early, but the default is that time ends it. A sprint ends when the team holds its review and says so. That sounds like a ceremony detail. It is actually the whole loop: the moment the sprint closes is the moment the team looks at what it promised against what it delivered.

Where unfinished work goes

When a cycle closes, every unfinished issue rolls into the next cycle. The only issues that stay behind are the ones somebody moved to backlog, triage or canceled first. You cannot leave an unfinished issue in a closed cycle at all.

In scrum, unfinished work goes nowhere until someone decides. It might carry over, it might go back to the backlog because priorities moved, it might be dropped. The decision is where a team learns that it keeps taking on a third more than it finishes. We wrote about how to make those calls separately.

The goal

Linear has no sprint goal field. A cycle has an editable name and a description, and the Linear Method connects cycles to bigger goals through projects: you pull work from projects into cycles, and projects tie back to initiatives. That works well for a product team whose "why" lives at the project level. It means the two weeks themselves do not have to stand for anything, and in practice they often don't.

What "done" counts

This is the one I did not expect when I started writing this. I assumed rollover was the big difference. Then I read how Linear calculates cycle progress.

Linear's success percentage counts completed issues fully and started issues as 25% done. Their own example: ten issues, five completed, four started, one untouched, comes out at 60%. In a sprint review the same two weeks are five of ten done, and four stories are about to be discussed one by one. Same work, different story. And because unestimated issues count as the team's default estimate, which is one point out of the box, a cycle full of unrefined issues looks smaller and healthier than it is.

None of this is wrong. It is a progress number designed to show momentum mid-cycle. It is just not a commitment number, and if you read it as one, you will think you are doing better than you are.

What is a cycle cooldown for?

A cooldown is an optional gap after each cycle. Linear pitches it as time for rest, tech debt and planning, and you cannot assign issues to it. It also acts as a buffer for rollover: issues moved to backlog, triage or canceled during the cooldown do not carry into the next cycle.

Scrum has nothing like it on purpose. Sprints run back to back, and review, retro and planning happen at the boundary between them, usually inside a day. A cooldown is closer to Shape Up thinking than to scrum. It is a good idea for teams that need a breather, and a risky one for teams that will quietly turn it into an unplanned third week.

How does Linear calculate cycle capacity?

Before a cycle starts, Linear shows a capacity dial: the average of the team's previous three completed cycles, counted in issues or estimate points. A brand-new team gets a rough guess based on team size.

This is the closest Linear comes to sprint velocity, and it is useful in planning. Two things to keep in mind. Three cycles is a short memory, so one holiday cycle pulls the number down for weeks. And because the scope it measures includes rolled-over issues and default points, it inherits the softness of the progress number above.

When cycles are enough

Honestly, for a lot of teams. If you are an internal product team, nobody outside the team is waiting on a date, work flows continuously from projects, and your retro already happens without a tool forcing it, cycles give you rhythm without ceremony. That is a coherent way to build software, and Linear is very good at it. Rollover is a feature for you, not a leak.

When you want a sprint

When somebody outside the team needs a forecast. When a client or stakeholder asks "what will we have in two weeks" and you need the answer to mean something. When your velocity needs to be a number you plan against across months, not a dial for the next cycle. And when you notice that nothing on your team is ever formally unfinished, because the tool moved it before anyone had to say so.

You can get most of the way there inside Linear with ten minutes of settings and one habit. The habit is walking the unfinished issues by hand before the cycle closes. If you end up doing that against the tool every two weeks, that is the signal.

How Scrumpy does the same two weeks

A sprint in Scrumpy has a goal field. It does not end on a timer: someone presses "End sprint", and unfinished stories move to the next sprint at that moment, by a person, usually straight after the review. Scrumpy does not hide that they moved. The sprint report keeps a list of carried-over stories with their points, and the success rate counts done stories only, against the scope the sprint had when it ended.

If you are weighing the two tools rather than the two words, the side-by-side comparison is the place to start, and this roundup covers the other sprint-first options too.