Consentik / Internal Doc
Sprint Workflow with AI
— Document №01
Internal / Process
Hanoi · 2026
Mike & Team
Sprint Workflow Manual

Consentik
Task Flow.

Quy trình làm việc cho team PO, Dev, Tester khi triển khai tính năng với sự hỗ trợ của AI — từ ý tưởng tới production, và sau đó.

Audience
PO · Dev · Tester
Scope
End-to-end
Tooling
AI-augmented
Status
Living document
Table of Contents

Bảy chương,
một quy trình.

Tài liệu này define cách team Consentik vận hành mỗi sprint với AI làm trợ thủ — không phải làm thay. Mỗi role giữ trách nhiệm cuối cùng cho output của mình.

  • 01 Roles & Responsibilities PO · Dev · Tester
  • 02 Sync Points trong Sprint 04 ceremonies
  • 03 Definition of Ready DoR Checklist
  • 04 Review Matrix Who · What · SLA
  • 05 Feature Flag Lifecycle Create → Cleanup
  • 06 Knowledge Management 3 layers
  • 07 Rules Non-negotiable
Chapter 01 / Roles · 1 of 3
The Strategist

PO/PM.

"Define the why and the what — leave the how to Dev."

Skills
superpowers:brainstorming superpowers:writing-plans ui-ux-pro-max
Discovery & Planning
  • Brainstorm với AI dựa trên data thực tế — analytics, support tickets, user feedback, competitive analysis
  • Validate ý tưởng để tránh trùng với feature đã có
  • Lên feature với đầy đủ business logic, user story, DoD, AC, UI/UX requirement, wireframe
  • Define success metrics — KPI cụ thể đo lường sau deploy
  • Đảm bảo tính năng đạt Definition of Ready trước sprint
  • Mỗi tính năng có 1 unique feature flag (ID)
Trong Sprint
  • Review scope-level của implement plan, không review chi tiết kỹ thuật
  • Available giải đáp business question từ Dev/Tester
  • Update spec khi có thay đổi và communicate với cả team
Sau Sprint
  • Đo success metrics đã define, đánh giá tính năng có đạt mục tiêu không
  • Quyết định khi nào tắt/xóa feature flag sau khi feature stable
Chapter 01 / Roles · 2 of 3
The Builder

Dev.

"AI viết code, nhưng Dev chịu trách nhiệm về implementation."

Skills
dev-break-task dev-code-reviewer dev-test-driven-development dev-e2e-test dev-quality-gate
Pre-implementation
  • Kiểm tra feasibility, feedback với PO nếu cần điều chỉnh
  • Implement plan có 2 phần: Technical Summary (PO review) + Technical Detail (peer Dev review)
  • Break task theo từng User Story để kiểm soát AI
  • Review test case của Tester (xem Review Matrix)
Implementation
  • Thực hiện theo TDD cho mỗi task
  • Viết unit test, đảm bảo coverage
  • Self-review (AI) và peer code review (human)
Pre-deploy
  • SonarQube quality gate, integration / e2e test
  • Update API docs trước khi deploy
  • Deploy staging chỉ khi: unit test ✓ SonarQube ✓ test case ✓
Deploy & Post-deploy
  • Monitor logs, errors, performance — đặc biệt feature liên quan GDPR
  • Rollback plan qua feature flag nếu phát hiện bug
Chapter 01 / Roles · 3 of 3
The Guardian

Tester.

"AI viết test case, con người verify — và test cả những gì AI miss."

Skills
tester-task-flow tester-test-api tester-write-test-cases tester-performance-test
Test Case Design
  • Dùng AI viết test case dựa trên plan từ PO
  • Verify test case đầy đủ, rõ ràng, cover Acceptance Criteria
  • Update test case khi có thay đổi từ PO/Dev
Trong Sprint
  • Viết test case song song với Dev code, không chờ code xong
  • Thứ tự chạy: API → Integration → E2E → Human-in-the-loop → Performance
  • Regression test cho các tính năng cũ liên quan
  • Test trên môi trường thực: Shopify dev store, Wix sandbox
Test Categorization · 5 loại
  • Human-in-the-loop — UX, visual, edge case phức tạp, exploratory testing
  • E2E / Integration — case có thể automate qua AI hoặc script
  • API test — happy path, edge case, error case, security cho từng endpoint
  • Performance test — API critical, load test, response time benchmark
  • Compliance test — GDPR/CCPA/LGPD scenario, cross-browser, multi-language, RTL (đặc thù Consentik)
Chapter 02 / Sprint Ceremonies

Bốn điểm đồng bộ.

Cả team cần gặp nhau ở đúng những thời điểm này — không hơn, không kém.

01
Sprint Planning
Đầu sprint
  • PO present plan, spec, success metrics
  • Cả team review DoR cho từng task
  • Dev estimate, raise concern kỹ thuật
  • Tester confirm đủ thông tin viết test case
  • Output: Sprint backlog confirmed, mỗi task có owner và feature flag
02
Daily Meeting
Hàng ngày · 15 phút
  • Hôm qua làm gì, hôm nay làm gì, blocker gì
  • Flag điểm cần sync: implement plan, test case, AI blocker
  • Không giải quyết vấn đề trong daily — schedule meeting riêng
03
Sprint Review / Demo
Cuối sprint
  • Demo các feature đã hoàn thành cho stakeholder
  • PO confirm Acceptance Criteria
  • Quyết định feature nào ready cho production
04
Retrospective
Cuối sprint
  • Cái gì hiệu quả, cái gì không
  • Đánh giá cách dùng AI: skill nào hữu ích, prompt nào cần cải tiến, AI fail ở đâu
  • Action items cho sprint sau
  • Update flow, skill, rules nếu cần
Chapter 03 / Quality Gate Before Sprint

Definition of Ready.

Một task đủ điều kiện vào sprint khi đạt cả 4 nhóm tiêu chí dưới đây.

01 Về Spec

  • User story rõ ràng (As a... I want... So that...)
  • Acceptance Criteria cụ thể, đo lường được
  • Business logic được mô tả đầy đủ
  • Wireframe / design (nếu là feature có UI)

02 Về Kỹ thuật

  • Đã có unique feature flag (ID)
  • Dependencies với feature khác đã được identify
  • Đã có thư mục /docs/features/{feature_flag}/

03 Về Business

  • Success metrics đã được define
  • Compliance check (GDPR/CCPA/LGPD nếu có)
  • Cross-platform requirement rõ ràng (Shopify vs Wix)

04 Về Team

  • Dev đã estimate sơ bộ (không vượt quá ngưỡng story points)
  • Không có blocker hoặc dependency chưa giải quyết
  • Tester confirm có đủ thông tin để viết test case
Task không đạt DoR → không đưa vào sprint, trả về backlog cho PO bổ sung thông tin.
Chapter 04 / Who Reviews What

Review Matrix.

PO không nên review chi tiết kỹ thuật. Test case thông thường chạy async để không block.

Artifact Reviewer Block? SLA
Plan / Spec Dev + Tester (feedback) Có Trước sprint planning
Implement plan (summary) PO Có 1 ngày
Implement plan (detail) Peer Dev Có 1 ngày
Code Peer Dev + AI Có Trong ngày
Test case (critical path) Dev Có 1 ngày
Test case (thông thường) Dev Async 2 ngày · auto-approve nếu không phản hồi
API docs Peer Dev Không Trước deploy production

Lưu ý quan trọng

  • — PO chỉ review scope-level, không review chi tiết kỹ thuật
  • — Test case critical path (payment, consent logic, GDPR compliance) bắt buộc Dev review trước khi chạy
  • — Test case thông thường: Tester cứ chạy song song, Dev comment async để không block
Chapter 05 / Don't let flags live forever

Feature Flag Lifecycle.

Feature flag là scaffold — dựng lên để xây nhà, xây xong phải tháo. Để lại sẽ vướng và nguy hiểm.

01
Tạo
02
Active
03
Stable
04
Cleanup
05
Xóa

Phân loại 4 loại flag

Loại Mục đích Cleanup?
Release flag Bật/tắt feature mới khi deploy Có — sau 4-8 tuần stable
Experiment flag A/B testing Có — sau khi có kết quả
Ops flag (kill switch) Tắt khẩn cấp khi có sự cố Không — giữ lại
Permission flag Bật theo plan/role (Free/Pro/Enterprise) Không — là business logic
Chapter 06 / Don't let knowledge die with the flag

Three layers, one memory.

Khi cleanup flag, code biến mất nhưng tri thức phải ở lại — gọn lại, không mất.

01
/docs/features/
Đang phát triển — working docs
FormatChi tiết, đầy đủ
AudienceTeam đang làm sprint
LifetimeĐến khi cleanup flag
02
/docs/knowledge-base/
Tham khảo nhanh sau cleanup
FormatNgắn gọn, súc tích
AudienceDev/PO mới · AI cần context
LifetimeVô hạn — tài sản chiến lược
03
/docs/archive/
Audit, deep dive khi cần
FormatNguyên bản gốc (read-only)
AudienceHiếm khi đụng đến
LifetimeVô hạn

Knowledge Base — cấu trúc

  • — overview.md   feature làm gì, tại sao có (1-2 trang)
  • — architecture.md   kiến trúc, component, data flow (2-3 trang)
  • — business-rules.md   quy tắc business, compliance (2 trang)
  • — history.md   lịch sử thay đổi, link archive (1 trang)

Tại sao quan trọng với Consentik

  • — Audit trail khi có vấn đề pháp lý
  • — Onboarding Dev/PO mới hiểu nhanh sản phẩm
  • — AI context feed knowledge base để AI hiểu nền
  • — Cross-platform tham chiếu giữa Shopify ↔ Wix
Chapter 07 / Non-negotiable

Bốn nhóm nguyên tắc.

Những quy tắc bất di bất dịch — áp dụng cho mọi feature, không có ngoại lệ.

01 Feature Flag
  • Mỗi feature có 1 unique feature flag (ID)
  • Release flag có expiry: 4-8 tuần sau rollout 100%
  • Cuối tháng PO + Dev review danh sách flag active
  • Cleanup flag là task chính thức trong sprint, có owner
02 Documentation
  • Tài liệu active đặt trong /docs/features/{flag}/
  • Khi cleanup, BẮT BUỘC consolidate sang knowledge-base
  • Folder gốc move sang /docs/archive/ (read-only)
  • Code reference tới knowledge base, không tới flag đã xóa
03 AI Governance
  • Không commit code AI generate mà chưa đọc hiểu
  • Lưu prompt/context quan trọng vào ai-context.md
  • Không share sensitive data (API key, customer PII) với AI
  • Version control cho prompt khi build skill
04 Quality & Compliance
  • Compliance check bắt buộc cho feature liên quan GDPR/CCPA/LGPD
  • Cross-platform consistency check (Shopify vs Wix)
  • i18n review — đảm bảo support đầy đủ ngôn ngữ và RTL
  • Deploy production: unit test ✓ SonarQube ✓ test case ✓ monitoring ✓
How the three roles connect

Mối quan hệ ràng buộc.

Ba role, một feature flag, một workspace chung. Mỗi mũi tên là một trách nhiệm — không ai làm việc trong vacuum.

SHARED CONTEXT Feature Flag & Docs Plan · Spec · Metrics Implement Plan · Estimate AC · Test Scope Confirm DoR · Concerns Code · API Docs Test Cases · Bug Reports ROLE 01 PO/PM ROLE 02 Dev ROLE 03 Tester

Loại quan hệ

  • Solid — bắt buộc, blocking. Phải có trước khi bước tiếp theo bắt đầu.
  • Dashed — async feedback. Không block, có thể comment sau.

Điểm chung của 3 role

  • Feature Flag — unique ID nối tất cả
  • /docs/features/{flag}/ — workspace chung
  • Sprint Goal — mục tiêu chung

Nguyên tắc cốt lõi

  • "Mỗi role giữ trách nhiệm cuối cùng cho output của mình — AI chỉ là trợ thủ."
End of document

AI là trợ thủ.
Con người vẫn giữ vô lăng.

Consentik · Sprint Workflow Manual · Hanoi 2026
01 / 12