Skip to main content
  • Send to AI

Project Lifecycle

Purpose​

This document describes how a Project progresses from idea to post-deploy monitoring. It defines the appetite and maps the Product activities to the Kanban states defined in Backlog Management.

Appetite​

Appetite is the maximum time budget for a Project. We cut scope, not the date.

AppetiteTypical case
1 weekA small feature or a tightly scoped change
2 weeksThe typical Project. Most fall here
3 weeksMaximum ceiling. If a Project needs more, it is split

If a Project cannot fit in three weeks, it must be split into two or more Projects before starting, each with its own appetite and spec. A Project that overruns its appetite triggers a scope review, not a deadline extension. Any decision to move the date is explicit and is recorded in the Project.

Workflow​

We respect the eight Kanban states defined in Backlog Management: Backlog → Shaping → Refining → To Do → Prioritized → In Progress → In Review → Resolved (plus Blocked).

Each transition between states has exit criteria. Without those criteria met, the Project does not advance.

Pink states are owned by Product. Blue states are owned by Development.

Activities by State​

Backlog · Product​

The Project starts as an idea. The PM captures the problem, writes a one-paragraph description, and tags the candidate Initiative. No detailed spec yet.

Shaping · Product + QA​

The PM drafts the spec: problem, objective, EARS Acceptance Criteria (functional behavior + tracking events + state behaviors), no-goals, Quality Bar (open questions for Refining: Metric, Performance, Accessibility), risks. QA joins Shaping as author of the Test Plan and co-author of the Project: QA reviews every EARS requirement for ambiguity and drafts the Test Plan inside the spec.

The Test Plan must be complete before the spec can move to Spec Review.

See Spec and EARS and QA Collaboration.

Refining · Product​

The spec is reviewed with the CPO (Spec Review). Edge cases are closed, principles are checked, Milestones are set, and the Quality Bar open questions (Metric, Performance, Accessibility) are resolved with concrete numbers and explicit scope (R-16, R-18).

The Spec Review with the CPO is the exit criterion. Without the review validated and the Quality Bar fully resolved, the Project does not enter To Do.

To Do / Prioritized · Product → Development handoff​

The Project is ready for execution. It is ordered using the rules in Prioritization. The Dev Lead runs a Kickoff and breaks the Issues into technical tasks.

In Progress · Development​

Developers pull from the top of Prioritized, self-assign, and move the Issue to In Progress. A GitLab branch and MR are created referencing the Linear Issue.

In Review · Development + QA​

Code review by peers. QA testing happens within In Review as an extension phase. QA executes the Test Plan, reports bugs as Issues inside the same Project, and validates fixes.

Exit criterion: QA pass with zero Severity 1 or 2 bugs open. Without a passing QA validation, the Project does not reach Resolved.

Resolved · Development → Product handback​

The code is merged. Post-deploy activities:

  • Smoke test in production, run by QA.
  • 72-hour active monitoring window by Development: errors, performance, and the metrics defined in the Quality Bar.
  • Release Shout-out posted by the PM the same day as the deploy. See Cadences and Visibility.

"Deployed" and "Done" from the Framework both live inside the Resolved state as post-deploy activities; they are not separate Kanban columns.

Blocked · Product Owner​

When progress is impeded, the Issue moves to Blocked and is reassigned to the PO. Blocked time is monitored weekly to expose systemic issues. See Backlog Management for the operational detail.

Transition Checkpoints​

The critical exit criteria across the lifecycle:

TransitionOwnerCriterion
Shaping → RefiningQATest Plan complete. Every EARS requirement has at least one test case
Refining → To DoCPOSpec Review validated. Problem, EARS, Quality Bar, and principles all satisfied
In Review → ResolvedQAQA pass with zero Severity 1 or 2 bugs open

These checkpoints are non-negotiable: they protect the Dev team from unclear work and protect the user from untested releases.

X

Graph View