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 ứng dụng ví điện tử ở Việt Nam. Cuối Sprint, đội phát triển hồ hởi báo cáo: "Tính năng nạp tiền qua Napas đã xong rồi anh ơi!". Bạn vui mừng đem đi demo cho khối kinh doanh, rồi tự tin nói với CEO rằng tuần sau sẽ phát hành. Nhưng đến khi triển khai thật, mọi thứ vỡ trận: chưa ai test với số tiền lớn, chưa có log để truy vết giao dịch lỗi, chưa qua kiểm thử bảo mật, và quan trọng nhất — chưa có ai viết tài liệu vận hành. "Xong" mà bạn nghe được hoàn toàn khác với "xong" mà khách hàng cần.
Đây chính là vấn đề mà Definition of Done (DoD) sinh ra để giải quyết. Trong vai trò Product Owner, bạn không trực tiếp viết code, nhưng bạn là người chịu trách nhiệm về giá trị giao đến tay khách hàng. Nếu không có một định nghĩa rõ ràng, được cả đội đồng thuận, về thế nào là "hoàn thành", thì mỗi người sẽ hiểu chữ "done" theo một cách. Hệ quả là chất lượng trồi sụt, nợ kỹ thuật (technical debt) chất đống, và lòng tin của stakeholder bị xói mòn từng Sprint một.
Bài học này sẽ giúp bạn hiểu DoD không phải là một danh sách kiểm tra (checklist) khô khan do QA tự nghĩ ra, mà là một cam kết về chất lượng — một trong những khái niệm cốt lõi nhất của Scrum mà một PO chuyên nghiệp bắt buộc phải nắm vững và bảo vệ.
Khái niệm cốt lõi
DoD là một Cam kết (Commitment), không phải checklist
Theo Scrum Guide 2020, Increment (phần sản phẩm gia tăng sau mỗi Sprint) đi kèm với một cam kết tên là Definition of Done. Đây là điểm thay đổi tư duy quan trọng: Scrum Guide gắn mỗi Artifact với một Commitment.
- Product Backlog gắn với Product Goal.
- Sprint Backlog gắn với Sprint Goal.
- Increment gắn với Definition of Done.
Định nghĩa của "Done": ranh giới trắng-đen
DoD đưa ra một định nghĩa chính thức và thống nhất về trạng thái của Increment khi nó đáp ứng các tiêu chuẩn chất lượng cần thiết của sản phẩm. Quy tắc vàng:
> Nếu một Product Backlog Item (PBI) chưa đạt Definition of Done, thì nó KHÔNG được xem là done — dù task list đã tick hết, dù lập trình viên đã commit code, dù demo trông có vẻ chạy được.
Việc này tạo ra một ranh giới trắng-đen, loại bỏ vùng xám "gần xong", "xong 90%", "chỉ còn test nữa thôi". Trong Scrum, không có khái niệm "done một phần". Một item hoặc đã done, hoặc chưa done. Những item chưa done sẽ không được tính vào Increment, không được demo như đã hoàn thành ở Sprint Review, và quay trở lại Product Backlog.
Tại sao đây là chuyện của PO?
Nhiều người lầm tưởng DoD là việc của Scrum Master hoặc Developers. Thực ra PO có lợi ích trực tiếp và sâu sắc:
- DoD bảo vệ tính minh bạch (transparency). PO ra quyết định dựa trên Increment. Nếu "done" không đáng tin, mọi quyết định về phát hành, dự báo, cam kết với stakeholder đều dựa trên nền móng giả.
- DoD ảnh hưởng trực tiếp tới forecasting. Nếu DoD lỏng lẻo, đội sẽ tích lũy "công việc ẩn" (chưa test, chưa tài liệu) và sẽ phải trả nợ vào lúc tệ nhất — thường là ngay trước ngày release.
- DoD là đòn bẩy chất lượng dài hạn. Một DoD nghiêm ngặt buộc đội duy trì chất lượng đều đặn thay vì dồn vào cuối, giúp sản phẩm luôn ở trạng thái có thể phát hành.
Ai sở hữu DoD?
Nếu tổ chức đã có một DoD chuẩn ở cấp công ty (ví dụ với sản phẩm cần tuân thủ quy định ngân hàng), đội phải tuân theo như mức tối thiểu. Nếu chưa có, Scrum Team tự xây dựng DoD phù hợp với sản phẩm. Developers là người chủ yếu định hình các tiêu chí kỹ thuật, nhưng PO phải tham gia để đảm bảo DoD phản ánh đúng kỳ vọng chất lượng của thị trường và khách hàng. Đây là việc làm chung, không phải PO áp đặt từ trên xuống.
DoD khác gì với Acceptance Criteria?
Đây là chỗ rất nhiều PO Việt Nam nhầm lẫn. Hãy phân biệt rạch ròi:
- Acceptance Criteria (Tiêu chí chấp nhận): riêng cho từng User Story, mô tả hành vi cụ thể của tính năng đó. Ví dụ với story "Nạp tiền qua Napas": "Người dùng nhập số tiền tối thiểu 10.000đ", "Hệ thống gửi OTP trước khi xác nhận".
- Definition of Done: chung cho mọi item, mô tả mức chất lượng tối thiểu mà mọi thứ phải đạt. Ví dụ: "Code đã qua review", "Unit test coverage ≥ 80%", "Đã chạy trên môi trường staging".
Một DoD mẫu cho ứng dụng web/mobile
Để bạn hình dung cụ thể, đây là một DoD thực tế cho một sản phẩm web ở quy mô vừa:
- Code đã được viết và push lên nhánh chính theo quy trình Git.
- Code đã qua peer review (ít nhất một lập trình viên khác duyệt).
- Unit test được viết và đạt độ phủ tối thiểu theo thỏa thuận (ví dụ 80%).
- Integration test cho luồng chính đã pass.
- Code tuân thủ coding convention và qua linter không lỗi.
- Đã kiểm thử thủ công trên môi trường staging.
- Không có lỗi nghiêm trọng (blocker/critical) còn tồn đọng.
- Đã rà soát bảo mật cơ bản cho dữ liệu nhạy cảm.
- Tài liệu kỹ thuật và release note liên quan đã được cập nhật.
- Tính năng được dịch đầy đủ (i18n) cho các ngôn ngữ hỗ trợ.
- Đã merge sạch, build CI/CD xanh.
Tình huống thực tế
Tình huống 1: Ví điện tử và cái giá của DoD lỏng lẻo
Một công ty fintech tại TP.HCM (gọi là PayViet) phát triển ví điện tử với đội Scrum 7 người. Trong giai đoạn đầu, để chạy nhanh cho kịp ra mắt, đội ngầm hiểu "done" là "code chạy được trên máy lập trình viên và demo OK". Họ không đưa kiểm thử bảo mật và tải vào DoD.
Sau 4 Sprint, sản phẩm có vẻ tiến rất nhanh — velocity đẹp, mỗi Sprint "xong" 30-40 điểm. Nhưng khi chuẩn bị ra mắt, đội phát hiện hàng loạt vấn đề: API nạp tiền không chịu nổi 500 giao dịch đồng thời, có lỗ hổng cho phép gọi lặp giao dịch (double-spend), và không có log để đối soát. Họ phải dừng 3 Sprint chỉ để "trả nợ" những thứ lẽ ra đã phải nằm trong định nghĩa "done".
Bài học: Velocity cao trên nền DoD lỏng lẻo là velocity ảo. PO của PayViet sau đó đã ngồi cùng đội bổ sung các tiêu chí bảo mật và kiểm thử tải vào DoD. Velocity "nhìn thấy" giảm xuống còn 20 điểm/Sprint, nhưng đó mới là con số thật, và từ đó về sau không còn những đợt dừng để trả nợ nữa. PO học được rằng bảo vệ một DoD nghiêm ngặt thực ra là bảo vệ khả năng dự báo và uy tín của chính mình.
Tình huống 2: Tiki và việc demo những thứ chưa done
Một đội tại sàn thương mại điện tử (giả định là Tiki) có thói quen ở Sprint Review demo cả những tính năng "gần xong" để stakeholder thấy đội làm việc chăm chỉ. Một tính năng "gợi ý sản phẩm cá nhân hóa" được demo trông rất mượt, khối marketing phấn khích và lập tức lên kế hoạch chạy campaign quảng bá trong 2 tuần tới.
Vấn đề là tính năng đó chưa đạt DoD: chưa qua kiểm thử hiệu năng, chưa xử lý trường hợp người dùng mới chưa có lịch sử mua hàng. Khi campaign chạy, hệ thống gợi ý sai bét và chậm, ảnh hưởng trải nghiệm hàng chục nghìn người dùng.
Bài học: PO phải kiên quyết — chỉ demo những gì đã thực sự done ở Sprint Review. Demo đồ chưa done tạo ra kỳ vọng sai và đẩy stakeholder ra quyết định trên thông tin giả. Sau sự cố, PO này đặt ra nguyên tắc: nếu một item chưa đạt DoD, nó được nhắc đến như "đang làm dở", tuyệt đối không trình bày như đã hoàn thành. Sự minh bạch tuy gây thất vọng ngắn hạn nhưng xây dựng lòng tin dài hạn.
Tình huống 3: Đội thuê ngoài và DoD như một hợp đồng chất lượng
Một startup giáo dục ở Hà Nội thuê một đội outsource ở Đà Nẵng phát triển nền tảng học trực tuyến. Hai bên liên tục tranh cãi vì "done" của bên outsource (code chạy được) khác hẳn "done" của PO bên startup (có thể phát hành cho học viên thật dùng). Mỗi lần nghiệm thu là một lần căng thẳng.
Giải pháp: PO chủ trì một buổi workshop để cả hai bên cùng viết ra một DoD chung, rõ ràng từng dòng — bao gồm cả tiêu chí về tốc độ tải trang dưới 2 giây, hỗ trợ trình duyệt phổ biến tại Việt Nam, và responsive trên điện thoại tầm trung. DoD này trở thành ngôn ngữ chung, một "hợp đồng chất lượng" mà cả hai bên đồng thuận.
Bài học: Trong bối cảnh làm việc với đội phân tán hoặc outsource — rất phổ biến ở Việt Nam — DoD là công cụ căn chỉnh kỳ vọng mạnh mẽ nhất. Nó biến những tranh cãi cảm tính thành những tiêu chí khách quan, kiểm chứng được.
Hướng dẫn từng bước
Nếu đội bạn chưa có DoD hoặc DoD hiện tại quá mơ hồ, đây là cách xây dựng một DoD vững chắc:
- Tổ chức workshop với cả Scrum Team. Đừng tự PO ngồi viết một mình. Mời Developers, Scrum Master cùng tham gia. DoD chỉ có giá trị khi cả đội đồng thuận và cảm thấy nó là của họ.
- Liệt kê mọi hoạt động cần thiết để một item có thể phát hành. Đặt câu hỏi: "Từ lúc code xong đến lúc khách hàng dùng được, cần làm những gì?". Thu thập tất cả: review, test, tài liệu, bảo mật, dịch thuật, kiểm thử trên thiết bị thật.
- Lọc ra những tiêu chí khả thi ngay bây giờ. Nếu đội chưa có khả năng tự động triển khai (auto-deploy) trong Sprint, đừng đưa vào DoD vội. DoD phải phản ánh năng lực thực tế hiện tại, không phải mơ ước.
- Viết tiêu chí rõ ràng, kiểm chứng được. Tránh chữ chung chung như "code chất lượng tốt". Hãy viết "code qua review bởi ít nhất 1 dev khác" hoặc "không có lỗi linter". Mỗi tiêu chí phải trả lời được câu hỏi đúng/sai một cách dứt khoát.
- Công khai DoD ở nơi ai cũng thấy. Dán lên bảng, ghim trong Jira, đầu trang Confluence. DoD phải minh bạch với cả stakeholder bên ngoài.
- Dùng DoD làm bộ lọc ở mọi sự kiện Scrum. Trong Sprint Planning, hỏi: "Để item này done theo DoD, cần làm gì?". Trong Sprint Review, chỉ trình bày những gì đạt DoD.
- Cải tiến DoD dần qua Retrospective. Khi năng lực đội tăng lên (ví dụ đã có CI/CD), hãy nâng cấp DoD chặt hơn. DoD là tài liệu sống, không phải đá tảng. Mỗi lần siết DoD là một bước trưởng thành của đội.
Lỗi thường gặp & mẹo
Lỗi 1: Nhầm DoD với Acceptance Criteria. Như đã phân tích, DoD là chung cho mọi item, Acceptance Criteria là riêng cho từng story. Mẹo: hãy nhớ DoD trả lời "chất lượng đủ chưa", còn AC trả lời "đúng tính năng chưa".
Lỗi 2: Đếm item chưa done vào velocity. Cám dỗ lớn nhất là tính cả những thứ "gần xong". Đừng. Velocity chỉ tính những item đạt DoD. Item chưa done = 0 điểm, dù làm được 90%.
Lỗi 3: DoD quá tham vọng so với năng lực đội. Đặt DoD đòi hỏi auto-deploy khi đội còn deploy tay sẽ khiến không item nào "done" được. Mẹo: bắt đầu với DoD đạt được, rồi nâng dần.
Lỗi 4: PO thương lượng bỏ qua DoD để kịp deadline. "Lần này cho qua, bỏ test đi cho kịp ra mắt nhé". Đây là cái bẫy chết người. Một khi bạn cho phép phá vỡ cam kết một lần, DoD mất hết giá trị. Nợ kỹ thuật sẽ quay lại với lãi kép.
Mẹo cho PO: Hãy xem DoD như tấm khiên bảo vệ uy tín của bạn trước stakeholder. Khi ai đó hỏi "sao chậm vậy", bạn có thể tự tin: "Chúng tôi giao thứ thực sự dùng được, không phải thứ trông giống dùng được". DoD biến áp lực thành cuộc trò chuyện về chất lượng.
Bài tập thực hành
- Phân tích DoD hiện tại. Viết ra định nghĩa "done" mà đội bạn đang ngầm hiểu. Nó có được viết ra rõ ràng không, hay mỗi người hiểu một kiểu? Liệt kê 3 điểm mơ hồ nhất.
- Soạn thảo DoD cho sản phẩm của bạn. Dựa trên hướng dẫn từng bước, viết một DoD gồm 8-12 tiêu chí cụ thể, kiểm chứng được, phù hợp với năng lực hiện tại của đội. Đánh dấu tiêu chí nào đội đã làm tốt, tiêu chí nào còn yếu.
- Phân biệt thực hành. Lấy một User Story gần đây. Viết riêng phần Acceptance Criteria của nó và phần Definition of Done áp dụng cho nó. Gạch chân điểm khác biệt để khắc sâu sự phân biệt.
- Tình huống ra quyết định. Cuối Sprint, một item đã pass mọi Acceptance Criteria nhưng chưa qua kiểm thử bảo mật (vốn nằm trong DoD). Stakeholder đang rất muốn có tính năng này. Bạn sẽ xử lý thế nào? Viết ra 3 câu bạn sẽ nói với stakeholder.
Tóm tắt
- Definition of Done là một Cam kết của Increment, không phải một checklist tùy tiện. Nó định nghĩa mức chất lượng tối thiểu để một item được xem là "done".
- Quy tắc vàng: item chưa đạt DoD thì không done, dù task đã tick hết. Không có khái niệm "done một phần".
- DoD khác Acceptance Criteria: DoD chung cho mọi item (chất lượng), AC riêng cho từng story (hành vi). Item done phải thỏa cả hai.
- DoD là việc của cả Scrum Team, nhưng PO phải tham gia vì nó bảo vệ tính minh bạch, khả năng dự báo và uy tín của PO trước stakeholder.
- DoD lỏng lẻo tạo velocity ảo và nợ kỹ thuật; DoD nghiêm ngặt giữ sản phẩm luôn ở trạng thái có thể phát hành.
- Chỉ demo những gì đã thực sự done ở Sprint Review; đừng bao giờ thương lượng bỏ qua DoD để chạy theo deadline.
- DoD là tài liệu sống — hãy nâng cấp nó dần qua Retrospective khi năng lực đội trưởng thành hơn.