Mở đầu — vì sao bài này quan trọng
Trong các bài trước, bạn đã học Definition of Done (DoD) ở mức khái niệm: nó là commitment gắn với Increment, là tiêu chuẩn chất lượng chung mà cả Scrum Team cam kết, và nó quyết định khi nào một Product Backlog Item (PBI) thực sự "Done". Nhưng khi tôi đi tư vấn cho các đội ở Việt Nam, có một câu hỏi lặp đi lặp lại: "Em hiểu lý thuyết rồi, nhưng một DoD thật trông như thế nào? Viết bao nhiêu dòng là đủ? Cái gì nên cho vào, cái gì không?"
Bài 45 này sinh ra để trả lời đúng câu hỏi đó. Chúng ta sẽ không lặp lại định nghĩa lý thuyết (bài 14 đã làm). Thay vào đó, tôi sẽ đưa cho bạn những DoD mẫu cụ thể cho nhiều loại sản phẩm khác nhau — web app, mobile, sản phẩm có yêu cầu tuân thủ — kèm con số, kèm bối cảnh thật, và quan trọng nhất là chỉ cho bạn cách đọc một DoD để biết nó tốt hay dở.
Vì sao điều này quan trọng với kỳ thi PSPO I và với công việc thật của một Product Owner? Vì DoD là nơi PO dễ hiểu sai vai trò nhất. Nhiều PO nghĩ "DoD là việc của Developers, em chỉ quan tâm acceptance criteria." Sai. PO không viết một mình DoD, nhưng PO chịu trách nhiệm về giá trị của Increment — và một DoD yếu kém tạo ra Increment trông xong nhưng không dùng được, kéo tụt giá trị mà PO cam kết với stakeholder. Hiểu một DoD thực tế trông ra sao giúp bạn vừa trả lời đúng câu hỏi thi, vừa làm tốt việc thật.
Khái niệm cốt lõi
DoD là một danh sách điều kiện, không phải một câu khẩu hiệu
Một DoD tốt là tập hợp các điều kiện kiểm chứng được (verifiable). Mỗi dòng phải trả lời được bằng "có" hoặc "không" mà không cần tranh cãi. "Code chất lượng tốt" không phải là một điều kiện DoD — vì "tốt" là chủ quan. "Code đã được ít nhất một Developer khác review và approve trên pull request" mới là điều kiện DoD — vì nó kiểm chứng được.
Đây là ranh giới sống còn. Khi đứng trước một dòng trong DoD, hãy tự hỏi: "Hai người trong đội có thể bất đồng về việc dòng này đã đạt hay chưa không?" Nếu có thể bất đồng, dòng đó chưa đủ rõ.
DoD khác Acceptance Criteria — đừng trộn lẫn
Đây là phần PSPO I rất hay kiểm tra, nên tôi nhấn mạnh:
- Acceptance Criteria (AC) thuộc về một PBI cụ thể. Nó mô tả hành vi riêng của tính năng đó. Ví dụ: "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."
- Definition of Done áp dụng cho mọi PBI và mọi Increment. Nó là tiêu chuẩn chất lượng chung. Ví dụ: "Mọi tính năng mới đều có unit test và đã chạy qua bộ test tự động."
DoD có nhiều "tầng"
Trong thực tế, một tổ chức lớn thường có DoD theo tầng:
- Tầng tổ chức (organizational DoD): chuẩn tối thiểu mọi đội phải tuân thủ (ví dụ: mọi sản phẩm phải qua quét bảo mật).
- Tầng đội (team DoD): đội bổ sung thêm điều kiện chặt hơn cho sản phẩm của mình.
DoD nên ngắn gọn nhưng đủ
Một DoD 30 dòng thường là dấu hiệu đội đang nhồi nhét acceptance criteria, quy trình nội bộ, và cả mong muốn cá nhân vào đó. Một DoD 3 dòng thì thường quá lỏng, bỏ sót testing hay bảo mật. Điểm cân bằng thực tế của hầu hết đội tôi từng làm việc là khoảng 8–15 dòng, nhóm theo cụm: code, test, tích hợp, tài liệu, phi-chức năng (bảo mật, hiệu năng), và triển khai.
Tình huống thực tế
Ví dụ 1 — Tiki: DoD cho một web app thương mại điện tử
Hãy bắt đầu từ chính dàn ý gốc của bài này và mở rộng nó thành một DoD đầy đủ cho web app. Giả sử một đội làm phần "trang chi tiết sản phẩm" của một sàn thương mại điện tử quy mô như Tiki. Đội gồm 6 Developers, Sprint 2 tuần.
DoD của họ trông như sau:
- Code đã được merge vào nhánh
mainqua pull request, có ít nhất 1 reviewer approve. - Unit test đã viết cho logic mới, độ phủ (coverage) toàn module ≥ 80%.
- Integration test cho luồng liên quan đã chạy pass trên CI.
- Không còn lỗi blocker hoặc critical mở trong công cụ quản lý lỗi.
- Trang đạt điểm Lighthouse Performance ≥ 80 trên mobile.
- Tương thích trên Chrome, Safari, và Cốc Cốc phiên bản mới nhất.
- Đã quét bảo mật bằng SAST, không có lỗ hổng mức high trở lên.
- Văn bản hiển thị đã được dịch đầy đủ tiếng Việt, không còn chuỗi cứng (hardcoded) tiếng Anh.
- Đã deploy lên môi trường staging và được PO/QA kiểm tra trên staging.
Bài học rút ra: Dàn ý gốc (merge, unit test, integration test) là bộ khung lõi về kỹ thuật. Nhưng DoD thật phải mở rộng để bao gồm cả chất lượng phi-chức năng và trải nghiệm địa phương. Con số 80% coverage là một thỏa thuận của đội, không phải con số thần thánh — có đội chọn 70%, có đội chọn 85%. Điều quan trọng là có một ngưỡng kiểm chứng được và cả đội đồng thuận.
Ví dụ 2 — MoMo: DoD cho ứng dụng ví điện tử (sản phẩm có yêu cầu tuân thủ)
Bây giờ đổi bối cảnh sang một sản phẩm tài chính, ví dụ một đội làm tính năng "chuyển tiền P2P" trong một ví điện tử cỡ MoMo. Ở đây DoD phải gánh thêm yêu cầu pháp lý và bảo mật rất nặng. DoD của họ có thêm:
- Mọi giao dịch tiền được ghi log đầy đủ phục vụ audit, không log dữ liệu nhạy cảm (PIN, số thẻ đầy đủ).
- Đã qua kiểm thử trên thiết bị Android tầm trung (RAM 3GB) và iPhone đời cũ, không crash.
- Mọi endpoint mới có rate limiting và xác thực OTP cho giao dịch trên ngưỡng.
- Đã được team Compliance review và ký xác nhận cho các thay đổi liên quan luồng tiền.
- Có cờ tính năng (feature flag) để tắt khẩn cấp mà không cần phát hành lại.
Một điểm tinh tế cho PO: dòng "có feature flag để tắt khẩn cấp" không phải yêu cầu pháp lý, mà là quyết định quản trị rủi ro mà PO rất nên ủng hộ. Nó cho phép PO bảo vệ giá trị sản phẩm: nếu tính năng chuyển tiền gặp sự cố lúc 11 giờ đêm, đội tắt được ngay thay vì phải chờ một bản phát hành mới.
Bài học rút ra: Với sản phẩm có rủi ro cao, DoD trở thành lưới an toàn về tuân thủ và vận hành, không chỉ về code. Và PO — dù không sở hữu DoD một mình — có tiếng nói quan trọng trong việc đưa các điều kiện bảo vệ giá trị vào đó. Đừng để DoD chỉ phản ánh mối quan tâm của Developers; nó cũng phải phản ánh rủi ro kinh doanh mà bạn nhìn thấy.
Ví dụ 3 — Một startup SaaS B2B: DoD tiến hóa theo thời gian
Tình huống thứ ba: một startup SaaS B2B 12 người ở TP.HCM, làm phần mềm quản lý kho cho các nhà bán lẻ. Khi mới khởi động, DoD của họ rất đơn giản, đúng kiểu dàn ý gốc:
- Code chạy được trên máy của ít nhất một người khác.
- Đã demo được tính năng.
Diễn giải: DoD không phải tảng đá khắc sẵn. Nó là một thỏa thuận sống, được thanh tra và điều chỉnh — thường tại Sprint Retrospective. Khi sản phẩm trưởng thành, độ rủi ro tăng, thì DoD cũng phải chặt lên theo. Một DoD phù hợp với startup 3 tháng tuổi sẽ là một DoD vô trách nhiệm với cùng startup đó khi đã có khách hàng doanh nghiệp.
Bài học rút ra: Đừng cố viết một DoD "hoàn hảo" ngay từ đầu. Hãy bắt đầu với một DoD trung thực với năng lực hiện tại của đội, rồi để Retrospective nâng cấp nó dần. Một DoD ghi những điều đội chưa làm được (ví dụ ghi "≥ 90% coverage" trong khi thực tế chỉ đạt 40%) còn nguy hiểm hơn không có DoD — vì nó biến mọi item thành "không Done", làm đội mất niềm tin vào chính tiêu chuẩn của mình.
Hướng dẫn từng bước
Đây là quy trình tôi dùng để giúp một đội xây dựng hoặc rà soát DoD thực tế:
- Tập hợp đúng người. DoD là của cả Scrum Team. Developers nắm phần kỹ thuật, Scrum Master điều phối, còn bạn — PO — mang vào góc nhìn rủi ro kinh doanh và giá trị. Đừng để Developers tự viết rồi báo cho bạn.
- Liệt kê theo cụm. Brainstorm điều kiện theo 6 nhóm: (a) Code & review, (b) Testing, (c) Integration/build, (d) Phi-chức năng (bảo mật, hiệu năng, khả năng tiếp cận), (e) Tài liệu, (f) Triển khai/vận hành. Cách nhóm này giúp bạn không bỏ sót mảng nào.
- Kiểm tra từng dòng bằng phép thử "có thể bất đồng?". Với mỗi điều kiện, hỏi: hai người có thể tranh cãi về việc nó đã đạt chưa không? Nếu có, viết lại cho cụ thể và đo được.
- Loại bỏ những gì thực ra là Acceptance Criteria. Nếu một dòng chỉ đúng cho một tính năng cụ thể, nó không thuộc DoD. Chuyển nó về AC của PBI tương ứng.
- Đối chiếu với DoD tầng tổ chức (nếu có). Đảm bảo DoD của đội chặt bằng hoặc chặt hơn chuẩn tổ chức, không bao giờ lỏng hơn.
- Kiểm tra tính trung thực. Hỏi thẳng đội: "Sprint vừa rồi chúng ta có thực sự đạt hết các dòng này cho mọi item không?" Nếu không, hoặc đội cần cải thiện năng lực, hoặc DoD đang viết theo mơ ước. Chọn một hướng.
- Đưa vào nơi ai cũng thấy. Dán DoD lên board, ghim vào kênh chat, hoặc đưa vào template pull request. DoD giấu trong tài liệu không ai đọc là DoD chết.
- Lên lịch rà soát định kỳ. Đặt việc xem lại DoD vào Retrospective mỗi vài Sprint, đặc biệt khi sản phẩm thay đổi mức độ trưởng thành.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhồi Acceptance Criteria vào DoD. Tôi từng thấy một DoD có dòng "Nút thanh toán hiển thị màu cam." Đó là chi tiết của một tính năng, không phải tiêu chuẩn chung. Khi tính năng đó xong, dòng này thành vô nghĩa cho mọi item khác. Mẹo: nếu một dòng nhắc đến tên tính năng cụ thể, gần như chắc chắn nó sai chỗ.
Lỗi 2 — DoD chỉ là khẩu hiệu. "Chất lượng cao", "khách hàng hài lòng", "code sạch" — nghe hay nhưng không kiểm chứng được. Mẹo: thay mọi tính từ chủ quan bằng một điều kiện đo được.
Lỗi 3 — DoD viết theo mơ ước. Ghi "100% coverage, zero bug" trong khi đội còn không có CI. Mẹo: DoD phải mô tả những gì đội thực sự làm được hôm nay. Tham vọng thì để dành cho mục tiêu cải tiến trong Retrospective.
Lỗi 4 — Bỏ quên phần phi-chức năng và vận hành. Đội chỉ ghi code và test, quên bảo mật, hiệu năng, khả năng rollback. Đây là nơi giá trị âm thầm rò rỉ. Mẹo: với bối cảnh Việt Nam, luôn cân nhắc thêm: tương thích trình duyệt nội địa, hiệu năng trên mạng và thiết bị tầm trung, và bản địa hóa ngôn ngữ.
Lỗi 5 — PO đứng ngoài. Coi DoD "không phải việc của mình". Mẹo: bạn không viết DoD một mình, nhưng nếu một item "Done" mà không thể giao cho khách, chính uy tín của bạn với stakeholder bị tổn hại. Hãy tham gia.
Mẹo bonus cho kỳ thi PSPO I: Nhớ ba ý cốt lõi mà đề hay hỏi — (1) DoD áp dụng cho Increment, không phải riêng một PBI; (2) nếu tổ chức có DoD chuẩn, mọi đội phải tuân theo tối thiểu; (3) một PBI chưa đạt DoD thì không được tính vào Increment, không demo như đã xong, và quay lại Product Backlog.
Bài tập thực hành
- Viết DoD cho sản phẩm của bạn. Lấy chính sản phẩm bạn đang làm (hoặc một app bạn dùng hằng ngày như một ứng dụng gọi xe). Viết một DoD 8–12 dòng theo 6 cụm trong phần Hướng dẫn. Đảm bảo mỗi dòng vượt qua phép thử "có thể bất đồng?".
- Phân loại 10 phát biểu. Lấy 10 câu trộn lẫn giữa DoD và Acceptance Criteria (ví dụ: "Mọi API mới có rate limiting" / "Người dùng đặt lại mật khẩu qua email" / "Coverage ≥ 75%" / "Nút Mua hiển thị giá đã gồm VAT"). Tự phân loại đâu là DoD, đâu là AC, và giải thích lý do.
- Khám bệnh một DoD lỗi. Đây là một DoD thật-kiểu-lỗi: "Code đẹp. Test đầy đủ. Khách hàng vui. Deploy nhanh." Hãy chỉ ra từng vấn đề và viết lại thành các điều kiện kiểm chứng được.
- Tình huống tầng tổ chức. Tổ chức của bạn yêu cầu mọi đội phải quét bảo mật trước khi phát hành. Đội của bạn muốn bỏ bước này trong một Sprint gấp để kịp ra mắt. Với tư cách PO, bạn phản hồi thế nào, và Scrum Guide nói gì về việc nới lỏng DoD?
Tóm tắt
- DoD là một danh sách điều kiện kiểm chứng được, áp dụng cho mọi Increment — không phải khẩu hiệu, không phải Acceptance Criteria của một tính năng.
- Bộ khung kỹ thuật lõi (merge to main, unit test có ngưỡng coverage, integration test pass) là điểm khởi đầu, nhưng một DoD thật phải mở rộng sang phi-chức năng, bảo mật, tài liệu và triển khai.
- Ba ví dụ — web e-commerce (Tiki), ví điện tử có tuân thủ (MoMo), và SaaS B2B tiến hóa theo thời gian — cho thấy DoD phải khớp với loại sản phẩm và mức độ rủi ro; sản phẩm càng trưởng thành, DoD càng chặt.
- DoD có nhiều tầng: chuẩn tổ chức là sàn tối thiểu, đội chỉ được làm chặt hơn, không lỏng hơn.
- PO không sở hữu DoD một mình, nhưng phải tham gia — vì một Increment "Done" mà không giao được cho khách chính là giá trị bị rò rỉ, và đó là trách nhiệm của bạn.
- Đừng viết DoD theo mơ ước; hãy viết trung thực với năng lực hiện tại rồi nâng cấp dần qua Retrospective.