Linear for Product Teams: Issues, Roadmaps, Cycles, and Git Integrations (A Complete System)

Most teams meet Linear for the first time when an engineer says, “Can we please stop using spreadsheets for bugs?” Linear is far more than a bug tracker. When you set it up with sane defaults, strong conventions, and a few key integrations, it becomes a lightweight operating system for product delivery—fast triage, clear ownership, predictable cycles, and honest visibility for leadership. This guide walks you through a production-ready configuration for small and medium teams, with practical templates, workflows, and guardrails you can copy.

The mental model: work, time, and scope

Linear organizes work with a simple model:

• Workspace: your company or product group.
• Teams: cross-functional squads (e.g., “Core App,” “Growth,” “Platform”). Each team has its own workflow and backlog.
• Projects: meaningful outcomes that span multiple issues and sometimes multiple teams.
• Issues: the unit of work (feature, improvement, bug, chore).
• Cycles: time-boxed sprints (usually 1–2 weeks) that give the team cadence.
• Roadmaps: higher-level plans built from Projects with timelines and status.

Keep this mapping crisp: Issues roll into Projects; Projects roll into a Roadmap; Cycles are how you ship.

Create teams with clear, shared workflows

Each team should have an almost identical workflow so people can move between teams without relearning basics. Start with:

• Backlog → Planned → In Progress → In Review → Ready to Merge/Stage → Done
• Add Blocked as a status type (not a label) so it’s visible and reportable.
• For support/ops work, consider a Needs Triage column before Backlog.

Define state changes precisely:

• Moving to Planned means the issue has acceptance criteria and is eligible for the next cycle.
• In Review means a PR is up or QA is happening.
• Done means in production behind any flags, user-visible if intended, and validated by the owner.

Document these in a short “How we use Linear” page and pin it in the team description.

Issue hygiene that scales

Create issue templates for the three common types:

• Feature/Improvement
  • Problem statement (who, what pain)
  • Approach sketch or link to spec
  • Acceptance criteria (Given/When/Then)
  • Analytics/telemetry plan
  • Rollout and fallback (flag, migration, comms)
• Bug
  • Steps to reproduce
  • Expected vs actual
  • Environment (browser/app version)
  • Severity & impact
  • Screenshot/video/logs
• Chore/Infra
  • Rationale
  • Definition of done
  • Risks

Use labels sparingly—think 6–10 global labels that actually drive views: security, performance, design, copy, migration, hotfix, good-first-issue. Avoid duplicating statuses as labels.

Set default assignee rules: creator is not the default assignee. Triager sets owner when the issue moves to Planned.

Fast, honest triage

Adopt a lightweight daily triage habit:

1. New issues land in Needs Triage (or Backlog if you prefer).
2. The triager of the day (PM or senior engineer) applies a priority (P0–P3), adds labels, sanity-checks the template, and sets target team.
3. If it’s a quick win (<1 hour), move straight to Planned or In Progress.
4. If it lacks context, add a blocking checklist item and keep it out of Planned.

For bugs, tie severity to SLA:

• P0/P1 production incidents interrupt the cycle and trigger an incident template (separate project).
• P2 within the current or next cycle.
• P3 queued and reevaluated during weekly backlog review.

Cycle planning that doesn’t drag

Rhythm matters more than precision. Use two-week cycles for most teams.

• Before planning: review last cycle’s carryover and velocity (completed points/issues). Keep a moving average to set capacity.
• During planning: select issues from Planned that fit capacity, not optimism. Put stretch items in a “Later this cycle” section or keep them in Planned.
• During the cycle: protect focus time; avoid ballooning the in-progress column. Track WIP explicitly.
• End of cycle: hold a quick demo from the completed list and a retro anchored on cycle metrics (completion, carryover, blocked time).

If you use estimates, stick to a simple T-shirt size (S/M/L) or Fibonacci points. The goal is capacity planning, not courtroom accuracy.

Projects and the roadmap layer

Projects give stakeholders a narrative above the issue level. Good projects have:

• Clear goal and non-goals
• Success metrics (leading and lagging)
• Scope expressed as a set of issues (not vague promises)
• Milestones or phases
• Owner and team(s) involved
• Status and risk notes updated weekly

Build a quarterly roadmap from projects. Keep statuses to On track, At risk, Off track, Paused, Done. Use the roadmap view in updates with leadership; never list every issue—projects tell the story, issues prove it.

Views that people will actually use

Set up a handful of shared views per team:

• My Focus: assigned to me, state not Done, sorted by cycle then priority.
• This Cycle: all issues in the current cycle grouped by status with WIP limits called out.
• Bugs Now: state not Done, label bug, sorted by created date descending with severity color.
• Blocked: state = Blocked across the workspace. Review daily.
• Recently Done: last 7 days, used for demos and release notes.

At the workspace level, add Leadership views:

• Projects – At risk/Off track
• Cross-team Blockers
• Throughput trend (issues done per cycle per team)

Keyboard muscle memory

Linear is designed to be driven with the keyboard. Encourage three habits:

• C to create, A to assign, P to set priority, D to set due/cycle.
• Cmd/Ctrl+K to jump anywhere.
• L to add labels, S to change state, B to add to a project.

A 10-minute team workshop on shortcuts saves hours every month.

GitHub/GitLab integration that closes the loop

Connect your repo so PRs and commits update issues automatically:

• Include issue ids in branch names or commit messages (e.g., app-123-fix-timezone).
• Configure transitions: open PR → In Review, merged to main → Ready to Stage/QA, tagged release → Done.
• Add a checklist to the issue template for QA and release notes; don’t mark Done on merge if QA is required.
• For feature flags, link the flag name in the issue; closing the issue requires flag on for target cohort.

This keeps product and engineering timelines aligned without manual status theater.

Slack and notifications that reduce noise

• Create a #changelog or #shipped channel that Linear posts to when an issue moves to Done with a label user-visible. Provide the PR link and short customer-facing summary.
• Route new bugs P1/P0 to a #incidents channel with a concise template and on-call mention.
• Mute generic “issue created” messages; focus on transitions that matter.

Design and research in the loop

• Link Figma files to issues and projects; keep a “Design source of truth” section in project descriptions.
• For research or discovery tasks, use an Issue type = Research with a done definition like “insights captured, decision recorded, next steps created.”
• Avoid design files hidden in chat; the issue keeps the chain of custody.

Analytics and the handful of metrics that matter

Linear’s built-in insights and simple exports are enough for most teams. Focus on trend lines, not absolute numbers:

• Throughput: issues completed per cycle. A steady or gently rising line is healthy.
• Cycle time: average time in In Progress → Done. Investigate spikes.
• Carryover: % of planned issues pushed to next cycle. Keep it under ~20–30%.
• Blocked time: average days issues spend blocked. Attack the common causes (env, approvals, dependencies).
• Bug rate: bugs created vs resolved per week; a rising backlog signals quality debt.

Share these in a compact weekly update: one chart, three bullets—what moved, where we’re stuck, what we’ll change.

Incident and hotfix flow

Production incidents need a sharp path separate from feature cycles:

• Label incident and route to a dedicated Incident project.
• Use a template that includes: severity, blast radius, owner (incident commander), comms plan, status timeline, mitigation, and follow-up actions.
• Hotfix issues skip the regular cycle but must still land in Done with a post-incident follow-up task created and scheduled.

Quality gates without bureaucracy

• Add a QA checklist to issue templates: unit tests updated, analytics events verified, docs/strings reviewed, rollback plan.
• For changes with user-visible copy, tag copy and add reviewer field for content/design.
• For regulated or sensitive areas, require two approvals before moving to Ready to Stage.

Keep the gates few but strict.

Conventions that make search and reports work

• Issue titles: start with the verb + object (“Add bulk invite to team settings”), not vague nouns (“Team settings update”).
• Projects: prefix with product area or customer segment (“Billing – Usage-based pricing v2”).
• Labels: publish a glossary. If a label doesn’t drive a view or report, delete it.
• Milestones: keep names consistent across teams (“M1 Discovery,” “M2 Build,” “M3 Rollout”).

Security and privacy

• Restrict private customer data to your CRM; reference IDs in issues rather than pasting PII.
• Use private teams for sensitive initiatives (pricing changes, acquisitions).
• Rotate integration tokens and limit bot scopes to what’s needed.

Two-week rollout plan

Day 1–2
Create teams, unify workflows, and set default labels and priorities. Write a one-page “How we use Linear.” Connect Git and Slack.

Day 3–4
Build issue templates; seed three projects that reflect current goals; create shared views (This Cycle, Blocked, Bugs Now).

Day 5
Run the first triage session; move only well-formed items to Planned. Teach the keyboard shortcuts.

Day 6–7
Plan the first two-week cycle using real capacity. Agree on Done definitions. Turn on the #shipped channel.

Day 8–9
Ship the first small batch; showcase Recently Done in a quick demo. Start logging cycle metrics.

Day 10
Integrate Figma links and codify design handoffs. Add a research issue type if needed.

Day 11–12
Tune Slack notifications to cut noise. Create leadership views for projects at risk and cross-team blockers.

Day 13–14
Hold the first retro with insights: throughput, carryover, blocked time. Capture 3 process changes and apply immediately to the next cycle.

Common pitfalls and how to avoid them

• Too many labels and statuses make boards unreadable. Keep them lean; let titles and descriptions carry nuance.
• Planning beyond real capacity leads to chronic carryover. Use a moving average of the last 3 cycles to size the next one.
• Merging equals Done can hide QA gaps. Preserve a Ready to Stage/QA state if your context requires it.
• Roadmaps full of aspirations erode trust. Projects should reference issues or concrete milestones; update status weekly with one sentence.
• Design and product context scattered in chat slows engineering. Link specs and Figma to issues; make Linear the single source of truth for “what” and “why.”

Final thoughts

Linear shines when you combine its speed with a few disciplined habits: daily triage, small cycles, crisp templates, and integrations that reflect reality without manual theater. Keep the model simple—Issues → Projects → Roadmap, paced by Cycles. Guard WIP, measure just enough to steer, and keep decisions and designs close to the work. Within two weeks, your team will ship more predictably, argue less about status, and spend more time building