Cycles vs sprints: what actually differs, and which one a small team should run
Cycles and sprints are both fixed time boxes for planned work. Cycles drop Scrum's ceremony, roll unfinished work forward automatically and skip velocity.
On this page
A sprint and a cycle are the same basic thing: a fixed, short time box in which a team commits to a chosen set of work. The difference is in what surrounds it. A sprint comes from Scrum and carries its events, roles and the habit of estimating in points. A cycle, the term Linear popularised, keeps the time box and drops most of the rest: unfinished work rolls forward automatically, cooldowns are built in, and velocity is optional or absent.
If you have ever argued about whether to call the thing a sprint or a cycle, that argument is usually about ceremony, not the calendar. This post sets out where the two terms come from, what each tool actually does when the clock runs out, and how we settled the question for our own team.
Where sprints come from
The sprint is a Scrum concept. The Scrum Guide defines sprints as fixed-length events of one month or less, says a new sprint starts immediately after the previous one ends, and gives every sprint a single objective, the Sprint Goal. Around the time box, Scrum places four events: sprint planning, the daily scrum, the sprint review and the retrospective.
None of that is optional in Scrum as written. The Guide is also clear that forecasting practices such as burn-downs, burn-ups and cumulative flows are useful but do not replace empiricism; they are instruments, not the method.
Jira is the tool most people meet sprints in. Atlassian's own advice for teams new to it is a fixed two-week sprint. When you press "Complete sprint" in Jira with work still open, you choose where it goes: the backlog, any future sprint already created, or a new sprint made on the spot. The Jira documentation describes those three options; the decision is yours each time.
Where cycles come from
"Cycle" as a product term became common through Linear, which chose the word to signal a lighter version of the same idea. Linear's cycles documentation describes the shape: a team picks one duration, anywhere from one to eight weeks, and a start day, and cycles then repeat on that schedule. The team can add a cooldown after each cycle, a gap for technical debt and planning, and issues cannot be assigned to a cooldown.
The behaviour at the end of a cycle is the biggest practical difference from a sprint. In Linear, open issues roll over to the next cycle automatically, and there is no way to keep unfinished issues in a closed cycle. Where Jira asks you where unfinished work should go, Linear has already moved it. Linear also offers to auto-add started issues to the current cycle, so work that began outside the plan is captured rather than lost.
Capacity planning exists but is quiet. For a cycle that has not started, Linear estimates capacity from the number of issues or estimate points completed across the previous three completed cycles. You can use estimate points if you want to; many teams count issues instead. Linear lets you create up to fifteen future cycles.
Cycles vs sprints: the comparison
The table below compares the concept as Scrum defines it, as Jira implements it, and as Linear and Atrix implement cycles, as of October 2026.
| Scrum sprint | Jira sprint | Linear cycle | Atrix cycle | |
|---|---|---|---|---|
| Length | One month or less, fixed | Any; two weeks recommended | 1 to 8 weeks, fixed per team | 1 to 4 weeks, with a goal |
| Goal | Required (Sprint Goal) | Optional field | Optional | Set when the cycle is created |
| Unfinished work at the end | Returns to the product backlog for re-planning | You choose: backlog, a future sprint, or a new sprint | Rolls over to the next cycle automatically | Rolls over to the next cycle or back to the backlog |
| Gap between time boxes | None; the next sprint starts immediately | None built in | Optional cooldown; no issues assignable | None built in |
| Estimation | Not prescribed | Story points common | Optional estimate points | None; no story points |
| Velocity | Not a Scrum term | Velocity chart | Capacity from the last three cycles | Not tracked; burndown counts issues |
| Ceremony | Planning, daily scrum, review, retrospective | Whatever the team adds | Whatever the team adds | Whatever the team adds |
Read across a row and the pattern is clear. Scrum defines the method; Jira gives you the fields to run that method and leaves the decisions to you; cycle-based tools make the decisions for you and remove the fields you might argue about.
The three differences that matter day to day
What happens to unfinished work. In a sprint tool, closing the time box is a small ceremony with a decision attached. In a cycle tool, it is a date passing. Automatic rollover means nothing is dropped by accident, and it means a team that habitually over-plans will watch the same issues roll forward three cycles in a row. That visibility is the point. A cycle that keeps rolling the same work is a planning problem, not a tooling one.
Whether you estimate. Story points exist to forecast how much a team can take on. Cycle tools treat that as optional, and some, including Atrix, do not offer points at all. Counting issues instead is cruder but harder to game, and for a team of five, it is usually close enough. The trade-off is honest: if you need to tell a client how many weeks a scope will take, points and velocity give you a defensible number; issue counts give you a rough one.
How much ceremony is attached. A sprint implies four meetings. A cycle implies none. Most small teams that run cycles still do a short planning session and some kind of review, but they are choosing to, and they can skip the retrospective in a quiet fortnight without feeling they have broken the method.
Cooldowns and the cadence question
Scrum's "a new sprint starts immediately" is deliberate: it keeps the rhythm steady and stops the gaps between sprints from swallowing a week. Linear's cooldown is the opposite choice: a built-in pause where no issues can be assigned, meant for debt and planning.
In our experience, the cooldown works when it is short and protected. One week after a six-week cycle gives people room to fix the things that annoyed them and to plan the next block properly. A cooldown that becomes "the week nobody is sure what to do" is worse than no cooldown. If your team is two or three people, you probably do not need one; the end of a cycle and the start of the next can be the same afternoon.
What we run, and why
We run two-week cycles in Atrix, our own workspace, for product work, and we chose cycles over sprints for a reason that has nothing to do with vocabulary. With four to six people on a product, the time we used to spend on points and velocity was not improving our forecasts. Counting issues, with a goal per cycle and a burndown of open issues, told us what we needed to know: are we going to hit the goal, or not?
What Atrix gives you, stated plainly: cycles of one to four weeks per product, each with a goal; you plan issues into a cycle from the backlog; the burndown counts open issues; when you complete a cycle, unfinished work rolls to the next cycle or back to the backlog. Coloured labels and milestones sit alongside. What it does not give you: story points, velocity charts or a cooldown setting. If your process depends on any of those, Jira or Linear is the better fit, and the project management feature page is honest about that.
How to choose for your team
- Count the people and the clients. Two to eight people building one product: cycles, counted in issues, will do. A team that must quote delivery dates to clients from historical throughput: sprints with points, or cycles with estimate points in a tool that has them.
- Pick a length and keep it. Two weeks is the common default for a reason; one week is good for a team shipping daily, four weeks for research-heavy work. Changing length every cycle destroys the comparison between them.
- Write one goal. Whatever the tool calls it, a cycle with a single sentence of intent is easier to plan and easier to judge than a list of issues.
- Decide the rollover rule once. Automatic rollover or a deliberate decision at close. Either works. Changing your mind each time is what causes work to vanish.
- Keep the review, drop what you do not use. A fifteen-minute look at what shipped is worth keeping even in the lightest process. A retrospective every cycle is worth keeping only if it changes something.
If you want a template to start from, the sprint planning template covers a goal, capacity in issues, and the carry-over list, and works for either word.
FAQ
Is a cycle the same as a sprint?
Both are fixed time boxes for planned work, so in everyday use they are interchangeable. The difference is in what comes attached: a sprint carries Scrum's events and usually points and velocity; a cycle, in tools such as Linear and Atrix, keeps the time box, rolls unfinished work forward automatically and treats estimation as optional.
Why did Linear call them cycles instead of sprints?
Linear uses the word to mark a lighter-weight version: fixed length, automatic rollover, optional cooldowns, and no requirement to estimate. The term distances the practice from Scrum's full ceremony without changing the underlying idea of working in short, fixed periods.
What happens to unfinished issues at the end of a cycle?
In Linear, open issues roll over to the next cycle automatically; unfinished issues cannot stay in a closed cycle. In Atrix, unfinished work rolls to the next cycle or back to the backlog when you complete the cycle. In Jira, you choose at completion between the backlog, a future sprint or a new sprint.
What is a cooldown in cycle planning?
A cooldown is an optional gap after a cycle, used for technical debt, bug fixing and planning the next cycle. In Linear, issues cannot be assigned to a cooldown. Scrum has no equivalent; the Scrum Guide says a new sprint starts immediately after the previous one.
Do cycles use story points or velocity?
Not necessarily. Linear supports optional estimate points and derives capacity from the last three completed cycles by issues or points. Atrix uses neither story points nor velocity; its burndown counts open issues. Jira offers both as standard.
How long should a cycle or sprint be?
The Scrum Guide caps sprints at one month. Atlassian recommends two weeks for teams new to sprints. Linear allows one to eight weeks and Atrix one to four. Two weeks is the most common choice for small product teams; the important thing is to fix the length and keep it.
Next step
Read the sprint entry in the glossary for the Scrum definition and its events, then set up a first cycle with the sprint planning template. If you want cycles with a goal and an issue-count burndown and nothing else, that is what project management in Atrix does.