Delivery Lifecycle

This is the standard we follow, not a description of how things happen today. When reality and this page disagree, reality is the bug.

This page owns the build loop: the cadence, the board states, and the two gates that bracket them. For the engagement end to end — lead, discovery, SOW, go-live, warranty, closure — see The Whole Picture (SDLC).

The cadence: Scrumban

Pure Scrum breaks in an agency because our specialists are shared across concurrent client projects — you can’t commit one person fully to one project’s sprint. Pure Kanban gives clients no rhythm. So we run a fixed 2-week cadence (the ceremonies clients feel) over a flow board with WIP limits (the daily work).

flowchart LR
  subgraph Cadence["Fixed 2-week cadence — per project"]
    P["Planning<br/>pull from backlog"] --> Demo["Client demo"] --> Retro["Retro"]
  end
  subgraph Flow["Flow board — WIP-limited, daily"]
    Ready["Ready<br/>DoR met"] --> InDev["In Dev"] --> CR["Code Review"] --> QAcol["QA"] --> UATcol["UAT"] --> Done["Done<br/>DoD met"]
  end
  P -.pulls into.-> Ready
  Done -.feeds.-> Demo

The load-bearing rules:

• WIP limits per column (e.g. In Dev ≤ 1–2 per developer). The single biggest fix for “everything started, nothing finished.”
• One 2-week rhythm across all projects so planning, demo, and retro land on a predictable beat.
• Bugs and support flow continuously through an expedite lane — they don’t wait for a sprint boundary.
• Definition of Ready gates the board; Definition of Done gates “Done”. Both enforced as Azure Boards column rules — see Boards & Work Items.

Board states map to work

stateDiagram-v2
  [*] --> Ready: DoR met
  Ready --> InDev: pulled (within WIP limit)
  InDev --> CodeReview: PR opened
  CodeReview --> QA: approved + merged
  QA --> UAT: passed
  UAT --> Done: client sign-off (DoD met)
  QA --> InDev: failed
  UAT --> InDev: change requested
  Done --> [*]

Definition of Ready (entry to the board)

A story is Ready only when all are true:

1. Clear problem statement — the user need, not a solution.
2. Acceptance criteria written and testable.
3. Scope small enough to finish inside one cadence.
4. Dependencies and designs identified (API contract, screens).
5. No open blocking question.
6. Performance impact stated — for a change on a per-request path, a loop over I/O, or a background job, the story states queries and external calls per run, before and after.

Definition of Done (a story is truly done)

1. Code merged via PR (build validation green, reviewed).
2. Tests written and passing in the same PR; the diff-coverage gate met on the changed lines.
3. QA passed against acceptance criteria.
4. Demoed / accepted by the client (or PM on their behalf).
5. No known regression; docs/AGENTS.md updated if behavior changed.