1.4 Linear Projects
Projects provide shared context for related work. Choose its lifecycle when creating it so everyone understands what its status and dates mean.
Project setup¶
| Field | Convention |
|---|---|
| Name | Use the product area's name for ongoing work, or the intended delivery for a bounded effort. |
| Lead | Name one person responsible for keeping scope, priorities, and progress understandable. |
| Teams | Associate the teams doing the work. |
| Description | Use the description template below. |
| Status | Reflect the actual stage of work. A maintained product's existence alone does not mean active development. Choose the closest existing workspace status. |
| Priority | Express relative importance across projects when useful. Review it as priorities change. |
| Dates | Use genuine forecasts or commitments. Leave the target date empty for permanent projects; date their meaningful deliveries instead. |
| Resources | Link relevant designs, technical documentation, and evidence. Keep each document in one authoritative location. |
Description template¶
Keep each section to a few sentences. Maintain owners, priorities, dates, and resource links in their dedicated fields.
Purpose¶
Who benefits from this project, what problem does it aim to solve for them, and why does solving it matter?
Scope¶
What belongs in this project? State important exclusions when needed.
Done when¶
For bounded projects only: what observable result completes the project? For ongoing projects, omit this section and put completion criteria on milestones.
Milestones¶
Create a milestone when several issues contribute to a meaningful delivery, such as a pilot or public release. Give it a short name and a completion condition; add a target date when useful.
Attach contributing issues to the milestone. Routine fixes may have no milestone.
Maintenance¶
The lead updates project context when direction changes and reviews active projects during normal planning:
- Confirm the current delivery, remaining scope, and blockers.
- Adjust milestones, forecasts, and priorities when evidence changes.
- Write a short project update when collaborators need it: delivered, next, blocked, or decision needed.
- Complete bounded projects when their outcome is verified. Keep ongoing projects while the product area remains supported; retire them deliberately when that responsibility ends.