Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn đặt món phở online. Nhà hàng nhắn "đơn của bạn đã xong" — nhưng khi shipper giao tới, hộp phở thiếu rau, thiếu chanh, và nước dùng đã nguội. Vậy "xong" theo nghĩa nào? Với nhà bếp, "xong" là đã chan nước vào tô. Với bạn, "xong" là một tô phở nóng hổi, đủ topping, ăn được ngay. Khoảng cách giữa hai định nghĩa "xong" đó chính là nơi sự thất vọng — và cả những cuộc cãi vã — sinh ra.
Trong một Scrum Team, vấn đề y hệt diễn ra mỗi sprint. Lập trình viên nói "code xong rồi". Tester hỏi "đã test chưa?". Product Owner hỏi "deploy lên production chưa?". Khách hàng hỏi "tài liệu hướng dẫn đâu?". Nếu cả nhóm không thống nhất trước một định nghĩa chung về thế nào là "xong", thì mỗi người sẽ tự hiểu một kiểu, và mỗi sprint review sẽ biến thành một màn tranh luận mệt mỏi.
Definition of Done (DoD) — tạm dịch "Định nghĩa Hoàn thành" — chính là công cụ giải quyết tận gốc vấn đề này. Đây là một trong những công cụ nền tảng nhất trong toolbox của Scrum Master, và là bài học bạn sẽ áp dụng được ngay từ sprint tiếp theo. Trong bài này, chúng ta sẽ học cách tạo ra (craft) một DoD đúng nghĩa thông qua một workshop có cấu trúc — không phải sao chép từ template trên mạng, mà tự nhóm xây dựng để nó thực sự thuộc về nhóm.
Khái niệm cốt lõi
DoD là "hợp đồng chất lượng" của nhóm
Definition of Done là tập hợp các tiêu chí mà mọi Product Backlog Item phải thỏa mãn trước khi được coi là một phần của Increment có thể chuyển giao. Nói cách khác, nó là tiêu chuẩn chất lượng tối thiểu, áp dụng cho tất cả mọi việc nhóm làm — không phải cho riêng một story nào.
Đây là điểm cần phân biệt cực kỳ rõ:
- Acceptance Criteria (tiêu chí chấp nhận) gắn riêng với từng story, mô tả "story cụ thể này cần làm được những gì". Ví dụ: "người dùng nhập sai mật khẩu 5 lần thì bị khóa 15 phút".
- Definition of Done áp dụng cho mọi story, mô tả "bất kỳ việc nào của nhóm cũng phải đạt tiêu chuẩn này". Ví dụ: "code đã được review", "đã viết unit test với độ phủ tối thiểu", "đã deploy lên môi trường staging".
Scrum Guide bắt buộc có DoD
Đây không phải tùy chọn. Theo Scrum Guide (phiên bản 2020), Definition of Done là một trong ba commitment (cam kết) gắn với ba artifact của Scrum: Product Goal gắn với Product Backlog, Sprint Goal gắn với Sprint Backlog, và Definition of Done gắn với Increment.
DoD chính là thứ làm cho khái niệm "Increment" trở nên có ý nghĩa. Một Increment chỉ được tạo ra khi một Product Backlog Item đạt được Definition of Done. Nếu một item không đạt DoD, nó không được phép release, không được tính là hoàn thành trong sprint, và quay lại Product Backlog. Không có DoD, từ "Increment" chỉ là một từ rỗng.
Vì sao DoD lại quyền lực đến vậy
DoD làm được ba việc mà ít công cụ nào làm được cùng lúc:
- Tạo sự minh bạch (transparency). Khi đứng nhìn vào board, ai cũng hiểu chính xác "cột Done" nghĩa là gì. Không còn chuyện "tưởng xong rồi".
- Quản lý technical debt một cách chủ động. Mỗi tiêu chí trong DoD là một lời hứa rằng nhóm sẽ không "ăn bớt" chất lượng để chạy theo tiến độ. Nếu nhóm thường xuyên bỏ bước test để kịp deadline, DoD lỏng lẻo chính là nơi nợ kỹ thuật tích tụ âm thầm.
- Là cơ sở để lập kế hoạch. Khi nhóm estimate một story, họ phải tính cả công sức để đạt DoD (viết test, review, viết tài liệu...). Nếu DoD mơ hồ, estimate sẽ luôn lạc quan quá mức.
DoD là một artifact "sống"
Một hiểu lầm phổ biến: tạo DoD một lần rồi để đó mãi mãi. Sai. DoD phải tiến hóa cùng với năng lực và sự trưởng thành của nhóm. Một nhóm mới có thể bắt đầu với DoD khiêm tốn (chưa thể tự động deploy được), nhưng sau vài tháng khi đã xây được CI/CD, họ nên nâng cấp DoD để phản ánh tiêu chuẩn cao hơn. Retrospective là nơi lý tưởng để rà soát và điều chỉnh DoD.
Tình huống thực tế
Ví dụ 1 — Tiki và cái bẫy "Done nhưng chưa Done"
Một nhóm phát triển tính năng giỏ hàng tại một công ty thương mại điện tử lớn (tạm gọi theo bối cảnh Tiki) gồm 6 thành viên. Suốt 4 sprint đầu, velocity của họ rất ấn tượng: trung bình 45 story point mỗi sprint. PO rất hài lòng. Nhưng đến sprint thứ 5, mọi thứ vỡ trận: 12 bug nghiêm trọng từ các sprint trước đồng loạt nổ ra trên production vào đúng đợt sale 9/9.
Khi điều tra, Scrum Master phát hiện gốc rễ: nhóm chưa hề có DoD chính thức. "Done" với các bạn lập trình viên đơn giản là "code chạy được trên máy mình". Không ai review chéo, unit test viết cho có, và việc test tích hợp bị đẩy hết sang cuối — mà cuối thì luôn hết giờ. 45 point mỗi sprint thực ra là một con số ảo, vì một phần lớn công việc thực sự (test, fix bug) bị giấu đi và dồn lại.
Bài học: Velocity cao mà không có DoD chặt chẽ là một cái bẫy nguy hiểm. Nhóm này sau đó tổ chức workshop và đưa vào DoD các mục như "có ít nhất 1 reviewer approve", "pass toàn bộ regression test tự động", "đã test trên môi trường staging giống production". Velocity "danh nghĩa" tụt xuống còn 28 point, nhưng đó là 28 point thật — và số bug rò rỉ ra production giảm khoảng 80% trong hai sprint kế tiếp.
Ví dụ 2 — Một fintech ở Singapore và DoD "trên trời"
Một startup fintech tại Singapore (khoảng 30 kỹ sư) đi theo hướng ngược lại. Đội ngũ rất giàu lý tưởng, và trong workshop tạo DoD, họ đưa vào những tiêu chí cực kỳ tham vọng: "độ phủ unit test 100%", "đã thực hiện kiểm thử bảo mật (penetration test) đầy đủ cho mọi story", "đã có tài liệu kiến trúc cập nhật".
Kết quả? Sau 3 sprint, không một story nào đạt được DoD. Penetration test cần đội security riêng vốn chỉ rảnh mỗi quý một lần. Yêu cầu 100% coverage khiến các bạn viết test giả tạo chỉ để chạy đủ con số. Cả Sprint Review trở thành buổi giải thích tại sao "chưa Done".
Scrum Master nhận ra DoD đã bị nhầm với danh sách ước mơ. Họ tổ chức lại workshop, tách các tiêu chí thành hai nhóm: những gì nhóm kiểm soát được và làm được mỗi sprint (đưa vào DoD), và những gì là mục tiêu dài hạn hoặc phụ thuộc bên ngoài (đưa ra một checklist riêng cho release lớn). DoD mới gọn lại: review code, coverage cho phần logic nghiệp vụ mới (không phải toàn bộ), pass automated test, và security scan tự động (thay cho pen-test thủ công).
Bài học: Một DoD tốt phải vừa tầm với hiện tại của nhóm. DoD mà không bao giờ đạt được thì vô dụng — tệ hơn cả không có, vì nó dạy nhóm thói quen coi thường chính tiêu chuẩn của mình.
Ví dụ 3 — Nhóm outsourcing ở Đà Nẵng và "DoD áp đặt"
Một công ty gia công phần mềm ở Đà Nẵng nhận dự án cho khách hàng Nhật. Manager kỹ thuật, vốn là một kỹ sư giỏi, đã tự ngồi soạn một DoD rất chi tiết gồm 18 mục rồi gửi email yêu cầu cả nhóm tuân thủ. Trên giấy tờ, DoD này rất đẹp.
Nhưng thực tế, không ai trong nhóm thực sự dùng nó. Khi được hỏi, một developer thừa nhận: "Em còn không nhớ trong đó có gì, đó là DoD của sếp mà." Vì nhóm không tham gia xây dựng, họ không cảm thấy sở hữu nó, và DoD trở thành một văn bản chết nằm trên Confluence.
Khi Scrum Master mới về, anh tổ chức một workshop 90 phút để nhóm cùng nhau viết lại DoD từ đầu. Lần này chỉ còn 9 mục — ít hơn một nửa — nhưng là 9 mục mà mọi người tự đề xuất, tranh luận và đồng ý. Điều thú vị: 7 trong 9 mục trùng với bản của manager, nhưng giờ đây nhóm thực sự làm theo, vì đó là cam kết của chính họ.
Bài học: DoD áp đặt từ trên xuống hiếm khi sống được. Quyền lực của DoD đến từ việc nó là cam kết tập thể, do nhóm tự xây dựng. Vai trò của Scrum Master là facilitate (điều phối) quá trình đó, không phải tự viết hộ.
Hướng dẫn từng bước
Dưới đây là cách tổ chức một workshop tạo DoD trong 90 phút. Mời toàn bộ Developers, Product Owner tham gia, và Scrum Master làm người điều phối.
Bước 0 — Chuẩn bị (trước buổi, 10 phút). Đặt sẵn một bảng (vật lý hoặc Miro/FigJam) với các vùng phân loại. Giải thích ngắn cho cả nhóm: hôm nay chúng ta định nghĩa "Done" nghĩa là gì, để không bao giờ phải cãi nhau về điều đó nữa.
Bước 1 — Brainstorm (15 phút). Mỗi người tự viết ra sticky note tất cả những gì họ nghĩ một story cần đạt để được coi là "xong". Làm im lặng, độc lập trước để tránh ý kiến mạnh lấn át. Khuyến khích nghĩ theo các nhóm: code (review, chuẩn coding), kiểm thử (unit, integration, regression), tích hợp (merge, build, deploy), tài liệu, và phi chức năng (hiệu năng, bảo mật, accessibility).
Bước 2 — Gom nhóm và làm rõ (20 phút). Dán hết note lên bảng, gom các ý trùng lặp, đọc to từng cái. Với mỗi tiêu chí, hỏi: "Cái này nghĩa cụ thể là gì? Làm sao biết nó đã đạt?" Một tiêu chí tốt phải kiểm chứng được — "code sạch" thì mơ hồ, nhưng "không còn warning từ linter" thì kiểm chứng được.
Bước 3 — Sàng lọc bằng câu hỏi vàng (25 phút). Với từng tiêu chí, đặt hai câu hỏi quyết định:
- Nhóm có thực sự làm được điều này trong MỖI sprint không? Nếu phụ thuộc bên ngoài hoặc chỉ làm được mỗi quý, nó không thuộc về DoD.
- Đây là tiêu chí áp dụng cho MỌI story, hay chỉ riêng một loại story? Nếu chỉ riêng vài story, đó là Acceptance Criteria, không phải DoD.
Bước 4 — Đồng thuận và phân tầng (15 phút). Chốt danh sách cuối cùng. Nếu hữu ích, phân tầng DoD theo cấp độ: DoD cho từng story/PBI, DoD cho từng sprint, và DoD cho release. Dùng một hình thức đồng thuận rõ ràng (ví dụ giơ tay theo thang Fist of Five) để đảm bảo không ai âm thầm phản đối.
Bước 5 — Công khai hóa và chốt lịch rà soát (5 phút). In DoD ra dán cạnh board, hoặc ghim trên kênh chat. Quan trọng: hẹn rõ sẽ rà soát lại DoD trong retrospective sau mỗi 2–3 sprint. DoD là tài liệu sống.
Lỗi thường gặp & mẹo
Lỗi 1 — DoD quá dài, biến thành checklist 30 mục. Một DoD đồ sộ sẽ không ai nhớ và không ai dùng. Mẹo: giữ DoD đủ ngắn để mọi thành viên thuộc lòng — khoảng 7 đến 12 mục là hợp lý cho phần lớn nhóm.
Lỗi 2 — Nhầm DoD với Acceptance Criteria. Nếu một tiêu chí chỉ đúng với một story cụ thể, nó thuộc về Acceptance Criteria. DoD chỉ chứa những gì áp dụng cho mọi item. Hãy thường xuyên kiểm tra lại ranh giới này.
Lỗi 3 — DoD bất khả thi. Như ví dụ fintech Singapore, đặt tiêu chí mà nhóm không thể đạt mỗi sprint sẽ làm DoD mất uy tín. Mẹo: nếu một mục liên tục bị bỏ qua trong 2–3 sprint, hãy đối diện trung thực — hoặc loại nó khỏi DoD, hoặc đầu tư để nhóm thực sự làm được nó.
Lỗi 4 — DoD áp đặt từ trên xuống. Như nhóm Đà Nẵng, DoD do sếp viết hộ thì nhóm không sở hữu. Mẹo: Scrum Master điều phối, nhóm tự viết.
Lỗi 5 — Tạo xong rồi quên. DoD không được rà soát sẽ dần lệch khỏi thực tế. Mẹo: đưa "rà soát DoD" thành một mục định kỳ trong retrospective.
Mẹo nâng cao — DoD và môi trường nhiều nhóm. Khi nhiều Scrum Team cùng làm một sản phẩm, cần một DoD chung tối thiểu mà tất cả các nhóm phải tuân thủ, để Increment tích hợp được. Mỗi nhóm có thể thêm tiêu chí khắt khe hơn, nhưng không được hạ dưới mức chung.
Mẹo Việt Nam — văn hóa "nể nang". Trong nhiều nhóm Việt, khi điều phối bước đồng thuận, thành viên trẻ thường ngại phản đối ý kiến người lớn tuổi hoặc cấp trên. Hãy dùng cách bỏ phiếu ẩn danh hoặc viết note im lặng ở Bước 1 để mọi tiếng nói đều được nghe, tránh DoD chỉ phản ánh quan điểm của vài người mạnh nhất.
Bài tập thực hành
- Đánh giá DoD hiện tại. Nếu nhóm bạn đã có DoD, hãy mang nó ra. Với từng mục, tự trả lời: (a) mục này có kiểm chứng được không? (b) nhóm có thực sự đạt nó mỗi sprint không? (c) nó áp dụng cho mọi story hay chỉ vài story? Đánh dấu những mục "đỏ" cần sửa.
- Phân loại 10 phát biểu. Với mỗi câu sau, xác định nó là DoD hay Acceptance Criteria: (1) "Code đã được review bởi ít nhất 1 người"; (2) "Người dùng có thể lọc sản phẩm theo giá tăng dần"; (3) "Đã pass toàn bộ automated test"; (4) "Email xác nhận được gửi trong vòng 30 giây sau khi đặt hàng"; (5) "Không còn warning từ linter". Tự lý giải lựa chọn của bạn.
- Tổ chức workshop thật. Áp dụng quy trình 90 phút ở trên cho nhóm của bạn (hoặc một nhóm giả định gồm 5 bạn cùng học). Tạo ra một DoD từ 7–12 mục, kèm một danh sách "DoD khát vọng" riêng. Ghi lại những điểm tranh luận gay gắt nhất — chúng thường tiết lộ những bất đồng ngầm về chất lượng trong nhóm.
- Thiết kế lịch tiến hóa. Viết ra: trong 3 tháng tới, bạn muốn nâng cấp tiêu chí nào của DoD, và nhóm cần đầu tư gì (công cụ, kỹ năng, quy trình) để biến một mục "khát vọng" thành một mục chính thức.
Tóm tắt
Definition of Done là hợp đồng chất lượng chung của nhóm — tập tiêu chí mà mọi Product Backlog Item phải đạt để trở thành một phần của Increment có thể chuyển giao. Scrum Guide bắt buộc phải có nó, vì nó chính là thứ làm khái niệm "Increment" trở nên có thực và tạo ra sự minh bạch về chất lượng.
Ba nguyên tắc cốt lõi cần nhớ: (1) DoD áp dụng cho mọi story, khác với Acceptance Criteria gắn riêng từng story; (2) DoD phải vừa tầm — đạt được mỗi sprint, không quá lỏng lẻo như nhóm Tiki cũng không trên trời như nhóm fintech Singapore; (3) DoD phải do nhóm tự xây dựng để họ thật sự sở hữu, không phải áp đặt từ trên xuống như nhóm Đà Nẵng.
Cách tạo DoD tốt nhất là một workshop có cấu trúc: brainstorm độc lập, gom nhóm và làm rõ, sàng lọc bằng câu hỏi "có làm được mỗi sprint không" và "áp dụng cho mọi story không", rồi đồng thuận và công khai. Và đừng quên: DoD là tài liệu sống — hãy rà soát và nâng cấp nó qua từng retrospective, để nó luôn phản ánh tiêu chuẩn cao nhất mà nhóm bạn có thể vươn tới.