---
tags: v3, project management
---

# Linear Process Overview

## What is Linear?

- [Linear](https://linear.app/) is a powerful project management tool with GitHub integration
- Streamlines processes, sprints, bug tracking, milestones, etc.
- Multiple teams (design, development, product, outreach, etc.) can all work together without needing GitHub, but Linear integrates *with* GitHub

## Workflow

- Everything is oriented around the *issue*
- Templates can be used at any stage
- GitHub integration allows for automated status updates and PRs can be linked directly to Linear issues
- Issues flow through differnet Statuses:
- Backlog -> Design -> Spec -> Ready -> In Progress/Blocked -> In Review -> Done/Cancelled
- **Backlog**
- Purpose:
- Issues start here and detail is gradually added as it's available
- These can be bugs, feature requests, general ideas, etc.
- Progression:
- Moves when it's decided that the team should work on these
- If design is already available (or it doesn't need design) -> **Spec**
- If it needs design and there aren't already design files -> **Design**
- Not all issues may require design, so some may move into **Spec** right away
- **Design**
- Purpose:
- Issues here require design work such as Figma wireframes
- Examples: UX/UI designs for specific features, UI mockups for specific components
- Design team will largely work within these issues and own the processes around managing this work and handoff
- Design team may have an internal process for estimating and scoping, and would add these estimates to the effort level/issue details
- Progression:
- Once there is a Figma design associated with the issue, this moves into **Spec**
- Design team can decide if they want their work to also move to **In Progress**
- **Spec**
- Purpose:
- Issues here are ready to be specced/scoped for development work
- Suggested to follow a specific template for this -- ensuring that there are clear details and a rough estimate of the work
- Add clear deliverables and break out any sub-tasks if this is a larger issue
- Progression:
- Once all the details are added, this moves to **Ready**
- **Ready**
- Purpose:
- Issues here are specced, contain designs (if relevant) and are meant to be picked up by devs
- Ideally, these are in a state where they can be prioritized and organized by project/feature/milestone and integrated into the Sprint cycle based on priority
- These issues *should* have all information needed for a dev to grab and begin working on
- During planning meetings these are picked up by specific folks who are then the owner/lead of the issue
- There should be a rough understanding of the *Effort* estimate already, but devs can give a rough estimate for issues they pick up
- Progression:
- When work is picked up and started the issue moves to **In Progress**
- Cards moving from this stage should have a lead/owner and effort estimate, and are ready for immediate work
- Ideally, no additional speccing or design work needed - at least at initial review, but devs should communicate anything that they come across as needing additional design clarity by signalling via comments or in a huddle
- **In Progress**
- Purpose:
- Progression:
- **Blocked**
- Purpose:
- Progression:
- When no longer blocked this moves back to **In Progress**
- This isn't a "backwards move" -- it's a parallel move signalling that an issue is no longer Blocked
- **In Review**
- Purpose:
- PRs that are linked to Linear issues are automatically moved into this status
- Generally, this can include the following:
- Code review, design review (where appropriate), general QA first pass
- Progression:
- PR approved and merged into the appropriate branch automatically moves this to **Done**
- **Done**
- All issues here have been completed (Design work, or Dev work merged into `develop` branch)
- At end of cycle, all changes are reviewed holistically before merging `develop` into `prod` branches
- At this point, there would be a feature release based on the work done during the cycle

### Sprint Planning

- Each kickoff we meet as a team and look at the Backlog (or unfinished/in progress items from last sprint) and determine as a team which are priorities
- Each sprint can orient around a *feature* or independent workstreams

## Other Areas to Demonstrate

### Roadmap

### Timeline View

### Feature Request Form

## Questions

- When/does it make sense to move from GitHub Projects to Linear?