---
# System prepended metadata

title: Linear Process Overview
tags: [' project management', v3]

---

---
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?