Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn đặt một chiếc bánh kem cho sinh nhật con. Đến nơi nhận, bạn phát hiện bánh đã nướng xong nhưng… chưa phủ kem, chưa cắm nến, chưa viết tên. Người thợ nói: "Phần bánh đã done rồi anh ạ." Bạn ngớ người: với họ "xong" nghĩa là đã nướng, còn với bạn "xong" nghĩa là sẵn sàng mang lên bàn tiệc. Cùng một từ "xong", hai cách hiểu hoàn toàn khác nhau — và hậu quả là một bữa tiệc dở dang.
Trong Scrum, bi kịch này lặp lại mỗi ngày. Lập trình viên nói "tính năng đã xong", tester phát hiện chưa có ai kiểm thử, Product Owner hỏi sao chưa lên production được, còn khách hàng thì chờ đợi một thứ chẳng bao giờ tới đúng hẹn. Gốc rễ của mớ hỗn loạn này thường chỉ là một thứ: nhóm không có Definition of Done (DoD) — một định nghĩa chung, rõ ràng, được cả nhóm đồng thuận về việc thế nào là "hoàn thành".
Với vai trò Product Owner, DoD là tấm khiên bảo vệ chất lượng sản phẩm của bạn. Nó là ranh giới giữa "trông như xong" và "thực sự xong, dùng được, giao được". Bài này sẽ giúp bạn hiểu DoD là gì, tại sao nó quan trọng đến mức Scrum Guide xếp nó vào nhóm các cam kết (commitments) cốt lõi, và làm sao để xây dựng một DoD vừa chặt chẽ vừa thực tế cho nhóm của bạn.
Khái niệm cốt lõi
Definition of Done là gì
Theo Scrum Guide, Definition of Done là một mô tả chính thức về trạng thái của Increment khi nó đáp ứng các yêu cầu chất lượng cần thiết của sản phẩm. Nói đơn giản, DoD là một danh sách các tiêu chí mà mọi hạng mục công việc (Product Backlog Item) phải thỏa mãn trước khi được tuyên bố là "Done".
Điểm mấu chốt: DoD không phải gợi ý, không phải mong muốn — nó là chuẩn tối thiểu bắt buộc. Một hạng mục chỉ có hai trạng thái: đạt DoD (Done) hoặc chưa đạt (Not Done). Không có khái niệm "done 80%", "done nhưng còn chút việc", hay "done vào ngày mai".
DoD là một cam kết của Increment
Trong Scrum Guide phiên bản 2020, mỗi artifact gắn với một commitment để tăng tính minh bạch:
- Product Backlog gắn với Product Goal.
- Sprint Backlog gắn với Sprint Goal.
- Increment gắn với Definition of Done.
Phân biệt DoD với Acceptance Criteria
Đây là chỗ rất nhiều người nhầm, kể cả PO có kinh nghiệm.
- Definition of Done áp dụng cho toàn bộ các hạng mục. Nó nói về chất lượng kỹ thuật và quy trình: code đã review chưa, test đã chạy chưa, tài liệu đã cập nhật chưa, đã deploy lên môi trường staging chưa. DoD gần như giống nhau cho mọi user story.
- Acceptance Criteria (tiêu chí chấp nhận) áp dụng riêng cho từng hạng mục. Nó mô tả hành vi cụ thể của tính năng đó: "Khi người dùng nhập sai mật khẩu 5 lần, tài khoản bị khóa 15 phút." Mỗi story có acceptance criteria khác nhau.
Mục đích thực sự của DoD
DoD phục vụ ba mục đích lớn:
- Tạo hiểu biết chung (shared understanding). Khi ai đó nói "done", cả PO, Developer, Scrum Master và stakeholder đều hiểu chính xác như nhau. Hết cảnh "tưởng là xong".
- Đảm bảo minh bạch (transparency). DoD giúp đo lường tiến độ trung thực. Một story "đang code dở" không thể đội lốt thành "gần xong".
- Bảo vệ chất lượng và giảm nợ kỹ thuật. Bằng cách buộc mọi hạng mục đi qua cùng một bộ lọc chất lượng, DoD ngăn nhóm tích lũy nợ kỹ thuật (technical debt) — thứ giết chết tốc độ về lâu dài.
Ai sở hữu DoD
DoD do Scrum Team cùng xây dựng, nhưng phần kỹ thuật chủ yếu đến từ Developers vì họ là người hiểu rõ chất lượng kỹ thuật. PO đóng góp góc nhìn về giá trị và sự sẵn sàng giao cho người dùng. Nếu tổ chức đã có một DoD chung ở cấp công ty (organizational standard), nhóm phải tuân theo tối thiểu và có thể bổ sung tiêu chí chặt hơn — nhưng không được nới lỏng.
Tình huống thực tế
Tình huống 1: Tiki và cái bẫy "done trên máy của tôi"
Một nhóm phát triển tính năng "Ví Tiki" tại một sàn thương mại điện tử Việt Nam (bối cảnh giả định lấy cảm hứng từ các đội product ở TP.HCM) chạy Sprint 2 tuần. Cuối Sprint, Developer báo cáo: "Tính năng nạp tiền vào ví đã xong." Demo trên máy lập trình viên chạy mượt, ai cũng vui.
Ba ngày sau, khi cố đẩy lên production, mọi thứ vỡ vụn: chưa ai viết unit test, phần tích hợp cổng thanh toán chưa được kiểm thử trên môi trường staging, và log giao dịch không được mã hóa — vi phạm yêu cầu bảo mật. Cái "done" hóa ra là "done trên máy của tôi" (works on my machine).
Nhóm ngồi lại và viết DoD đầu tiên: code được review bởi ít nhất một người, unit test coverage ≥ 70%, chạy qua được trên staging, đáp ứng checklist bảo mật, và tài liệu API được cập nhật. Sprint kế tiếp, velocity giảm từ 32 xuống 24 điểm — nhưng số bug rò rỉ ra production giảm từ 11 xuống còn 2.
Bài học: Một DoD nghiêm túc ban đầu trông như làm chậm nhóm lại, nhưng thực ra nó chỉ phơi bày sự thật rằng trước đó nhóm đang báo cáo "xong" cho những thứ chưa xong. Velocity 32 cũ là con số ảo.
Tình huống 2: Startup fintech và DoD tiến hóa theo thời gian
Một startup fintech ở Singapore với 6 developer bắt đầu với DoD rất tối giản: "code chạy được + đã review". Giai đoạn đầu sản phẩm còn nhỏ, điều này tạm ổn và giúp họ ra mắt MVP nhanh.
Nhưng khi đạt 50.000 người dùng, sự cố bắt đầu xuất hiện: một bản cập nhật làm sập màn hình lịch sử giao dịch trên điện thoại Android đời cũ vì không ai test trên thiết bị thật. PO nhận ra DoD đã lỗi thời so với độ trưởng thành của sản phẩm.
Trong một buổi Retrospective, nhóm bổ sung DoD: phải test trên ít nhất 3 cấu hình thiết bị phổ biến nhất theo dữ liệu analytics, phải vượt qua kiểm tra hiệu năng (màn hình tải dưới 2 giây), và phải có cờ tính năng (feature flag) để có thể tắt nhanh khi sự cố. DoD của họ dày lên cùng với sự trưởng thành của sản phẩm.
Bài học: DoD không phải tài liệu khắc trên đá. Nó là một sinh thể sống, được nhóm soi lại và điều chỉnh — thường trong Sprint Retrospective — khi bối cảnh sản phẩm thay đổi. DoD quá lỏng khi sản phẩm đã lớn chính là một quả bom hẹn giờ.
Tình huống 3: PO ép tuyên bố "done" để kịp demo
Một PO tại công ty gia công phần mềm ở Đà Nẵng chịu áp lực lớn từ khách hàng Nhật Bản, đòi thấy tính năng "báo cáo doanh thu" trong buổi Sprint Review. Cuối Sprint, tính năng mới hoàn thành phần giao diện, phần tính toán số liệu còn lỗi và chưa qua kiểm thử. PO gợi ý nhóm: "Cứ đánh dấu done đi, mai mình sửa nốt, để khách thấy có tiến độ."
Scrum Master phản đối: làm vậy là phá vỡ DoD và làm hỏng tính minh bạch. Cuối cùng nhóm thống nhất giải pháp đúng đắn: trong Sprint Review, họ demo phần giao diện đã đạt DoD như một Increment thật, và trung thực trình bày phần tính toán còn dở dang như công việc chưa hoàn thành sẽ quay lại backlog. Khách hàng Nhật — vốn coi trọng sự trung thực — đánh giá cao cách làm này hơn là một con số đẹp giả tạo.
Bài học: Cám dỗ lớn nhất của một PO là nới lỏng DoD để "có cái mà khoe". Nhưng mỗi lần bạn cho phép một story chưa đạt DoD đội lốt "done", bạn đang vay một khoản nợ với lãi suất cắt cổ — và stakeholder sẽ mất niềm tin vào mọi báo cáo của bạn về sau.
Hướng dẫn từng bước
Dưới đây là quy trình thực tế để xây dựng và vận hành DoD cho nhóm của bạn.
Bước 1 — Tổ chức một workshop xây dựng DoD. Mời toàn bộ Scrum Team. Đặt câu hỏi: "Để một hạng mục thực sự sẵn sàng giao cho người dùng, nó phải trải qua những gì?" Ghi mọi ý kiến lên bảng, không phán xét.
Bước 2 — Nhóm các tiêu chí theo hạng mục. Thường có vài nhóm: chất lượng code (review, coding standard), kiểm thử (unit test, integration test, manual test), tích hợp & triển khai (merge, deploy staging), tài liệu (cập nhật API doc, hướng dẫn), phi chức năng (bảo mật, hiệu năng, khả năng truy cập).
Bước 3 — Lọc ra danh sách tối thiểu khả thi. Đừng tham. Một DoD 30 mục mà không ai làm nổi còn tệ hơn 8 mục được tuân thủ nghiêm. Hãy chọn những tiêu chí mà nhóm có thể thực sự đạt được ngay trong Sprint. Nếu một tiêu chí (ví dụ "kiểm thử tự động đầy đủ") chưa khả thi, hãy ghi nó vào lộ trình cải tiến thay vì nhồi vào DoD ngay.
Bước 4 — Viết DoD ở nơi ai cũng thấy. Dán lên bảng Jira, ghim trong kênh Slack/Telegram, in dán cạnh bàn làm việc. DoD vô hình là DoD vô dụng.
Bước 5 — Áp dụng DoD trong từng sự kiện Scrum. Trong Sprint Planning, kiểm tra mỗi story xem nhóm có đủ sức đưa nó đạt DoD trong Sprint không. Trong Daily Scrum, dùng DoD để hỏi "thực sự còn gì để story này đạt Done?". Trong Sprint Review, chỉ demo những gì đạt DoD.
Bước 6 — Soi lại DoD định kỳ trong Retrospective. Mỗi vài Sprint, hỏi: DoD còn phù hợp không? Có tiêu chí nào đang bị lách không? Có cần siết chặt thêm khi sản phẩm lớn lên không?
Lỗi thường gặp & mẹo
Lỗi 1: Không có DoD nào cả. Nhóm chạy theo cảm tính. Mỗi người hiểu "done" một kiểu. Đây là lỗi nền tảng — hãy sửa trước tiên.
Lỗi 2: DoD quá tham vọng, không thực tế. Một DoD đòi hỏi "100% test coverage và zero bug" nghe rất oai nhưng không nhóm nào đạt được, dẫn đến việc cả nhóm ngầm phớt lờ nó. DoD bị phớt lờ còn nguy hiểm hơn không có, vì nó tạo ảo giác về sự kiểm soát.
Lỗi 3: Nhầm DoD với Acceptance Criteria. Như đã phân tích, DoD là chuẩn chung, AC là yêu cầu riêng từng story. Trộn lẫn hai thứ khiến DoD phình to vô lý.
Lỗi 4: PO nới lỏng DoD vì áp lực deadline. Đây là cám dỗ nguy hiểm nhất với PO. Hãy nhớ: DoD không phải để thương lượng. Nếu cần ra mắt sớm, hãy giảm phạm vi (làm ít tính năng hơn nhưng mỗi tính năng đạt Done), chứ đừng giảm chất lượng (làm nhiều tính năng nhưng đều dở dang).
Lỗi 5: DoD bất biến. Sản phẩm trưởng thành mà DoD đứng yên là tự rước rủi ro. Hãy coi DoD như phần mềm — cần cập nhật theo thời gian.
Mẹo từ mentor:
- Khi một story không đạt DoD cuối Sprint, đừng "tính nửa điểm". Đưa nguyên nó về backlog và ước lượng lại. Velocity phải phản ánh công việc đạt Done.
- Với mỗi tiêu chí DoD, hãy đảm bảo nó kiểm chứng được (verifiable). "Code sạch" thì mơ hồ; "vượt qua linter với 0 lỗi" thì kiểm chứng được.
- Treo một câu hỏi vàng trong nhóm: "Nếu khách hàng dùng cái này ngay bây giờ, mình có dám không?" Nếu câu trả lời là không, story chưa Done.
Bài tập thực hành
- Soạn DoD cho nhóm giả định. Bạn là PO của một nhóm 5 người làm ứng dụng đặt món ăn trên di động. Hãy viết một DoD gồm 8–10 tiêu chí, chia theo các nhóm: chất lượng code, kiểm thử, triển khai, tài liệu, phi chức năng. Đảm bảo mỗi tiêu chí đều kiểm chứng được.
- Phân loại tiêu chí. Cho danh sách sau, hãy đánh dấu đâu là DoD, đâu là Acceptance Criteria:
- Xử lý tình huống. Cuối Sprint, một story quan trọng đã code xong và chạy đúng, nhưng chưa ai viết test tự động (DoD yêu cầu coverage ≥ 70%). Khách hàng đang chờ demo gấp. Bạn là PO, hãy viết ra cách bạn xử lý và lý do — bám sát nguyên tắc minh bạch và không thương lượng DoD.
- Tự kiểm DoD hiện tại. Nếu bạn đang đi làm, hãy lấy DoD của nhóm bạn (nếu có) và soi: có tiêu chí nào không kiểm chứng được không? Có tiêu chí nào đang bị nhóm âm thầm lách không? Đề xuất một thay đổi để mang ra Retrospective tới.
Tóm tắt
Definition of Done là một mô tả chính thức, được cả Scrum Team đồng thuận, về việc thế nào là một Increment đạt chuẩn chất lượng để gọi là "hoàn thành". Đây là một trong ba cam kết cốt lõi của Scrum, gắn liền với artifact Increment.
Những điểm cần khắc cốt ghi tâm:
- DoD tạo hiểu biết chung — khi ai đó nói "done", cả nhóm hiểu giống nhau.
- DoD đảm bảo minh bạch và bảo vệ chất lượng, ngăn nợ kỹ thuật tích tụ.
- DoD khác Acceptance Criteria: DoD là chuẩn chung cho mọi hạng mục, AC là yêu cầu riêng từng story.
- DoD là tối thiểu bắt buộc, không thương lượng — nhưng tiến hóa theo độ trưởng thành của sản phẩm.
- Với vai trò PO, đừng bao giờ nới DoD để có cái khoe; hãy giảm phạm vi thay vì giảm chất lượng.