Skip to main content
  • Send to AI

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.

Squad Structure​

The DEV team is organized into two squads, each with distinct areas of ownership. Issues should be created in the appropriate squad's board based on the domain.

Commerce Squad (COM)​

Board: Commerce Board

Responsible for all customer-facing commerce experiences and back-office tools:

  • Storefront: Browsing, searching, filtering, shopping cart, checkout
  • My Publications: User's account, user's lists
  • Digital retail: Subscriptions and paper sales
  • SEO
  • Institutional sales and integrations: LTI, SAML, IP, Referrer, Orders API, Auth Token
  • Gateways and Publica Payments
  • Payouts
  • Cross border
  • Control Panel: Users, plans, prices, coupons, settings, manual and bulk content management
  • Sales Analytics: Sales, coupons, subscriptions, visits, etc.
  • SaaS: New customers, customer plans and billing
  • Integration with other team's tools: Intercom, HubSpot, company website integration (but not the company website itself)

Fullfilment Squad (FUL)​

Board: Fullfilment Board

Responsible for content processing, delivery, and consumption experiences:

  • Reader (web + apps): EPUB, PDF, Audiobook
  • Native apps: Mobile (iOS, Android) and desktop (macOS, Windows)
  • Automated Content Intake: Bulk imports from ONIX, content automations (e.g., La Tercera)
  • Content Processing: Conversion and optimization for PDF, EPUB, and Audiobooks
  • Content Delivery: CDN
  • Content Security
  • Content Consumption Analytics: Reading sessions, listening sessions, interactions (highlights, notes, dictionary, TTS, etc.)

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, Bug, Feature, Improvement)
    • 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