What You Need to Know Before You Start
Linear is a project management tool built specifically for software teams – not adapted from generic task managers, but designed from the ground up around how engineers actually work. Its sprint planning workflow is fast, opinionated, and deliberately minimal, which means it rewards teams who invest time learning its structure rather than fighting against it.
Before touching any sprint settings, understand the core hierarchy: Workspaces contain Teams, Teams contain Projects and Cycles (Linear’s term for sprints), and Cycles contain Issues. That distinction matters because sprint planning in Linear happens at the Team level, not the Project level. A lot of new users get confused here and end up with cycles that don’t behave as expected.
This guide covers everything from initial setup through running an active sprint, including triage, backlog grooming, capacity planning, and the automation features that eliminate the most tedious parts of sprint management. You do not need to be using Linear’s paid tier for most of this – the free plan supports Cycles with up to a handful of team members, which is enough to follow every step here.
Step 1: Set Up Your Team and Cycle Settings
Navigate to your Workspace, then select or create a Team. Go to Team Settings and find the Cycles section. This is where you configure the foundational sprint cadence – duration, start day, and auto-scheduling behavior.
Set your cycle duration to match your actual sprint length. Two weeks is standard, but Linear supports one-week cycles equally well. The start day matters more than most teams realize: if standups happen Monday morning, starting cycles on Monday means your sprint boundary and your team rhythm are misaligned by a day. Set the start day to Tuesday or Wednesday if that better matches when your team actually reviews work together.
Enable Cooldown period if your team runs retrospectives or buffer days between sprints. This creates a gap between cycles where issues can be reviewed before the next sprint begins – it prevents the whiplash of closing one sprint and immediately inheriting unfinished work into the next without any triage step.
Step 2: Build and Groom Your Backlog
Linear’s backlog is not a passive list. It is the source of truth for everything not yet scheduled, and grooming it before sprint planning is the difference between a 20-minute planning session and a two-hour debate.
Start by filtering the backlog by Priority. Linear uses a four-tier priority system – Urgent, High, Medium, No Priority – and anything unprioritized before a sprint planning meeting is work that will either get skipped or argued over in the meeting itself. Assign priorities in advance. This is a team lead or engineering manager responsibility, not something to crowdsource during the planning call.
Use Labels to tag issues by type: Bug, Feature, Tech Debt, Spike. During planning, filtering the backlog by label lets you quickly see if a sprint is becoming all bug fixes with no feature work, or vice versa. That imbalance is worth catching before the sprint starts, not midway through.
Add Estimates to backlog issues using Linear’s point scale. The default scale runs from 0 to Extra Large, but you can configure custom point values under Team Settings. Estimates are optional at the backlog stage but required for capacity planning in Step 4 – so any issue you want to pull into a sprint should have a number attached to it.
Step 3: Create a New Cycle
In the left sidebar under your Team, select Cycles and click New Cycle. If you configured auto-scheduling in Step 1, Linear will auto-populate the start and end dates. Confirm these dates match your actual sprint window before proceeding.
Give the cycle a name if your team uses named sprints – some teams prefer numbered cycles (Sprint 47), others use milestone names (Auth Refactor, Q3 Launch Prep). Linear supports both. Named cycles make historical reporting easier when you are reviewing velocity trends weeks later.
Leave the cycle in draft state until backlog grooming is complete. Starting a cycle immediately locks in the start date and triggers any automations you have configured, so it is worth holding off until you have issues ready to pull in.
Step 4: Run Capacity Planning
Linear does not have a native team member availability calendar, which is one honest limitation of the tool. Capacity planning here means working with total point targets, not per-person hour breakdowns. If you need the latter, you will need a separate spreadsheet or a tool like Todoist for individual task tracking alongside Linear.
Calculate your team’s baseline velocity from the previous two or three cycles. Linear shows completed points per cycle in the Insights panel. Take that average and subtract capacity for any planned time off, on-call rotations, or company events during the upcoming sprint.
That target number becomes your point ceiling for sprint planning. It sounds simple because it is. The goal is to stop overloading sprints, which is the single most common reason teams carry issues forward cycle after cycle and lose confidence in their planning process.
Step 5: Pull Issues into the Active Cycle
Open your backlog and sort by Priority descending. Start pulling issues into the cycle by clicking the issue and updating the Cycle field, or by using the right-click context menu and selecting Move to Cycle. Linear also supports drag-and-drop from the backlog view directly into the current cycle view.
Watch the cycle’s running point total as you add issues. Linear displays this in the cycle header. Stop adding issues when you hit your capacity target from Step 4. This requires actual discipline – there will always be stakeholder pressure to add one more thing. The cycle point ceiling is the answer to that pressure, not a negotiation.
For issues that surface during planning but lack estimates or sufficient detail, create them as issues in the backlog with a Triage label rather than pulling them directly into the sprint. Half-defined work in an active sprint is worse than deferred work in a groomed backlog.
Step 6: Assign Issues and Set Sub-Issues
Assign each sprint issue to a specific team member. Unassigned issues in an active cycle are accountability gaps – when no one owns something, no one is watching whether it moves.
For larger issues, use Sub-issues to break work into discrete tasks. Linear supports nested sub-issues, but keep nesting to one level for sprint work. Deeply nested task trees make daily standups harder to parse and status updates more confusing than helpful.
Set Due Dates only for issues with external dependencies or hard deadlines. Adding due dates to every issue creates noise and trains the team to ignore the date field. Use it selectively so it retains meaning when it appears.
Step 7: Start the Cycle and Configure Automations
Mark the cycle as active by clicking Start Cycle. This makes the cycle the default view for the team and activates any automations you have configured.
Linear’s automation rules live under Team Settings > Workflow. The most useful automations for sprint planning are: automatically moving issues to In Progress when a branch is created in a linked GitHub or GitLab repo, marking issues as Done when a pull request merges, and canceling issues that remain in a future cycle past their due date. These three rules alone eliminate a significant amount of manual status updating during the sprint.
Configure the Cycle Auto-Add setting if you want Linear to automatically pull in urgent issues created mid-sprint. This is useful for bug-heavy teams where production issues need to enter the sprint immediately rather than sitting in a backlog until someone manually adds them.
Step 8: Manage the Sprint in Progress
The active cycle view is your daily operating screen. Linear’s Board view (Kanban-style columns by status) is the default for most teams during execution, but the List view is faster for leads who want to scan across all issues quickly during standups.
Use Filters to create personal views. Each engineer should filter the cycle board to their own assigned issues during standups rather than scrolling through the full team list. This takes ten seconds to set up and removes a consistent source of standup drag.
When new work appears mid-sprint – and it will – run a quick point check before adding it. If the addition pushes the cycle over capacity, something of equal or lesser points should be pushed back to the backlog. This is the hard conversation sprint planning is supposed to front-load, but it happens mid-sprint often enough that having an explicit rule about it prevents ad hoc scope creep from becoming the norm.
Step 9: Close the Cycle and Handle Carry-Overs
When the cycle ends, Linear will prompt you to close it. Before closing, review incomplete issues and decide: move to next cycle, move to backlog, or cancel. Linear gives you all three options in the close cycle dialog.
Resist the default reflex to move everything incomplete into the next sprint. Issues that didn’t get touched during the sprint were either wrongly prioritized or blocked by something that needs to be addressed explicitly. Moving them forward without that conversation just defers the root cause.
After closing, check the Insights panel for the cycle’s completed vs. planned points. That ratio, tracked over four or five sprints, is the most honest signal of whether your team’s estimates and planning process are calibrated to reality.
Key Takeaways
Linear’s sprint planning workflow is only as good as the habits built around it. The tool handles the structure – cycles, automations, status syncing with code repositories – but the decisions about what goes into a sprint and how much is too much remain entirely human calls.
- Configure cycle settings before the first sprint – duration, start day, and cooldown period all affect how the sprint behaves downstream
- Groom the backlog before planning – unestimated, unprioritized issues in a planning meeting cost more time than they save
- Use velocity from past cycles as your capacity ceiling, not optimism about what the team could theoretically accomplish
- Assign every issue before starting the cycle – ownership is not optional
- Set up at least the three core automations – branch creation to In Progress, PR merge to Done, and auto-add for urgent issues
- Close cycles deliberately – carry-over decisions should be explicit, not automatic
The teams that get the most out of Linear’s sprint tooling are the ones that treat the cycle boundary as a real constraint rather than a suggestion. When the point ceiling is respected and carry-over is treated as a signal worth investigating, the planning meeting stops being a negotiation and starts being a 30-minute formality. That shift alone justifies the setup time.
One thing to watch: Linear’s Insights panel only surfaces velocity data if your team is consistently closing cycles cleanly. Teams that leave cycles in limbo or forget to close them end up with incomplete historical data, which makes capacity planning in Step 4 a guess rather than a calculation.
