Goal
Ship working software in thin slices — something the client can click every sprint, every line reviewed.
Inputs → outputs
Inputs
- Sprint backlog with acceptance criteria
- Mockups, design tokens, API contract
- Definition of Done
Deliverables
- Source code in the repo with a clean history
- Staging build every sprint + change notes
- Updated API docs, developer handbook
- Weekly status reports
Teams & roles
- Engineering (FE · BE · Mobile)writes code, peer review, migrations
- Data & AIAI / data features: prompts, evals, cost caps
- Quality Assurance (QA/QC)writes tests alongside, checks stories against DoD
- Solution Architecturedesign review on larger PRs
- Project Management / Scrum Masterruns sprints, demos, CRs
- Client (Product Owner / sponsor)attends demos, gives feedback, approves CRs
RACI matrix
R — does the work · A — accountable, final sign-off (exactly one A per activity) · C — consulted before · I — informed after.
| Activity | BA | UX | Arch | PM | Dev | Sec | Data | Client |
|---|---|---|---|---|---|---|---|---|
| Backend & migrations | · | · | C | · | A | · | · | · |
| Frontend / mobile | · | C | · | · | A | · | · | · |
| AI features: prompts, evals, cost caps | · | · | · | · | R | C | A | · |
| Code review & merge | · | · | C | · | A | C | · | · |
| Sprint demo | · | · | · | A | R | · | · | C |
| Change request handling | R | · | · | A | · | · | · | C |
BA = Business Analysis (BA); UX = UX/UI Design; Arch = Solution Architecture; PM = Project Management / Scrum Master; Dev = Engineering (FE · BE · Mobile); Sec = Application Security (AppSec); Data = Data & AI; Client = Client (Product Owner / sponsor)
Quality gate
Each story meets DoD: reviewed, tested, running on staging.
Entry criteria
- Green CI, staging ready
- Sprint stories have acceptance criteria and approved designs
Exit criteria
- Every completed story meets the Definition of Done
- Sprint demo held, feedback recorded
- No open critical defects in delivered work
- API docs and developer handbook updated
- AI-assisted changes reviewed by someone else + labelled
Activities
- 1.Backend: APIs, business logic, versioned DB migrations
- 2.Frontend / mobile: UI from the design system, loading / error / empty states
- 3.AI (if any): versioned prompts, eval sets, cost ceilings
- 4.Short feature branches → Pull Request → review → merge
- 5.End-of-sprint demo; every scope change goes through a CR
Checklist
Tick to self-review — 0/7. Ticks stay in this browser only and are not sent anywhere.
Document templates
Markdown (.md) files: open in any editor, or paste into Word / Google Docs. Each states its purpose, who fills it in and when.
Client involvement
- Attend sprint demos, try staging, reply within 2–3 days
- Re-prioritise the backlog; approve or reject CRs
Tools
- TypeScript · Node.js · Next.js
- Java · Spring Boot
- React Native
- PostgreSQL · Prisma
- VS Code · Claude Code
Reference standards
- Google Engineering Practices — Code Review
- What reviewers look for, how to keep PRs small
- GitHub Flow / trunk-based
- Short-lived branches, frequent merges, main always deployable
- ISO/IEC 27001:2022 — Annex A 8.25–8.28
- Secure development life cycle and secure coding
Common pitfalls
- Huge PRs reviewed superficially
- "Works on my machine" but never ran on staging
- Changing scope on verbal requests without a CR
- Assuming a green type-check means a green build
Real example
cuongthai.com, 8 Aug 2026: renaming an enum value passed the whole checklist yet broke the seed script in production — tsc --noEmit did not cover the seed folder, and the seed carried its own copy of the type. The checklist now has a separate seed type-check and a real seed run. Verify by running, not just by reading.Where to learn
Subjects and courses on cuongthai.com that teach this stage’s work.