Goal
Lay the rails before running the train: a baselined plan, repository, automated checks, three separate environments and a reporting rhythm.
Inputs → outputs
Inputs
- SOW, SRS, SDD
- Prioritised backlog
Deliverables
- Baselined project plan + sprint calendar + Definition of Done
- Repo with README, CONTRIBUTING, .env.example and a green CI pipeline
- A staging environment the client can open
- Risk register and communication plan
Teams & roles
- Project Management / Scrum Masterplan, sprint calendar, risks, communication
- DevOps / SRECI/CD and environments
- Engineering (FE · BE · Mobile)repo, branching, project skeleton
- Quality Assurance (QA/QC)co-designs the Definition of Done
- Project Management Office (PMO)approves the plan baseline
- Client (Product Owner / sponsor)appoints the Product Owner, follows the board
RACI matrix
R — does the work · A — accountable, final sign-off (exactly one A per activity) · C — consulted before · I — informed after.
| Activity | PM | Dev | QA | Sec | Ops | Infra | PMO | Client |
|---|---|---|---|---|---|---|---|---|
| Project plan & sprint calendar | A | C | C | · | · | · | C | C |
| Definition of Done | A | R | R | · | · | · | · | · |
| Repo, branching, PR template | · | A | · | · | C | · | · | · |
| CI & dev / staging / production | · | C | · | C | A | R | · | · |
| Risk register & communication plan | A | · | · | · | · | · | C | I |
PM = Project Management / Scrum Master; Dev = Engineering (FE · BE · Mobile); QA = Quality Assurance (QA/QC); Sec = Application Security (AppSec); Ops = DevOps / SRE; Infra = Infrastructure & Network; PMO = Project Management Office (PMO); Client = Client (Product Owner / sponsor)
Quality gate
CI green on main; staging serves an end-to-end "hello world"; plan baselined.
Entry criteria
- SDD and first-sprint API contract frozen
- Team and roles confirmed
Exit criteria
- Baselined plan: scope, schedule, resources, risks
- Definition of Done agreed
- CI green on main
- Staging runs an end-to-end "hello world"
- Client has access to the work board
Activities
- 1.Slice the backlog into 1–2 week sprints, agree a Definition of Done
- 2.Create the repo, branch conventions, PR template, protect main
- 3.Set up CI: lint, type-check, tests, image build on every PR
- 4.Create dev / staging / production, with separated env vars and secrets
- 5.Start the risk register, communication plan and weekly report
Checklist
Tick to self-review — 0/5. 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
- Appoint one approver (client-side product owner)
- Get access to the work board to follow progress
Tools
- GitHub / GitLab
- GitHub Actions
- Docker Compose
- Jira / GitHub Projects / CT Work
Reference standards
- The Scrum Guide (2020)
- Scrum events, roles and artefacts
- The Twelve-Factor App
- Config in env, separate build/release/run, dev/prod parity
- Conventional Commits 1.0.0
- Machine-readable commit message convention
- ISO 31000:2018
- Risk management — principles and guidelines
Common pitfalls
- Coding before CI exists → technical debt from day one
- Sharing a database between staging and production
- A vague Definition of Done
- No baseline, so slippage cannot be measured
Real example
cuongthai.com: pushing to main no longer deploys. Both deploy workflows are manual-only because they once raced each other on every push and caused real outages (feed 500s while the schema lagged the image, containers recreated mid-flight). Deploying is a deliberate script, not a side effect of pushing.
Where to learn
Subjects and courses on cuongthai.com that teach this stage’s work.