Linear Issue Tracking: An Honest Review for Agencies

Linear issue tracking is how Linear handles issues, projects, and cycles. Filing an issue is fast and the statuses are strict, which suits a team that ships one product. At an agency it keeps engineers moving, but it starts to strain once several clients, contracts, and definitions of "done" share one board.

What linear issue tracking is built to do

An issue is a small unit of work with an owner, a priority, a team, and a state. The usual states are Triage, Backlog, Todo, In Progress, In Review, Done, and Cancelled. Every state you add is a process you have to teach. Projects group issues toward a dated outcome. Cycles are one- or two-week windows, and unfinished work rolls into the next one.

The product is opinionated. You get a keyboard-first app, a clean issue page, GitHub and GitLab sync, Slack unfurls, and shared views. What you don't get is a workflow engine you can bend into any shape, so teams that want Jira's scheme-per-project model will end up fighting it. See software like Jira without the configuration overhead.

A linear issue tracker runs a short loop. Someone files an issue, or a GitHub issue becomes one. Triage accepts or cancels it, and a cycle picks it up. In Review starts when a pull request opens, and Done means merged or shipped. Linear's docs cover the shortcuts and sync rules.

Who it fits

Linear fits a product company with a few teams, one backlog culture, and engineers who work from the issue list, as long as everyone agrees on what In Progress means.

Agencies often don't agree on that. A retainer wants a weekly review, a fixed-scope build wants a sign-off gate, and a care plan cares about response time. Teams, projects, and labels can stand in for all three, but they won't stop someone dragging a client-blocked issue to Done because the cycle report looked bad. Linear records what you tell it and knows nothing about the contract.

How the moving parts behave

Issues, projects, and cycles

Sub-issues help when a feature splits cleanly. They get in the way when the parent is a vague promise and the children are the real jobs. A dated project whose issues each take a few days works better.

Cycles make rollover visible, and that can train a bad habit. The same issue rolls four times because the client hasn't answered, and the report makes it look like the team slipped. Keep "waiting on client" out of the building states. Give each outcome its own project ("Q3 site relaunch") instead of one forever-project per client, and close it when the outcome ships.

Triage and views

New issues sit in Triage until someone accepts or cancels them. Whether it came from a client email, a Slack DM, or a production bug, each one raises the same questions: which client, which contract, is it in scope, and who owes the reply?

Keep the views small:

• My issues due this cycle
• Blocked on the client, by project
• In review for more than two days
• Triage older than one business day

What agencies gain

Filing an issue, assigning it, and starting a branch takes seconds. Engineers who hated Jira tend to stay because the issue page stays out of their way.

Saying "It's in ENG-142" is better than digging through a Slack thread. Git sync ties the pull request to the issue, and In Review shows who is carrying the review load. On a client call, a one-line cycle goal is easier to defend than an open backlog.

Where linear issue tracking strains

One status model, several contracts

A retainer expects a digest. A launch expects a staging link and a punch list. A security review expects a named reviewer. Labels such as retainer and needs-security-review can mark the difference, but they can't make In Review mean three things.

So write the meanings down. In Review means a pull request is open and a human is assigned. It does not mean you emailed the client. Client-facing status belongs in the update you send, and leads and renewals belong in a CRM. Putting sales stages inside issue states makes both records worse.

Scope and the quick fix

"Can we also change the header?" arrives as a comment, becomes a sub-issue, gets estimated at an hour, and the cycle absorbs it. Then the date moves, and nobody can point to when the scope changed.

A change that affects the date or the price should be its own issue, linked to the parent, with the client's request quoted. Linear won't enforce that, so triage has to.

Agents that write code

Linear issue tracking assumes a person picks up the issue and does the work. Teams that ask Claude Code or Codex to draft a change still need the constraint, the definition of done, and a plan someone can reject before merge. The description can hold that text, but it doesn't check the plan against team rules or turn a call into a reviewed ticket. The same gap shows up in Jira AI features in 2026 and in ClickUp AI versus purpose-built agent workflows.

Falrow is built for that gap. Slack messages, calls, and Sentry errors become tickets. Claude Code and Codex plan from the git repository under workflow rules, with version-checked writes, and the roadmap is counted from those tickets. Falrow is in private beta, with access by request. The reasoning is on why Falrow is built agent-first. Rules written into a description still go unchecked.

What a client will accept

Cycle completion is an internal number. A client wants to know what shipped, what is waiting on them, and whether the date holds. Put three lines on every client-facing issue: the outcome, the blocker if there is one, and the next date you will touch it.

A worked example: one retainer week

Northwind is a fictional client with two engineers, one PM, and a five-day cycle. Monday triage has six items. Four are accepted and two duplicates are cancelled.

1. ENG-310. Checkout fails on an empty discount field. Production, in scope, high priority.
2. ENG-311. Replace the homepage hero, requested in Slack. This is a change request, so it gets checked against this week's hours before it enters the cycle.
3. ENG-312. Staging login is broken for the reviewer. It blocks sign-off, so it goes to Todo the same day.
4. ENG-313. A search-vendor spike. It stays in Backlog until it has its own estimate.

The cycle goal is one line: unblock staging, fix checkout, ship the hero if hours remain.

By Wednesday, ENG-312 is Done, ENG-310 is In Review, and ENG-311 is In Progress. A Slack message asks for a font change, and the PM files it as ENG-314 in Triage, either for next cycle or to swap with the hero.

On Friday, ENG-310 is Done. ENG-311 rolls because the client's comments arrived late. The update names ENG-311 and the client as the reason, and the cycle report should say the same.

The rules that made the week work don't come from Linear: triage before lunch, one meaning for In Review, new requests as new issues, and blockers named by identifier.

Linear next to other agency tools

Need	Linear	Jira	A stricter, agent-aware workspace
Engineer adoption	High. The app stays fast.	Drops if an admin does not keep config small.	High when done still means a ticket.
A workflow per client	Weak. One status model is the point.	Strong, and the usual source of clutter.	Only with a few explicit stages.
Client sign-off	A state you can add, and skip.	A rule you can overbuild.	Fits when the gate is a reviewed ticket.
Coding agents	The issue is a brief. The repo is separate.	Similar, with more fields.	Fits when the plan is checked before the write.
Time to a useful board	Hours.	Days if you migrate schemes.	Hours if you refuse extra fields.

Jira alternatives for teams that build with AI agents covers the Jira column. Leaving Jira and leaving Linear are different decisions.

When to stay, and when to move

Stay if engineers already live in Linear, clients accept a short update, one status model covers the contracts, and a human still owns the merge. In that case, tighten triage, scope, and waiting-on-client handling first. One stricter cycle may be enough.

When linear issue tracking is the wrong center

Move when Slack, a call, or Sentry is the real source of work and the issue is a copy that drifts. Also move when agents open pull requests nobody checks against the ticket, when the same issues keep rolling because nobody asks why, or when the roadmap is a slide instead of a count of tickets. Read what to pick when you outgrow Linear and match the next tool to the work you already have.

Falrow is aimed at that case. It has custom stages and triage, cycles with reviewed rollover, a CRM where meeting notes become reviewed tickets, cycle-time percentiles, and Monte Carlo forecasts from those tickets. Details are on the features page, and pricing is on request. None of that helps if the board isn't honest to begin with.

Try one client for one cycle. Write down what each status means, including "waiting on client," and don't use Done for it. File every new request as its own issue. Send one update the client could forward. At the end you'll either keep Linear or be able to name the failure a new tool has to fix.

FAQ

Is Linear issue tracking good for agencies?

It's good for the engineering core: fast issues, cycles, and pull requests tied to identifiers. It fits poorly when each client needs a different approval chain, when scope arrives through chat, or when the board has to match the contract. Use it for delivery and keep the commercial pipeline somewhere else.

How is a linear issue tracker different from Jira?

Linear is opinionated and quick to learn. Jira is configurable and easy to bury in schemes. Linear pushes one status model and cycles, while Jira can model almost any process, including ones you'll regret. Agencies that drowned in Jira config often prefer Linear. Agencies that need a different gate per client often end up rebuilding that gate outside Linear.

Can clients see Linear issues?

You can invite clients as guests to a team or project, or send a summary to people who shouldn't have a login. Guest comments mean engineers end up answering twice, so many agencies keep the board internal and cite identifiers in a short update.

Does Linear replace a roadmap and a CRM?

It can stand in for a roadmap of dated projects, but it doesn't replace a CRM. Renewals, and what a call promised, belong in a different record from ENG-310. If notes have to become tickets a reviewer accepts, write that step down. A roadmap slide that isn't tied to issues drifts the first time a cycle rolls.