Work Intake and Weekly Planning¶

Use this page when adding, routing, or selecting work in Linear. The goal is to keep Linear clean enough that the team can see the weekly plan without needing a spoken status update.

Operating Rules¶

Start unplanned work as one Linear triage issue.
Use Todo and the current cycle for this week's selected work only.
Create a Linear Project after the work is selected for definition or delivery planning.
Keep In Progress aligned with the work someone is actually doing, preferably one active issue per developer.
Keep backlog as accepted but unselected work, and resurface it through backlog management.
Use the governed workflow when work needs prioritisation, specification, coordination, or sign-off.

Triage Issue¶

A triage issue should be short. It only needs enough information to route the work.

Include:

Need or problem.
Why it matters.
Source or context.
Customer, CS, developer, platform, security, data, or release impact.
Decision needed next.

Keep the triage issue as the single seed until the work has been selected.

Routing¶

Route	Use when	Next action
Freestanding issue	The work is small, clear, low-risk, and has a visible done condition.	Select it by adding it to this week's cycle (`Todo` for this workflow), then assign and estimate it before pickup.
Support/bug	The work is a production, customer, or support issue without governed project context.	Keep it in support/bug triage until priority, owner, and next action are clear.
Governed candidate	The work is substantial, ambiguous, multi-person, customer-visible, cross-team, architectural, or likely to need sign-off.	Keep the triage issue as the seed until the work is selected for challenge framing or definition.
Backlog	The work is valid but not selected now.	Move to `Backlog` with enough context for later review.
Close	The work is not worth preserving as a future candidate.	Close as `Canceled` or `Duplicate` with a short reason.

Promotion Into Governed Work¶

When a triage issue may become governed work, first decide the next stage.

If the problem is not framed well enough, keep the issue standalone and use it to produce or update the Index challenge. The issue is done when the challenge exists and the next decision is recorded.

If the challenge is selected for definition, create the Linear Project then. Move or relate the seed issue into the Project as the first definition issue, usually named Define <project name>. That issue is done when the Project specification is signed off and the delivery issues are ready.

After sign-off, use the Project issues as the execution plan. Each delivery issue should be small enough for focused delivery, with acceptance criteria and visible dependencies.

Weekly Planning¶

Run Monday planning from Linear. Use spoken updates to resolve uncertainty, not as the source of the plan. Decisions made in the meeting should be reflected back into Linear through issue state, cycle assignment, owner, scope, blockers, or Project status updates when a Project is relevant.

Review:

Triage items needing a route.
Top backlog items surfaced through backlog management.
Rolled-over work from the previous cycle.
Ready small work.
Active governed projects and their next gate.
Blocked work needing a decision.

For each candidate, choose one action:

Add to this week's cycle (Todo).
Keep or move to Backlog with current context.
Promote to challenge framing or definition.
Split or narrow before pickup.
Close.

Automatic rollover is a reminder to review, not a commitment to keep doing the same work. Rolled-over issues stay in the cycle only when the team re-selects them for the week.

Backlog Management¶

Backlog is for accepted work that is not selected now. It is reviewed through normal backlog management, usually when Phillip or Nikki surface top candidates for planning. When moving something to backlog, leave enough context for a later decision: why it matters, who is affected, and any known trigger, dependency, or priority lens.

Self-Serve Pickup¶

Self-serve pickup means choosing the next ready item, not starting parallel side work. Prefer finishing or handing off the current In Progress issue before starting another one.

Developers can pick up work without extra approval when all of these are true:

The issue is selected into this week's cycle.
Scope and done condition are clear.
Expected impact is low and local.
The issue has an owner, estimate, and enough context to finish.

Small freestanding work should still be weighed against the main weekly plan and the cost of context switching. If it is not urgent enough to interrupt, put it through planning before pickup.

Pause and surface the work before pickup when it affects customers, CS/support, other developers, permissions, security, data model or migrations, integrations, API contracts, feature flags, release communication, or project scope.