Linear Best Practices

Using Linear well is about habits, not features. Every feature in Linear only delivers value when teams apply it consistently and intentionally. This topic brings together the most important practices that high-performing teams use to get the most from Linear every day.

Issue Writing Practices

Write One Issue Per Task

Each issue must describe one and only one piece of work. Combining two tasks in one issue creates confusion — the issue can never be truly "done" until both are done, and the assignee has no clean way to split the work. Break multi-part work into sub-issues instead.

Wrong (Combined Tasks)Right (Separate Issues)
Fix login bug and update the profile pageIssue 1: Fix login timeout bug on Safari
Issue 2: Redesign the profile page layout
Improve performance and fix all bugsMultiple focused issues, each targeting one problem

Include Acceptance Criteria

Every issue should answer: "How do we know when this is done?" Acceptance criteria remove ambiguity. The developer and reviewer know exactly what the finished state looks like, which prevents issues from bouncing between In Review and In Progress repeatedly.

Backlog Hygiene

A bloated backlog slows everyone down. Teams spend more time reviewing old issues than doing new work. Set aside time every one to two weeks to clean the backlog.

Backlog Cleanup Checklist

CheckAction if True
Issue has been in Backlog for over 90 daysCancel it or set a realistic future cycle
Issue has no assignee and no priorityReview and either assign it or cancel it
Issue is a duplicate of another issueMark as Duplicate and close it
Issue description is empty or too vagueUpdate with context or cancel if no one remembers why it exists
Issue was created by someone who left the teamReassign ownership or cancel

Cycle Planning Best Practices

Never Over-Commit a Cycle

Use your team's historical velocity to set the cycle plan. If the average velocity over the last four cycles is 28 points, plan the next cycle for 24–28 points — not 40. Over-committing creates stress, breaks team morale, and inflates carry-over rates.

CAPACITY PLANNING FORMULA

Average Velocity = (Sum of last 4 cycles' completed points) / 4

Example:
  Sprint 20: 30 pts
  Sprint 21: 26 pts
  Sprint 22: 28 pts
  Sprint 23: 24 pts
  Average: (30+26+28+24) / 4 = 27 points

Plan next cycle: 25–27 points maximum
Add buffer for interruptions (support requests, meetings):
  25 points × 80% buffer = 20 committed points + 5 stretch points

Leave Room for Unplanned Work

Every team gets unexpected tasks during a cycle — urgent bugs, customer escalations, teammate absences. Reserve 15–20% of each cycle for unplanned work. Fill it only when something genuinely urgent arrives, not with extra backlog items.

Workflow State Discipline

Workflow states only reflect reality when everyone moves issues consistently. The most common failure is issues that get stuck in "In Progress" long after work has actually stopped or been completed.

State Ownership Rules

StateWho Updates ItWhen to Update
In Progress → In ReviewThe assigneeThe moment a pull request is opened
In Review → DoneThe reviewer or team leadAfter approving and merging the PR
Any state → BlockedThe assigneeThe moment a blocker is discovered
Done → CancelledTeam lead or issue creatorOnly when the work was never needed

Priority Management

Keep Urgent Issues Rare

When too many issues carry Urgent priority, the label loses meaning and the team can't determine what truly needs immediate attention. Limit Urgent to issues that actually break production or block users right now. If more than 10% of open issues are Urgent, the priority scale needs recalibration.

HEALTHY PRIORITY DISTRIBUTION

Urgent:  ▓▓░░░░░░░░  ~5% of issues
High:    ▓▓▓▓░░░░░░  ~20% of issues
Medium:  ▓▓▓▓▓▓░░░░  ~45% of issues
Low:     ▓▓▓▓░░░░░░  ~20% of issues
No Pri:  ▓▓░░░░░░░░  ~10% of issues

Using Labels Consistently

Define your label set once and write a short definition for each one in a team document. When anyone on the team creates an issue, they should agree on which label applies based on a shared understanding. Inconsistent labels make filters unreliable.

Communication in Issues vs Slack

TopicWhere to Discuss
Technical decision about how to solve a specific issueIn the Linear issue comment thread
Quick clarification needing an immediate answerSlack, then paste the answer back into the issue
Design or product debate affecting multiple issuesSlack, but summarize the outcome in each affected issue
Status update on a specific issueIn the Linear issue comment thread

The rule: if a discussion results in a decision, that decision lives in Linear. Slack messages get lost. Linear comments are permanent and searchable.

Daily Linear Workflow

A simple daily rhythm helps individuals stay on top of their work without spending excessive time in Linear.

Suggested Daily Routine

  1. Morning (5–10 minutes): Open Inbox and process all notifications. Reply to comments, action any mentions.
  2. Morning (5 minutes): Open My Issues and confirm which issues are In Progress. Move anything that started yesterday from Todo to In Progress.
  3. During work: Update issue status the moment your work state changes — don't batch status updates at end of day.
  4. End of day (5 minutes): Add a comment to any In Progress issue noting where you left off. This helps anyone who picks it up next.

Team-Level Practices

PracticeFrequencyPurpose
Backlog reviewWeeklyClean stale issues, re-prioritize, assign unowned tasks
Cycle planningPer cycle startCommit to the right amount of work using velocity data
Cycle retrospectivePer cycle endReview what was completed, carried over, and why
Label and workflow auditQuarterlyRemove unused labels, update workflow states to match real process
Integration health checkMonthlyConfirm GitHub, Slack, and other integrations are firing correctly

Leave a Comment

Your email address will not be published. Required fields are marked *