Skip to main content
  • Send to AI

Project Gates

Purpose​

Binary checklists for every Project transition. Each gate references the Framework Rule that mandates it. A Project that fails any gate item does not advance; it returns to the previous state.

Skills and agents use this document as the evaluation standard when reviewing Projects and Issues in Linear.

Gate 1: Entry (Backlog to Shaping)​

A Project enters Shaping when it has enough signal to start writing a spec.

  • One-paragraph problem description captured
  • Tagged to exactly one active Initiative (R-02)
  • Associated with one of the four Verticals (R-04)
  • Single PM owner assigned (R-05)
  • No duplicate: searched Linear for existing Projects covering the same problem

Gate 2: Spec Complete (Shaping to Refining)​

The most demanding gate. The spec must be complete, principles must be satisfied, and QA must have authored the Test Plan.

Spec structure (R-09)​

All seven sections present. A missing section means there is no spec.

#SectionCheck
1ProblemQuantitative when possible. Not a feature request dressed as a problem
2ObjectiveSingle testable sentence (R-10)
3EARS RequirementsAll requirements (functional, tracking, states) in EARS notation (R-13)
4No-GoalsExplicitly listed, not inferred (R-11)
5Quality BarThree items present as open questions/suggestions for Refining (see below)
6RisksEach risk has a mitigation
7Test PlanAuthored by QA. Every EARS has at least one test case (R-15, R-25)

Quality Bar (R-16)​

The Quality Bar at Gate 2 is a list of open questions and suggestions for Refining, not a list of closed answers. It must be resolved before Gate 3 (Spec Review), not Gate 2.

#ItemPass criteria at Gate 2
1MetricOpen questions stated (e.g., baseline source, target range candidates, measurement window options)
2PerformanceOpen questions stated (e.g., expected LCP/TTI band, admin response time band, perf-critical paths)
3AccessibilityOpen questions stated (e.g., which surfaces require WCAG AA, keyboard nav scope, aria patterns to evaluate)

Tracking and States are not in the Quality Bar. They are EARS Acceptance Criteria (R-13). See the EARS check below.

EARS requirements check (R-13, R-14, R-15)​

  • Every requirement uses one of the five EARS patterns (Ubiquitous, Event-driven, State-driven, Unwanted behavior, Optional feature)
  • Every requirement names the system precisely (storefront, reader, admin panel), not "the system"
  • Every requirement is verifiable: QA can write a test case for it
  • Every requirement has at least one test case in the Test Plan
  • No requirement encodes an implementation detail (R-31)
  • Requirements are identified with short codes (E1, UB1, O1) for Issue and test case referencing
  • Tracking events are present as Event-driven EARS with event name and payload fields (one EARS per event)
  • State behaviors are present as State-driven or Unwanted EARS for empty, error, loading, and offline, each with user-facing copy

Principles gate​

01 Simplification (R-19, R-20, R-21)​

  • The solution does not add an "advanced mode," "expert user" toggle, explanatory tooltip, onboarding banner, or tutorial as the answer to the problem
  • No new configuration is exposed to the end reader. Configurability lives at the tenant
  • The default flow works without the user learning anything new
  • If the Project removes an existing option: confirmed usage is below 5% of tenants (with exception for highly relevant customers)

02 Remove Blockers (R-22)​

  • The spec declares at least one of:
    • (a) A specific friction it removes on a common path (name the path), OR
    • (b) Two or more future initiatives it enables, each traceable to an active Initiative or to the Verticals framework
  • If claiming (b): the initiatives are listed by name and confirmed active in Linear or in the 2026 Verticals document

03 Shaped for Quality​

  • Three Quality Bar items present as open questions/suggestions for Refining (Metric, Performance, Accessibility)
  • Tracking events are written as EARS Acceptance Criteria, with event names and payload fields
  • States (empty, error, loading, offline) are written as EARS Acceptance Criteria, with specific user-facing copy
  • No Quality Bar item is deferred to a follow-up Project (R-18). Open questions must close before Spec Review (Gate 3)

04 Self-Serve (R-23, R-24)​

  • The Project does not add any new manual step for CS, DevOps, or Support
  • Tenant-gated features are activable from the tenant's panel or from Nova, not by CS ticket or DevOps script
  • If the Project touches an existing manual process: the spec states whether it eliminates or preserves it

Appetite (R-07)​

  • Appetite is set: 1, 2, or 3 weeks
  • If the Project cannot fit in 3 weeks: it has been split into two or more Projects, each with its own spec

Gate 3: Spec Review (Refining to To Do)​

The CPO validates the spec. This is a meeting, not an async approval.

  • Spec Review held with CPO (R-28)
  • All seven spec sections validated
  • All four principles confirmed satisfied
  • Quality Bar fully resolved: every open question from Gate 2 has a closed answer (Metric with baseline/target/window, Performance with numbers, Accessibility with explicit scope) (R-16, R-18)
  • Tracking events and state behaviors verified as EARS Acceptance Criteria (R-13)
  • Test Plan confirmed complete by QA (R-26)
  • Milestones set (from Spec Approved to Monitored)
  • Edge cases closed during review
  • Appetite confirmed or adjusted

Gate 4: Prioritization (To Do to Prioritized)​

  • Layer 1 — Initiative fit: the Project contributes to an active Initiative. If it does not fit, it is parked or rejected
  • Layer 2 — RICE score: Reach, Impact, Confidence, and Effort are computed. Effort caps at 3 (Projects cannot exceed 3-week appetite)
  • Projects are ordered by RICE score within their Initiative. No prioritization by opinion or stakeholder urgency
  • Expedite exception (R-35): if URGENT, authorized by CPO or PM. Within 20% of squad weekly capacity. Logged for monthly review (R-36)

Gate 5: Kickoff (Prioritized to In Progress)​

  • PM hands spec to Dev Lead at Kickoff meeting
  • Dev Lead confirms Issue breakdown and identifies technical risks
  • Issues are vertical slices (UI + logic + data), not horizontal layers. Each Issue produces something demo-able
  • QA confirms environments and test data are ready
  • Issues created inside the Project, each referencing the EARS identifiers
  • Each Issue has 3 labels minimum: Issue Type + Project + Domain

Gate 6: Release (In Review to Resolved)​

  • Code review complete (peer review)
  • QA executes Test Plan within In Review (R-29)
  • QA pass: zero Severity 1 or Severity 2 bugs open (R-30)
  • Non-blocking bugs (Sev 3, Sev 4) logged as Issues inside the Project (R-27)
  • Release Shout-out prepared: what shipped, who it impacts, links to metrics (R-38)
  • Manual operations: the release lists which it eliminates, or confirms none added (R-23)

Gate 7: Post-Deploy (Resolved)​

  • Production smoke test run by QA
  • 72-hour active monitoring window started by Development (R-39)
  • Monitoring covers: errors, performance, and the metrics defined in the Quality Bar
  • Release Shout-out posted in #releases the same day as deploy
  • Weekly update posted in #product-updates on the following Friday (R-37)

Issue Evaluation Checklist​

For individual Issues (inside a Project or in the shared zone).

All Issues​

  • Belongs to a Project or explicitly to the shared zone (R-06)
  • Three labels minimum: Issue Type + Project + Domain
  • Clear, descriptive title
  • Description explains what and why, not how (R-31)
  • Verifiable acceptance criteria
  • References the EARS identifier(s) it implements (if inside a Project)

Issues in critical flows​

Commerce (cart, checkout, payments, subscriptions), Identity (auth, permissions), Content (reading, download), and Integrations (external APIs, webhooks) require additional detail:

  • Business rules documented
  • Error handling defined with user-facing messages
  • Edge cases covered

Severity reference (for bug Issues)​

SeverityDefinitionBlocks release
Sev 1Blocker. Feature unusable or data loss riskYes
Sev 2Major. Key path broken for a significant user segmentYes
Sev 3Minor. Workaround exists or small user impactNo
Sev 4Cosmetic. No functional impactNo

Using This Document​

  • PMs use Gates 1 through 4 when shaping and reviewing Projects.
  • Dev Leads use Gate 5 at Kickoff and Gate 6 during review.
  • QA uses Gates 2, 3, and 6 (Test Plan authoring, Spec Review, and QA pass).
  • Skills and agents use the full document to evaluate Projects and Issues programmatically.
X

Graph View