Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là Product Owner của một team làm app giao đồ ăn. Cuối Sprint, lập trình viên hồ hởi báo: "Tính năng đặt món xong rồi anh!". Bạn mở app lên dùng thử thì phát hiện: chưa có ai test trên điện thoại Android cũ, code chưa được review, chưa có log lỗi, và khi mất mạng thì app trắng màn hình. Vậy "xong" ở đây nghĩa là gì? Xong với lập trình viên là "code chạy được trên máy em", còn xong với bạn là "khách hàng đặt món thành công và không bị lỗi".
Khoảng cách giữa hai chữ "xong" đó chính là nơi mọi rắc rối trong dự án Agile sinh ra. Và để xoá bỏ khoảng cách này, Scrum có hai công cụ tưởng giống nhau nhưng bản chất hoàn toàn khác: Definition of Done (DoD) và Acceptance Criteria (AC). Rất nhiều Scrum Master, Product Owner, thậm chí cả những người đã làm Agile vài năm, vẫn nhầm lẫn hai khái niệm này. Họ viết Acceptance Criteria nhưng gọi là Definition of Done, hoặc bỏ hẳn DoD vì nghĩ "có AC là đủ rồi".
Bài học này sẽ giúp bạn phân biệt rạch ròi hai khái niệm, hiểu khi nào dùng cái nào, và quan trọng nhất là biết cách xây dựng chúng cho team của mình. Đây là một trong những kiến thức nền tảng quyết định chất lượng sản phẩm và uy tín của cả team.
Khái niệm cốt lõi
Definition of Done (DoD) là gì
Definition of Done là một danh sách tiêu chuẩn chất lượng chung mà toàn bộ Scrum Team cùng cam kết tuân thủ. Nó trả lời câu hỏi: "Để một phần việc được coi là thực sự hoàn thành và sẵn sàng đưa ra thị trường (releasable), nó phải đạt những điều kiện gì?".
Ba đặc điểm cốt lõi của DoD bạn cần khắc cốt ghi tâm:
- Là checklist dùng chung của cả Scrum Team. DoD không phải của riêng lập trình viên, không phải của riêng tester. Nó là cam kết tập thể về chất lượng.
- Áp dụng cho MỌI Increment, MỌI Product Backlog Item (PBI). Dù bạn làm tính năng đăng nhập hay tính năng thanh toán, dù story to hay nhỏ, tất cả đều phải đi qua cùng một bộ DoD.
- Nhất quán xuyên suốt mọi story. Đây là điểm phân biệt quan trọng nhất. DoD không thay đổi từ story này sang story khác.
Một ví dụ DoD điển hình của một team phát triển phần mềm:
- Code đã được review bởi ít nhất một thành viên khác.
- Unit test bao phủ tối thiểu 80% và toàn bộ test pass.
- Code đã merge vào nhánh chính (main/develop) không xung đột.
- Đã test trên cả ba trình duyệt chính: Chrome, Safari, Firefox.
- Tài liệu kỹ thuật và changelog đã cập nhật.
- Không có lỗi nghiêm trọng (critical/blocker) còn tồn đọng.
- Đã deploy thành công lên môi trường staging.
Acceptance Criteria (AC) là gì
Acceptance Criteria là các điều kiện cụ thể, riêng cho từng User Story, mô tả khi nào thì story đó được coi là đáp ứng đúng nhu cầu của người dùng. Nó trả lời câu hỏi: "Tính năng này phải làm được những gì để Product Owner chấp nhận?".
Đặc điểm của AC:
- Riêng biệt cho từng story. Story đăng nhập có AC của đăng nhập, story thanh toán có AC của thanh toán. Mỗi story một bộ AC khác nhau.
- Mô tả hành vi và kết quả mong đợi từ góc nhìn người dùng/nghiệp vụ.
- Do Product Owner định nghĩa (thường cùng team thảo luận khi Refinement).
- Thường viết theo dạng kịch bản, ví dụ format Given–When–Then (Cho trước – Khi – Thì).
- Given người dùng nhập đúng số điện thoại và mật khẩu, When bấm Đăng nhập, Then chuyển vào trang chủ.
- Given người dùng nhập sai mật khẩu 5 lần, When bấm Đăng nhập, Then khoá tài khoản 15 phút và hiện thông báo.
- Given số điện thoại chưa đăng ký, When bấm Đăng nhập, Then hiện gợi ý "Tạo tài khoản mới".
Sự khác biệt then chốt
Cách dễ nhớ nhất: AC nói về "cái gì" (what), DoD nói về "chất lượng/cách thức" (how well).
| Tiêu chí | Acceptance Criteria | Definition of Done |
|---|---|---|
| Phạm vi | Riêng từng story | Toàn bộ mọi story |
| Trả lời câu hỏi | Story này làm đúng chưa? | Công việc đạt chuẩn chất lượng chưa? |
| Ai sở hữu | Product Owner | Cả Scrum Team |
| Thay đổi theo story | Có | Không (nhất quán) |
| Bản chất | Yêu cầu nghiệp vụ | Cam kết kỹ thuật/chất lượng |
Story hoàn thành = Đạt Acceptance Criteria + Đạt Definition of Done.
Tình huống thực tế
Ví dụ 1: Sàn thương mại điện tử Việt và bài học "Done nửa vời"
Một công ty thương mại điện tử tại TP.HCM (gọi là ShopViet) có team 7 người làm tính năng "Ví điện tử tích điểm". Story được PO viết AC rất rõ: người dùng tích 1 điểm cho mỗi 10.000đ chi tiêu, điểm hiển thị ở trang cá nhân, có thể đổi điểm lấy mã giảm giá.
Cuối Sprint, lập trình viên demo: nhập đơn hàng 100.000đ, ví hiện 10 điểm, đổi được mã giảm giá. PO gật đầu, tính năng pass AC. Velocity được cộng. Ai cũng vui.
Hai tuần sau, khách hàng bùng nổ phàn nàn: khi nhiều người mua cùng lúc trong giờ flash sale, điểm bị tính sai, có người mất điểm, có người được nhân đôi. Hệ thống không chịu được tải. Hoá ra team chỉ test với một người dùng, chưa hề có test tải (load test), chưa có xử lý đồng thời (concurrency), và chưa ai review phần logic giao dịch.
Bài học: Story này đã đạt AC (đúng yêu cầu nghiệp vụ) nhưng KHÔNG đạt DoD (thiếu load test, thiếu code review, thiếu xử lý concurrency). ShopViet nhầm "pass AC" là "Done". Sau sự cố, họ bổ sung vào DoD: "Mọi tính năng liên quan tiền/điểm phải có concurrency test và performance test ở mức 500 request đồng thời". Từ đó, AC vẫn riêng từng story, nhưng DoD trở thành lưới an toàn chung bắt được những lỗ hổng mà AC không bao giờ nhắc tới.
Ví dụ 2: Fintech Singapore và DoD theo tầng (layered DoD)
Một công ty fintech ở Singapore làm app chuyển tiền xuyên biên giới. Họ phát hiện một DoD duy nhất không đủ. Có những thứ "Done" ở mức story, nhưng có những thứ chỉ kiểm chứng được ở mức release (ví dụ kiểm tra tuân thủ quy định chống rửa tiền của ngân hàng nhà nước).
Họ xây DoD ba tầng:
- DoD cho từng PBI: code review xong, unit test pass, đã test trên thiết bị thật.
- DoD cho Sprint Increment: integration test pass, không lỗi blocker, deploy staging thành công.
- DoD cho Release: kiểm tra compliance AML/KYC, đã qua kiểm thử bảo mật (penetration test), có tài liệu cho bộ phận vận hành.
Ví dụ 3: Team mới chuyển sang Agile và cái bẫy "AC làm luôn nhiệm vụ của DoD"
Một startup giáo dục ở Hà Nội mới áp dụng Scrum. PO của họ rất chăm chỉ, viết AC dài đến mức trong mỗi story đều có dòng: "code phải được review", "phải có unit test", "phải test trên mobile". Nghe thì tốt, nhưng vấn đề xuất hiện: mỗi PO viết một kiểu, story này yêu cầu review, story kia quên; tester không biết chuẩn chung là gì; và khi PO bận, các yêu cầu chất lượng bị bỏ sót.
Scrum Master nhận ra họ đang nhét DoD vào AC. Anh tổ chức một buổi workshop, tách toàn bộ các điều kiện chất lượng lặp đi lặp lại ra thành một DoD chung dán lên tường, để AC chỉ còn tập trung vào nghiệp vụ riêng của từng story.
Bài học: Khi bạn thấy cùng một điều kiện xuất hiện ở AC của nhiều story, đó là dấu hiệu rõ ràng nó thuộc về DoD, không phải AC. Việc tách bạch giúp AC gọn gàng, tập trung vào giá trị người dùng, còn chất lượng kỹ thuật được đảm bảo nhất quán bởi DoD.
Hướng dẫn từng bước
Dưới đây là quy trình xây dựng và sử dụng DoD cùng AC cho team của bạn.
Bước 1 — Tổ chức workshop xây DoD cùng cả team. DoD phải do cả Scrum Team cùng tạo ra, không phải do một mình Scrum Master áp đặt. Tập hợp lập trình viên, tester, PO. Đặt câu hỏi: "Để một tính năng thực sự sẵn sàng đến tay người dùng mà chúng ta tự tin, nó cần đạt gì?". Ghi mọi ý kiến lên bảng.
Bước 2 — Gom nhóm và chọn lọc DoD. Phân loại các điều kiện theo nhóm: code (review, coding standard), testing (unit, integration, manual), tài liệu, và triển khai (deploy, monitoring). Loại bỏ những điều quá lý tưởng mà team chưa đủ năng lực thực hiện ngay, để DoD khả thi. Một DoD không ai làm nổi còn tệ hơn không có DoD.
Bước 3 — Công khai DoD. Dán DoD ở nơi cả team nhìn thấy: lên tường, lên bảng Jira, lên trang đầu wiki. DoD phải hiển hiện, không được giấu trong tài liệu nào đó không ai mở.
Bước 4 — Viết AC cho từng story khi Refinement. Với mỗi story, PO cùng team viết AC theo định dạng Given–When–Then. Đảm bảo AC: cụ thể, kiểm chứng được (testable), và chỉ nói về nghiệp vụ/hành vi, không lặp lại nội dung DoD.
Bước 5 — Kiểm tra cả hai khi review story. Khi một story được coi là hoàn thành, đối chiếu hai lần: (a) đã đáp ứng toàn bộ AC chưa? (b) đã đi qua toàn bộ DoD chưa? Chỉ khi cả hai đều xanh, story mới được kéo sang cột Done.
Bước 6 — Cải tiến DoD định kỳ trong Retrospective. DoD không phải bất biến. Khi năng lực team tăng (ví dụ đã có pipeline CI/CD), hãy nâng chuẩn DoD lên. Khi gặp sự cố như ShopViet, hãy bổ sung điều kiện mới để lưới an toàn ngày càng dày.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm AC với DoD. Đây là lỗi phổ biến nhất. Mẹo phân biệt: nếu một điều kiện đúng với mọi story thì nó là DoD; nếu chỉ đúng với một story cụ thể thì nó là AC.
Lỗi 2 — DoD quá yếu hoặc quá tham vọng. DoD chỉ ghi "code chạy được" thì vô dụng; ngược lại DoD yêu cầu 100% test coverage khi team chưa có thói quen test thì sẽ bị phớt lờ. Mẹo: bắt đầu với một DoD vừa sức rồi nâng dần qua các Retrospective.
Lỗi 3 — Có DoD nhưng không ai tuân thủ. DoD trở thành tờ giấy chết trên tường. Mẹo: biến DoD thành checklist bắt buộc ngay trong công cụ quản lý (Jira, Trello), không tick đủ thì không cho chuyển trạng thái.
Lỗi 4 — AC viết mơ hồ, không kiểm chứng được. Ví dụ "app phải chạy nhanh" là AC tồi. Mẹo: AC tốt phải đo được — "trang chủ tải dưới 2 giây trên mạng 3G".
Lỗi 5 — Bỏ qua DoD để chạy kịp Sprint. Khi gần hết Sprint, team cám dỗ bỏ qua code review hay test để "kịp demo". Đây là cách tích luỹ nợ kỹ thuật (technical debt) nguy hiểm nhất. Mẹo: nhắc cả team rằng một story bỏ qua DoD không phải là Done — nó là một quả bom hẹn giờ.
Mẹo vàng: Hãy in DoD ra và dán cạnh màn hình mỗi người. Khi Scrum Master hỏi "story này Done chưa?", câu trả lời không phải cảm tính, mà là chỉ tay vào checklist.
Bài tập thực hành
Bài 1 — Phân loại. Cho danh sách sau, hãy đánh dấu mỗi mục là DoD hay AC:
- "Người dùng đổi được 100 điểm lấy mã giảm 20.000đ."
- "Code đã được review bởi một thành viên khác."
- "Khi nhập sai OTP 3 lần, hệ thống khoá 5 phút."
- "Unit test pass và coverage trên 75%."
- "Đã test trên Chrome, Safari, Firefox."
Bài 3 — Viết AC. Cho story: "Là khách hàng, tôi muốn huỷ vé đã đặt để được hoàn tiền". Hãy viết 3 Acceptance Criteria theo định dạng Given–When–Then. Lưu ý: chỉ viết phần nghiệp vụ, đừng nhét điều kiện kỹ thuật chung vào.
Bài 4 — Tình huống. Team báo story "thanh toán qua VNPay" đã pass hết AC nhưng chưa ai test trường hợp người dùng đóng app giữa chừng giao dịch. Hãy phân tích: story này đã Done chưa? Bạn sẽ bổ sung gì vào DoD để tránh lặp lại?
(Gợi ý đáp án Bài 1: mục 1 và 3 là AC; mục 2, 4, 5 là DoD.)
Tóm tắt
- Acceptance Criteria (AC) là điều kiện riêng cho từng story, trả lời "tính năng này có làm đúng yêu cầu nghiệp vụ không?". Do Product Owner định nghĩa, thay đổi theo từng story, thường viết dạng Given–When–Then.
- Definition of Done (DoD) là checklist chất lượng chung của cả Scrum Team, áp dụng nhất quán cho mọi PBI và mọi Increment, trả lời "công việc đã đạt chuẩn chất lượng để release chưa?".
- Cách phân biệt nhanh: AC nói về cái gì (what), DoD nói về chất lượng/cách thức (how well). Điều kiện nào đúng với mọi story thì thuộc DoD; đúng với một story thì thuộc AC.
- Một story chỉ thực sự Done khi đạt cả AC riêng VÀ toàn bộ DoD chung. Thiếu một trong hai đều chưa xong.
- DoD là cam kết chính thức trong Scrum, gắn với Increment. Bỏ qua DoD để chạy kịp Sprint chính là cách tích luỹ nợ kỹ thuật nguy hiểm nhất.
- DoD do cả team cùng xây, công khai, và cải tiến liên tục qua Retrospective. Với ngành khắt khe, có thể chia DoD theo tầng (PBI / Sprint / Release).