Product Engineering Workflow in Linear

Use this page when touching Linear: Projects, issues, estimates, dependencies, cycles, milestones, labels, ownership, or status. For intake and weekly selection, start with Work Intake and Weekly Planning.

What Linear Owns

Object	Use
Triage issue	One seed record for new or unowned work.
Project	Governed product specification and project-level operating state.
Issue	Active work, delivery slice, support/bug, small fix, docs work, or execution step.
Milestone	Released-together customer scope or governed gate.
Cycle	Weekly planning container, not a release boundary.

Index owns governed challenge framing. Repos own implementation and shipped-output artifacts. Linear owns the operating view.

Project Rules

A governed Project should:

• contain the canonical specification
• link to or clearly name the Index challenge
• have the owning team set
• have a lead assigned
• have start and target dates once it is In Progress
• have status updates at least every two days while active, or sooner when state, risk, timing, or scope changes
• contain issues shaped as unit user stories or focused execution steps rather than broad buckets

If a Project is only a rough thought, keep it as a placeholder and make the missing specification work explicit.

Issue Rules

Story issues should:

• map to one unit user story
• belong to the relevant Project
• include acceptance criteria or equivalent completion rules
• show material dependencies or blockers
• carry the Kind / Story label
• have an estimate when selected into the current cycle or moved to In Progress

Execution-only issues should:

• point back to the parent story or scope issue when one exists
• represent one hours-scale delivery step
• carry exactly one of Kind / Technical, Kind / Spike, Kind / Validation, or Kind / Docs
• use blockedBy when completion is required before the parent can finish
• use relatedTo for supporting work that should remain visible but is not a blocker
• be assigned to the person doing the current step

If an issue grows beyond one focused delivery step, split it or push the broader scope back into shaping.

Estimates

BetterFleet uses Linear's T-shirt estimates:

Estimate	Meaning
XS = 1	Very narrow, tightly bounded change.
S = 2	Clean small slice with light cross-checking.
M = 3	Straightforward multi-file or multi-surface change.
L = 5	Broader story or shaping slice with meaningful coordination.
XL = 8	Rare; prefer splitting before assigning.

Estimate the intended shape of the issue, not elapsed calendar time. If a body of work contains multiple independently shippable slices, split it instead of inflating the estimate.

Readiness

An issue is ready for governed pickup only when:

• it belongs to the right Project
• it links to the parent story or scope issue when needed
• its scope and completion rules are clear
• material dependencies and blockers are visible
• estimate, owner, and status are current when active

A Project is ready for active delivery tracking only when the specification is usable, the owning team and lead are set, dates exist for active work, and Project issues are shaped as deliverable slices.

A milestone is ready only when it represents real released-together customer scope or a governed gate, with a target date when timing is being planned or communicated.

Cycles

• A cycle is a weekly planning container.
• Only work intended for the week should be in the current cycle.
• Issues in the cycle should already be actionable enough to plan.
• Story issues may sit in the cycle for visibility while day-to-day work happens through execution-only issues.
• Automatic rollover is a review prompt, not an automatic recommitment.
• Rolled-over issues stay in the cycle only when the team re-selects them.

Status And Ownership

• Do not move placeholder, not-ready, or wrongly shaped work into In Progress.
• Once work starts, move or keep the active issue in In Progress and assign it to the person doing the current step.
• If a story needs multiple delivery steps, prefer moving the execution-only issue to In Progress rather than the broader story.
• If ownership changes, reassign the issue instead of leaving ambiguous ownership.
• If the active issue does not match the work actually happening, correct the Linear state or switch work before continuing.
• If scope, dependencies, blockers, linked planning references, or owner change, update Linear.

Before proposing Done or In Review, confirm the work meets the done conditions in Product Engineering Delivery.

Labels

Use the existing Kind label group:

• Kind / Story
• Kind / Technical
• Kind / Spike
• Kind / Validation
• Kind / Docs

Out Of Scope

This is not a general Linear user guide. It defines BetterFleet's operating rules for keeping Linear accurate and useful.