Skip to main content

Backlog Management Process

Purpose​

This document describes how we manage the product and engineering backlog using Kanban in Linear, how we integrate with GitLab and Slack, and the rules and responsibilities that keep the flow predictable.

Tools​

  • Linear for issue tracking and workflow.
  • GitLab integration to link issues with merge requests (MRs) and automate state transitions based on MR events.
  • Slack integrations to notify the team when issues change state or require attention.

Workflow Overview (Kanban)​

We operate a pull‑based Kanban process. Issues move left to right through the following states. Ownership shifts as the issue progresses.

  • Backlog → Shaping → Refining → To Do → Prioritized → In Progress → In Review → Resolved
  • Blocked is a special state used when progress is impeded.

Roles and Responsibilities by State​

  • Backlog, Shaping, Refining, To Do: owned by the Product team. Product curates scope, acceptance criteria, and prioritization.
  • Prioritized, In Progress, In Review, Resolved: owned by Engineering. Developers execute, collaborate on reviews, and deliver.
  • Blocked: assigned to the Product Owner (PO) to remove impediments.

Prioritization and Pull Rules​

  • Developers are free to pick any issue as long as they respect prioritization. Always start from the top of the "Prioritized" queue.
  • A single assignee must not hold more than two issues in the same state (work‑in‑progress limit per person, per state).
  • Issues with Priority URGENT must be taken immediately.

GitLab MR Automations​

The Linear ↔ GitLab integration moves issues automatically when MRs change state:

  • On MR open → move issue to In Progress
  • On MR review request or activity → move issue to In Review
  • On MR merge → move issue to Resolved
  • Draft MR open and MR ready for merge → no automatic action

Developers must reference the Linear issue in branch names and MR titles/descriptions to ensure correct linking.

Slack Notifications​

We use Slack notifications to broadcast key state changes (e.g., moved to In Progress, In Review, Resolved, or Blocked). This keeps stakeholders aligned and accelerates unblocking.

Cycle Time Measurement​

  • We track cycle time for every issue in Linear, focusing on the assignee and the issue priority. Cycle time is measured from the first entry into In Progress until Resolved.
  • When an issue enters Blocked, the current assignee reassigns it to the PO. Blocked time is monitored to highlight systemic issues and external dependencies.

Operating Procedure​

  1. Pick the highest‑priority item from the top of To Do ("Prioritized").
  2. Self‑assign the issue (if unassigned) and move it to In Progress.
  3. Create a GitLab branch and MR, referencing the Linear issue in the title and/or description.
  4. Let the integration update the issue state as the MR progresses. If review is requested, the issue moves to In Review. When merged, the issue moves to Resolved.
  5. If you are blocked, move the issue to Blocked and assign it to the PO with a concise blocker description.

Quality and Policy Notes​

  • Respect WIP limits: do not exceed two issues in the same state per person.
  • Respect priority ordering: URGENT issues override the queue and must start immediately.
  • Keep issue descriptions and acceptance criteria up to date before moving to To Do.
  • Every issue must have at least three labels:
    • One Issue Type label (e.g., Tech-Debt, Research, Task)
    • One Project label (e.g., 🦋 Farfalla, 🦊 Volpe, 🐦‍🔥 Fenice, 🪼 Medusa, 🐰 Coniglio, 📖 Docs)
    • One Domain label (e.g., Commerce, SaaS, Identity, Content, Storefront, Domains, Projects)

Reporting​

  • Use Linear analytics to review cycle time distributions by assignee and by priority.
  • Review Blocked items and their causes weekly to reduce recurring impediments.
X

Graph View