Mở đầu — vì sao bài này quan trọng
Nếu bạn từng nghe một Developer nói "Phần của em xong rồi" nhưng đến cuối Sprint sản phẩm vẫn không thể demo, vẫn còn bug, vẫn chưa tích hợp được — thì bạn đã chạm vào đúng vấn đề mà Definition of Done (DoD) sinh ra để giải quyết. Chữ "Done" mà mỗi người trong nhóm tự hiểu theo cách của mình chính là một trong những nguồn gốc lớn nhất của sự thất vọng, của những bản release lùi lịch, và của khoảng cách niềm tin giữa nhóm phát triển với stakeholder.
Trong kỳ thi PSPO I, DoD là một chủ đề mà Scrum.org hỏi rất "kỹ" và rất "gài". Họ muốn chắc chắn bạn hiểu DoD không phải là một checklist tùy hứng do Product Owner viết ra, mà là một cam kết (commitment) chính thức gắn liền với Increment, có vai trò định nghĩa chất lượng, và có những quy tắc rõ ràng về việc ai sở hữu nó, ai có thể thay đổi nó, và điều gì xảy ra khi một Product Backlog Item (PBI) không đạt DoD.
Với vai trò Product Owner, bạn cần hiểu DoD sâu sắc vì nó ảnh hưởng trực tiếp đến hai thứ bạn quan tâm nhất: tính minh bạch (transparency) của tiến độ và giá trị (value) thực sự được giao. Một Increment không đạt DoD thì không phải là giá trị có thể release — và đó là điều bạn phải biết để không tự huyễn hoặc bản thân lẫn stakeholder. Bài này tập trung trọn vẹn vào DoD: bản chất, đặc tính, cách xây dựng và những cái bẫy thường gặp. Các chủ đề liên quan như Increment (Bài 15) hay Definition of Ready (Bài 40) sẽ được nhắc đến vừa đủ để bạn thấy bức tranh, nhưng trọng tâm vẫn là DoD.
Khái niệm cốt lõi
DoD là một commitment, không phải là một quy trình
Scrum Guide 2020 định nghĩa ba artifact (tạo phẩm) và gắn cho mỗi artifact một commitment để tăng tính minh bạch và tập trung:
- Product Backlog có commitment là Product Goal.
- Sprint Backlog có commitment là Sprint Goal.
- Increment có commitment là Definition of Done.
Điểm tinh tế cần phân biệt: DoD mô tả trạng thái ("sản phẩm phải ở trạng thái nào để được coi là Done"), chứ không phải là một quy trình các bước phải làm. Nó nói "code đã được review, đã pass tất cả automated test, đã được deploy lên môi trường staging", chứ không phải "bước 1 viết code, bước 2 review...". Sự khác biệt này nghe nhỏ nhưng rất quan trọng trong tư duy.
Tại sao DoD lại tạo ra minh bạch (transparency)
Khi cả nhóm chia sẻ chung một DoD, mọi người hiểu chính xác "Done" nghĩa là gì. Không còn chuyện mỗi người một cách hiểu. Khi một PBI được tuyên bố là "Done", ai cũng tin chắc nó đã đạt đủ tiêu chuẩn chất lượng đã thống nhất.
Sự minh bạch này lan tỏa ra ngoài nhóm. Stakeholder nhìn vào một Increment "Done" và biết nó thực sự có thể dùng được, có thể release được. Tại Sprint Review, không ai phải tranh cãi xem "cái này tính là xong chưa". DoD biến chữ "Done" mơ hồ thành một tiêu chuẩn đo lường được, từ đó nền tảng kiểm soát thực nghiệm (empiricism) của Scrum mới hoạt động đúng.
Ai sở hữu và ai tạo ra DoD
Đây là vùng dễ sai nhất trong tư duy của nhiều người mới và trong đề thi. Theo Scrum Guide 2020:
- Nếu DoD là một phần của tiêu chuẩn của tổ chức (organizational standard), thì cả nhóm phải tuân theo nó như mức tối thiểu.
- Nếu không có tiêu chuẩn tổ chức, thì Scrum Team phải tự tạo ra một DoD phù hợp cho sản phẩm.
Một câu thi kinh điển: "Ai chịu trách nhiệm cho Definition of Done?" — nếu tổ chức không có sẵn, thì Scrum Team tạo ra nó, và Developers phải tuân thủ. Hãy tránh bẫy chọn "Product Owner" hay "Scrum Master".
Điều gì xảy ra khi PBI không đạt DoD
Quy tắc cứng từ Scrum Guide: Nếu một Product Backlog Item không đạt Definition of Done, nó không thể được release và thậm chí không được trình bày tại Sprint Review như một phần của Increment. Thay vào đó, nó quay trở lại Product Backlog để được xem xét trong tương lai.
Hãy đọc kỹ câu trên, vì nó là một mỏ vàng câu hỏi thi:
- Công việc dở dang không bị "ước lượng phần trăm hoàn thành" rồi cộng vào. Trong Scrum không có khái niệm "xong 80%".
- Nó không tự động chuyển sang Sprint sau. Nó quay về Product Backlog, và PO sẽ quyết định ưu tiên lại.
- Nó không được tính là Increment.
DoD và mối quan hệ với Acceptance Criteria
Nhiều học viên nhầm DoD với Acceptance Criteria (tiêu chí chấp nhận của một story). Hai thứ này khác nhau:
- DoD áp dụng cho mọi PBI và cho Increment nói chung. Nó là tiêu chuẩn chất lượng phổ quát: "đã test, đã review, đã không có lỗi nghiêm trọng, đã đáp ứng tiêu chuẩn bảo mật...".
- Acceptance Criteria đặc thù cho từng PBI cụ thể: "người dùng nhập sai mật khẩu 5 lần thì khóa tài khoản 15 phút".
DoD nên tiến hóa, không nên cố định mãi mãi
DoD không phải khắc lên đá. Khi nhóm trưởng thành về kỹ năng và công cụ, DoD nên mạnh dần lên — thêm các tiêu chí khắt khe hơn (ví dụ tăng độ phủ test, thêm kiểm tra hiệu năng). Sprint Retrospective (Bài 20) là nơi tự nhiên để nhóm bàn việc nâng cấp DoD. Một DoD đứng yên năm này qua năm khác thường là dấu hiệu nhóm không cải tiến.
Tình huống thực tế
Tình huống 1 — Tiki và cái bẫy "Done của em"
Một nhóm phát triển tính năng giỏ hàng tại một sàn thương mại điện tử lớn (tạm gọi theo mô hình của Tiki) gồm 6 Developer. Trước khi có DoD rõ ràng, mỗi cuối Sprint xảy ra cảnh quen thuộc: lập trình viên A nói "API giỏ hàng xong rồi", nhưng hóa ra chưa viết test, lập trình viên B nói "giao diện xong rồi" nhưng chưa chạy được trên Safari của iPhone.
Tại Sprint Review, PO định demo tính năng "thêm sản phẩm vào giỏ" cho ban giám đốc thì phát hiện tính năng lỗi trên trình duyệt Safari — chiếm gần 30% lượng truy cập mobile của họ. Buổi demo phải hủy giữa chừng. Niềm tin của stakeholder vào nhóm sụt giảm.
Sau buổi Retrospective, Scrum Team ngồi lại và viết một DoD chung. Trong đó có các dòng như: "Chạy đúng trên Chrome, Safari, Firefox phiên bản gần nhất"; "Unit test coverage tối thiểu 80%"; "Đã qua code review của ít nhất một Developer khác"; "Đã deploy thành công lên môi trường staging". Ở Sprint kế tiếp, số PBI tuyên bố "Done" giảm từ 12 xuống còn 8 — nghe có vẻ tệ, nhưng 8 PBI đó thực sự release được, demo trơn tru.
Bài học: DoD ban đầu có thể làm "tốc độ trên giấy" giảm, nhưng nó làm tốc độ thật tăng vì loại bỏ công việc làm lại (rework) và bug ẩn. Với PO, một con số "Done" trung thực còn quý hơn nhiều con số "Done" ảo.
Tình huống 2 — Fintech tại Singapore và DoD cấp tổ chức
Một công ty fintech tại Singapore vận hành ví điện tử có 4 Scrum Team cùng làm trên một nền tảng. Vì là lĩnh vực tài chính, công ty ban hành một organizational Definition of Done bắt buộc: mọi tính năng phải qua kiểm tra bảo mật (security scan), phải có audit log cho mọi giao dịch, phải tuân thủ chuẩn của Cơ quan Tiền tệ Singapore (MAS) về lưu vết dữ liệu.
Đây là mức tối thiểu — không nhóm nào được phép yếu hơn. Tuy nhiên, nhóm làm về tính năng chuyển tiền quốc tế tự thấy rủi ro của họ cao hơn, nên họ bổ sung thêm vào DoD của nhóm: "Đã chạy kiểm thử với ít nhất 3 loại tiền tệ" và "Đã có kịch bản rollback giao dịch lỗi". DoD của nhóm này khắt khe hơn DoD tổ chức, và điều đó hoàn toàn hợp lệ.
Bài học: DoD tổ chức là sàn (mức tối thiểu), nhóm có thể nâng cao hơn nhưng không được hạ thấp. Là PO trong môi trường có quy định pháp lý, bạn cần hiểu DoD không chỉ là chuyện kỹ thuật mà còn là lá chắn tuân thủ — và bạn nên ủng hộ việc nó đủ nghiêm.
Tình huống 3 — Khi PO ép tuyên bố "Done" để kịp deadline
Tại một startup giao đồ ăn ở TP.HCM, áp lực ra mắt tính năng "đặt món theo nhóm" trước Tết rất lớn. Đến cuối Sprint, tính năng còn lỗi: khi nhiều người cùng thêm món vào một đơn nhóm, đôi khi món bị trùng. PO, vì sốt ruột với deadline marketing, đề nghị: "Cứ tính là Done đi, lỗi nhỏ thôi, mình sửa sau."
Scrum Master đã can thiệp đúng: PBI này chưa đạt DoD (DoD của nhóm ghi rõ "không còn lỗi mức nghiêm trọng và cao"), nên nó không được tính là Done, không vào Increment, và quay lại Product Backlog. PO có toàn quyền ưu tiên nó lên đầu Sprint sau, nhưng PO không có quyền tuyên bố một thứ chưa đạt chuẩn là "Done".
Kết quả: tính năng ra trễ một Sprint, nhưng khi ra thì ổn định. Hãy hình dung kịch bản ngược lại: nếu release tính năng lỗi đúng cao điểm Tết, hàng nghìn đơn nhóm bị sai món, tổng thiệt hại danh tiếng và hoàn tiền lớn hơn nhiều so với việc trễ một tuần.
Bài học: DoD bảo vệ tính minh bạch khỏi áp lực thời hạn — kể cả áp lực đến từ chính PO. PO kiểm soát thứ tự ưu tiên và nội dung Backlog, nhưng không kiểm soát định nghĩa chất lượng theo kiểu "nới lỏng cho qua".
Hướng dẫn từng bước
Nếu nhóm bạn chưa có DoD, hoặc DoD đang yếu, đây là quy trình thực tế để xây dựng:
- Xác định đã có DoD cấp tổ chức chưa. Nếu có, lấy nó làm nền tảng tối thiểu. Nếu chưa, Scrum Team tự xây — đây là trách nhiệm chung, không đẩy cho riêng PO hay Scrum Master.
- Tổ chức một workshop với cả Scrum Team. Developers đóng vai chính vì họ am hiểu khía cạnh kỹ thuật và sẽ là người tuân thủ. PO mang đến góc nhìn về khả năng release và giá trị cho người dùng. Scrum Master tạo điều kiện cho buổi thảo luận.
- Liệt kê các khía cạnh chất lượng cần đảm bảo. Gợi ý các nhóm tiêu chí: code (đã review, tuân thủ coding standard), kiểm thử (unit test, integration test, đã pass), tích hợp (đã merge, không phá build), phi chức năng (hiệu năng, bảo mật, khả năng truy cập), tài liệu (cập nhật tài liệu cần thiết), và khả năng triển khai (đã deploy lên môi trường nào).
- Viết các tiêu chí dưới dạng có thể kiểm chứng được. Tránh từ mơ hồ như "code sạch" hay "test đầy đủ". Thay bằng "tuân thủ ESLint không lỗi", "coverage tối thiểu 80%". Tiêu chí phải trả lời được "đạt hay không đạt", không phải "đạt bao nhiêu phần trăm".
- Giữ DoD thực tế, đừng tham lam ngay từ đầu. Một DoD quá khắt khe mà nhóm chưa đủ năng lực thực hiện sẽ khiến gần như không PBI nào "Done" — phản tác dụng. Bắt đầu ở mức nhóm thực sự đạt được, rồi nâng dần.
- Công khai DoD. Dán nó lên bảng, đưa vào wiki, để mọi người (kể cả stakeholder) đều thấy. Tính minh bạch chỉ có khi DoD hiển thị.
- Xem lại và nâng cấp DoD định kỳ. Đưa nó vào Sprint Retrospective. Mỗi khi nhóm có công cụ mới, kỹ năng mới, hãy hỏi: "DoD của ta đã có thể mạnh hơn chưa?"
Lỗi thường gặp & mẹo
Lỗi 1 — Nghĩ DoD là của riêng Product Owner. Đây là hiểu nhầm phổ biến và là bẫy thi kinh điển. DoD thuộc về Scrum Team; Developers là người tuân thủ. PO đóng góp nhưng không sở hữu riêng và không áp đặt tiêu chí kỹ thuật.
Lỗi 2 — Nhầm DoD với Acceptance Criteria. DoD là tiêu chuẩn phổ quát cho mọi PBI và Increment; Acceptance Criteria là điều kiện riêng của từng PBI. Cần đạt cả hai mới gọi là "Done".
Lỗi 3 — Cho phép "Done một phần". Trong Scrum không có "xong 80%". Một PBI hoặc đạt DoD (Done), hoặc chưa (quay về Product Backlog). PO không được tính công việc dở dang là giá trị đã giao.
Lỗi 4 — Coi DoD bất biến. DoD nên tiến hóa mạnh dần theo năng lực nhóm. Một DoD đứng yên là dấu hiệu thiếu cải tiến.
Lỗi 5 — DoD viết bằng từ mơ hồ. "Chất lượng tốt", "test kỹ" không kiểm chứng được. Mỗi tiêu chí phải trả lời được câu hỏi đạt/không đạt một cách rõ ràng.
Lỗi 6 — Đưa "demo cho stakeholder" hay "PO chấp nhận" vào DoD như tiêu chí Done. DoD là về trạng thái chất lượng của sản phẩm; việc PO chấp nhận giá trị là chuyện khác, không nên trộn lẫn (đây cũng là điểm hay gây tranh luận trong đề thi).
Mẹo ôn thi:
- Nhớ chắc cặp: Increment ↔ Definition of Done (commitment).
- Khi gặp câu hỏi "PBI không đạt DoD thì sao": đáp án đúng là quay về Product Backlog, không vào Increment, không trình bày tại Review như phần của Increment.
- Khi gặp "Ai chịu trách nhiệm DoD": nếu không có chuẩn tổ chức, Scrum Team tạo ra, Developers tuân thủ.
- Khi gặp "DoD cấp tổ chức": đó là mức tối thiểu, nhóm có thể nghiêm hơn, không được lỏng hơn.
Bài tập thực hành
- Phân loại tiêu chí. Cho danh sách sau, hãy xếp mỗi mục vào DoD hay Acceptance Criteria: (a) "Đã pass tất cả unit test"; (b) "Khi người dùng quên mật khẩu, hệ thống gửi email đặt lại trong vòng 1 phút"; (c) "Đã code review"; (d) "Số dư hiển thị đúng định dạng tiền Việt Nam có dấu phẩy ngăn cách hàng nghìn". (Gợi ý: a và c thuộc DoD; b và d thuộc Acceptance Criteria.)
- Tình huống quyết định. Cuối Sprint, một PBI đã code xong nhưng chưa qua security scan — vốn nằm trong DoD tổ chức. Stakeholder muốn release ngay. Là PO, bạn xử lý thế nào? Viết 3–4 câu nêu rõ vì sao bạn không thể tuyên bố nó "Done" và bạn sẽ dùng quyền ưu tiên Backlog ra sao.
- Soạn DoD đầu tiên. Hãy tưởng tượng bạn là PO của một nhóm làm app đặt lịch khám bệnh. Liệt kê 6 tiêu chí DoD có thể kiểm chứng được, trải đều các nhóm: code, test, tích hợp, bảo mật, hiệu năng, triển khai.
- Câu hỏi kiểu thi. "Trong Sprint Review, ai quyết định một item có đạt Definition of Done hay không?" Hãy tự trả lời rồi giải thích vì sao đó không phải là quyền đơn phương của PO.
Tóm tắt
Definition of Done là commitment chính thức của Increment — bản mô tả trạng thái chất lượng mà mọi PBI phải đạt để được coi là "Done" và trở thành một phần của Increment. Vai trò cốt lõi của DoD là tạo ra tính minh bạch: khi cả nhóm và stakeholder cùng hiểu chữ "Done" theo một nghĩa, niềm tin và khả năng kiểm soát thực nghiệm mới được bảo đảm.
Những điểm phải khắc cốt cho kỳ thi và cho thực tế: DoD thuộc về Scrum Team, Developers là người tuân thủ — không phải tài sản riêng của PO. Nếu tổ chức đã có DoD thì đó là mức tối thiểu, nhóm có thể nghiêm hơn. PBI không đạt DoD thì quay về Product Backlog, không vào Increment, không có khái niệm "Done một phần". DoD khác Acceptance Criteria: cần đạt cả hai. Và DoD nên tiến hóa mạnh dần theo năng lực nhóm, thường được bàn tại Retrospective.
Là Product Owner, bạn không viết các tiêu chí kỹ thuật của DoD, nhưng bạn là người hưởng lợi và bảo vệ nó nhiều nhất — vì chỉ một Increment đạt DoD mới là giá trị thật sự có thể release. Đừng bao giờ đánh đổi DoD để lấy một con số "Done" đẹp trên giấy.