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 team làm phần mềm ngân hàng. Sprint Planning bắt đầu, cả team ngồi vào bàn, và bạn đưa lên một user story: "Là khách hàng, tôi muốn chuyển tiền nhanh". Chấm hết. Không có acceptance criteria, không có thiết kế màn hình, không ai biết "chuyển nhanh" là qua Napas hay nội bộ, giới hạn bao nhiêu, cần OTP hay không. Team gật gù kéo story vào sprint, rồi ba ngày sau developer gõ cửa hỏi: "Anh ơi, chuyển nhanh là gì?" Và thế là sprint đứng hình.
Ở đầu bên kia, một tình huống khác: developer báo "task xong rồi" và đóng ticket. Nhưng "xong" của bạn ấy là code chạy được trên máy local. Chưa có unit test, chưa merge, chưa qua code review, QA chưa hề đụng tới. Đến cuối sprint, khi demo cho khách, cả đống "task đã xong" bỗng dưng vỡ trận vì thực ra chẳng có gì thật sự hoàn thành.
Hai bi kịch này — story vào sprint mà chưa sẵn sàng, và task báo xong mà chưa thực sự xong — chính là lý do tồn tại của Definition of Ready (DoR) và Definition of Done (DoD). Đây là hai "hợp đồng chất lượng" mà cả team tự đặt ra và cam kết tuân thủ. DoR là cánh cổng đầu vào: quyết định khi nào một hạng mục công việc đủ điều kiện bước vào sprint. DoD là vạch đích: định nghĩa rõ ràng thế nào là "hoàn thành thực sự".
Với người làm Project Management, đặc biệt là PM/Scrum Master, hiểu và vận hành tốt DoR & DoD là kỹ năng nền tảng để bảo vệ chất lượng, kiểm soát phạm vi, và giữ cho sprint không bị vỡ. Bài này sẽ giúp bạn nắm chắc cả hai công cụ, biết cách xây dựng chúng phù hợp với team mình, và tránh những cái bẫy phổ biến.
Khái niệm cốt lõi
Definition of Ready (DoR) — điều kiện để story bước vào sprint
Definition of Ready là một danh sách các tiêu chí mà một Product Backlog Item (thường là user story) phải thỏa mãn trước khi được đưa vào sprint để thực thi. Nói cách khác, DoR trả lời câu hỏi: "Story này đã đủ rõ ràng, đủ chi tiết để team có thể bắt tay làm ngay mà không phải dừng lại hỏi đi hỏi lại chưa?"
DoR bảo vệ team khỏi việc nhận vào những công việc mập mờ. Nó là tấm lưới lọc ở đầu vào của sprint. Một số tiêu chí DoR điển hình:
- User story được viết đúng format: theo mẫu "Là [vai trò], tôi muốn [mục tiêu], để [giá trị]". Format này buộc người viết phải nghĩ rõ ai dùng, dùng để làm gì, và tại sao.
- Acceptance criteria đã được viết rõ ràng: các điều kiện chấp nhận cụ thể, kiểm tra được. Ví dụ dùng cú pháp Given–When–Then. Đây là phần quan trọng nhất — không có acceptance criteria thì developer chỉ đang đoán mò.
- Thiết kế (design/mockup) đã sẵn sàng nếu story liên quan đến giao diện. Developer không nên phải tự tưởng tượng UI.
- Dependencies đã được xác định và giải quyết: nếu story phụ thuộc vào API của team khác, vào dữ liệu, hay vào một quyết định pháp lý chưa có, thì chưa Ready.
- Story đã được ước lượng (estimated) bởi team, thường qua Planning Poker, story point.
- Đủ nhỏ để hoàn thành trọn vẹn trong một sprint. Nếu quá lớn, cần tách nhỏ.
- Team hiểu và đồng thuận — không còn câu hỏi lớn nào chưa được trả lời.
Definition of Done (DoD) — điều kiện để công việc được coi là hoàn thành
Definition of Done là danh sách các tiêu chí mà một hạng mục công việc phải thỏa mãn để được coi là "hoàn thành thực sự". DoD trả lời câu hỏi: "Khi nào chúng ta được phép nói task/story/increment này đã xong và có thể giao cho khách?"
Điểm mấu chốt: DoD chống lại cái mà giới Agile gọi là "undone work" — công việc trông có vẻ xong nhưng thực chất còn nợ một đống việc ẩn (test, review, tài liệu, deploy). Nếu không có DoD chung, mỗi người sẽ có một định nghĩa "xong" riêng, và velocity của team trở nên vô nghĩa.
Trong Scrum Guide, DoD là một cam kết (commitment) gắn liền với Increment. Một số tiêu chí DoD điển hình:
- Code đã được viết và tuân thủ coding convention của team.
- Unit test đã viết và pass; độ phủ (coverage) đạt ngưỡng cam kết (ví dụ ≥ 80%).
- Code đã qua code review và được merge vào nhánh chính.
- Đã qua kiểm thử tích hợp (integration test) và QA đã test đạt.
- Không còn bug nghiêm trọng (critical/blocker) tồn đọng.
- Tài liệu liên quan đã được cập nhật.
- Đã deploy thành công lên môi trường staging.
- Acceptance criteria của story đều được thỏa mãn.
DoR và DoD khác nhau thế nào?
Đây là chỗ nhiều bạn hay nhầm. Hãy phân biệt rạch ròi:
| Tiêu chí | Definition of Ready | Definition of Done |
|---|---|---|
| Thời điểm áp dụng | Đầu vào sprint (trước khi làm) | Đầu ra (sau khi làm xong) |
| Câu hỏi trả lời | "Story đã đủ rõ để bắt đầu chưa?" | "Công việc đã hoàn thành thực sự chưa?" |
| Ai chịu trách nhiệm chính | Product Owner chuẩn bị backlog | Developers thực thi |
| Vai trò trong Scrum Guide | Không bắt buộc (tùy chọn) | Bắt buộc (là commitment chính thức) |
Một lưu ý quan trọng về mặt lý thuyết: DoD được Scrum Guide chính thức công nhận là một commitment, còn DoR không nằm trong Scrum Guide và là một thực hành tùy chọn. Một số team Agile "thuần" thậm chí phản đối DoR quá cứng nhắc vì nó có thể tạo ra một "cửa quan" (gate) làm giảm tính linh hoạt. Vì vậy, hãy dùng DoR như một hướng dẫn (guideline) hơn là một rào chắn cứng.
Tình huống thực tế
Ví dụ 1 — Team fintech tại TP.HCM và bài học từ một DoR lỏng lẻo
Một startup ví điện tử ở TP.HCM (ta gọi là PayNhanh) có một team Scrum 6 người. Trong ba sprint liên tiếp, họ đạt velocity trung bình chỉ 18 story point trong khi cam kết 30. Truy vết nguyên nhân, Scrum Master phát hiện: gần 40% thời gian dev bị "đóng băng" vì story vào sprint mà thiếu thông tin. Điển hình là story "Tích hợp thanh toán qua VNPay" được kéo vào sprint nhưng chưa hề có tài khoản sandbox từ VNPay, chưa có tài liệu API, và chưa rõ luồng hoàn tiền.
Team quyết định áp dụng DoR nghiêm túc. Họ đặt ra 6 tiêu chí, trong đó có một tiêu chí "sát sườn" với đặc thù fintech: "Mọi story tích hợp bên thứ ba phải có sẵn tài khoản sandbox và tài liệu API được đính kèm trước Sprint Planning." Sau hai sprint áp dụng, số story bị block giảm từ trung bình 5 xuống còn 1, và velocity ổn định ở mức 27–29.
Bài học: DoR không phải là mẫu chung cho mọi team. Tiêu chí hiệu quả nhất là tiêu chí được rút ra từ chính "nỗi đau" lặp đi lặp lại của team bạn. PayNhanh không copy DoR trên mạng — họ nhìn vào lý do sprint hay vỡ và biến nó thành tiêu chí.
Ví dụ 2 — Dự án outsourcing và cái giá của DoD mơ hồ
Một công ty gia công phần mềm tại Hà Nội (giả định tên là VietSoft) nhận dự án cho khách Nhật Bản. Cuối mỗi sprint, team báo cáo "hoàn thành 25 story point". Khách hàng vui vẻ. Nhưng đến milestone tháng thứ ba, khi khách yêu cầu bàn giao bản chạy trên môi trường UAT, mọi thứ sụp đổ: 60% các story "đã xong" chưa hề có test tự động, nhiều tính năng chưa qua QA, và có tới 40 bug tồn đọng không ai ghi nhận. Khách Nhật — vốn cực kỳ khắt khe về chất lượng — mất niềm tin, và VietSoft phải bỏ thêm gần một tháng công không tính phí để "trả nợ kỹ thuật".
Gốc rễ: mỗi developer có một định nghĩa "xong" riêng. Có người coi "code chạy trên local" là xong, người khác coi "đã merge" là xong. Sau sự cố, VietSoft xây dựng một DoD dùng chung, dán ngay trên tường phòng team và tích hợp thành checklist bắt buộc trong công cụ Jira: một task chỉ được chuyển sang cột "Done" khi đã pass unit test, qua code review của ít nhất một người khác, QA xác nhận, và không còn bug ưu tiên cao. Ba sprint sau đó, số bug rò rỉ sang UAT giảm 85%.
Bài học: Velocity chỉ có ý nghĩa khi mọi "Done" đều đồng nhất. DoD không có nghĩa lý gì nếu chỉ nằm trên giấy — nó phải được "cưỡng chế" qua công cụ (Jira workflow, pull request template, CI pipeline) để không ai có thể lách qua.
Ví dụ 3 — DoD nhiều tầng ở một team thương mại điện tử
Một team làm sàn thương mại điện tử tại Đông Nam Á (giả định tên Shoply) nhận ra rằng dùng một DoD duy nhất cho mọi cấp độ là không đủ. Họ thiết kế DoD phân tầng:
- DoD cho một task (subtask kỹ thuật): code xong, self-test xong, đẩy lên nhánh feature.
- DoD cho một user story: mọi task con đã done, đã merge, QA test đạt, acceptance criteria thỏa mãn.
- DoD cho một release increment: tất cả story trong release đã done, đã qua regression test, đã deploy staging, đã có tài liệu release note, đã được Product Owner nghiệm thu.
Bài học: DoD không nhất thiết là một danh sách phẳng duy nhất. Với dự án phức tạp, DoD nhiều tầng (task → story → increment/release) phản ánh đúng thực tế công việc và tránh gánh nặng quy trình không cần thiết.
Hướng dẫn từng bước
Dưới đây là quy trình thực tế để bạn xây dựng và vận hành DoR & DoD cho team của mình.
Bước 1 — Tổ chức một workshop cùng cả team. DoR và DoD không phải do PM hay Scrum Master áp đặt từ trên xuống. Chúng phải là thỏa thuận tập thể để mọi người cảm thấy "sở hữu" và tự nguyện tuân thủ. Dành 60–90 phút mời cả Developers, QA, Product Owner cùng ngồi lại.
Bước 2 — Truy tìm "nỗi đau" thật của team. Hỏi hai câu: "Lần gần nhất một story vào sprint mà làm mãi không xong vì thiếu thông tin là khi nào?" và "Đã bao giờ chúng ta báo xong nhưng thực ra chưa xong chưa?" Từ câu trả lời, những tiêu chí DoR/DoD đầu tiên sẽ tự lộ diện.
Bước 3 — Soạn thảo danh sách DoR. Bắt đầu ngắn gọn, 5–8 tiêu chí. Ví dụ mẫu DoR:
- User story viết đúng format (vai trò / mục tiêu / giá trị).
- Acceptance criteria đã viết, kiểm thử được.
- Thiết kế/mockup sẵn sàng (nếu có UI).
- Dependencies đã xác định và không còn blocker.
- Story đã được ước lượng và đủ nhỏ để làm trong một sprint.
- Code hoàn thành, tuân thủ coding convention.
- Unit test viết đủ và pass; coverage đạt ngưỡng cam kết.
- Đã qua code review và merge vào nhánh chính.
- QA test đạt, không còn bug critical/blocker.
- Tài liệu cập nhật, đã deploy staging.
Bước 6 — Nhúng vào công cụ và quy trình. Đưa DoD thành Definition of Done checklist trong Jira/Azure DevOps, thành pull request template, thành cổng chặn trong CI pipeline. Dán DoR/DoD ở nơi ai cũng thấy (trên tường hoặc pin trong kênh Slack/Teams của team).
Bước 7 — Áp dụng tại đúng "nghi thức" (ceremony). Kiểm tra DoR trong Backlog Refinement và ngay đầu Sprint Planning — chỉ những story Ready mới được đưa vào sprint. Kiểm tra DoD tại Daily Scrum (khi ai đó nói "xong") và Sprint Review (trước khi demo).
Bước 8 — Rà soát và tiến hóa trong Retrospective. DoR/DoD là tài liệu sống. Mỗi vài sprint, đưa chúng ra Retrospective: tiêu chí nào thừa, tiêu chí nào thiếu, tiêu chí nào team không tuân thủ được. Khi năng lực team tăng lên, hãy nâng chuẩn DoD (ví dụ thêm yêu cầu về performance test).
Lỗi thường gặp & mẹo
Lỗi 1 — Biến DoR thành một cửa quan cứng nhắc. Nhiều team lạm dụng DoR đến mức mọi story phải "hoàn hảo tuyệt đối" mới được vào sprint, làm chậm cả dòng chảy và tạo ra tâm lý quan liêu. Mẹo: coi DoR là hướng dẫn, cho phép ngoại lệ có kiểm soát. Đôi khi việc bắt đầu một story "gần Ready" và làm rõ dần trong sprint lại nhanh hơn là chờ mọi thứ hoàn hảo.
Lỗi 2 — DoD chỉ nằm trên giấy. Team viết DoD rất đẹp nhưng không ai thực sự tuân theo, và không có cơ chế cưỡng chế. Mẹo: nhúng DoD vào công cụ — không merge được nếu chưa qua review, không chuyển cột "Done" nếu chưa tick đủ checklist.
Lỗi 3 — Copy DoR/DoD từ internet. Danh sách của team khác không phản ánh nỗi đau của team bạn. Mẹo: luôn bắt đầu từ vấn đề thực tế của chính team, rồi mới tham khảo mẫu bên ngoài để bổ sung.
Lỗi 4 — Nhầm lẫn Acceptance Criteria với DoD. Đây là lỗi rất phổ biến. Acceptance Criteria là riêng cho từng story (điều kiện chấp nhận đặc thù của story đó). DoD là chung cho mọi story (chuẩn chất lượng áp dụng toàn bộ). Một story chỉ "Done" khi thỏa mãn cả acceptance criteria riêng và DoD chung. Mẹo ghi nhớ: Acceptance Criteria trả lời "story này làm đúng chưa?", DoD trả lời "story này làm xong tử tế chưa?".
Lỗi 5 — DoD quá tham vọng ngay từ đầu. Đặt coverage 95% khi team chưa có thói quen viết test sẽ khiến DoD bị phá vỡ liên tục và mất uy tín. Mẹo: bắt đầu với chuẩn team đạt được, rồi nâng dần từng sprint.
Mẹo vàng: In DoR và DoD ra giấy A3, dán ngay cạnh bảng công việc. Khi tranh cãi "story này Ready chưa?" hay "task này Done chưa?", chỉ cần chỉ tay lên tường. Nó biến những cuộc tranh luận cảm tính thành đối chiếu khách quan.
Bài tập thực hành
- Kiểm tra DoR: Cho user story sau, hãy chỉ ra ít nhất 3 lý do nó CHƯA Ready và viết lại cho đạt DoR: "Là người dùng, tôi muốn tìm kiếm sản phẩm." (Gợi ý: thiếu acceptance criteria? thiếu phạm vi tìm kiếm — theo tên, theo mã, theo danh mục? thiếu xử lý khi không có kết quả? có phân trang không?)
- Xây DoD cho team giả định: Bạn là Scrum Master của một team 5 người làm ứng dụng đặt đồ ăn. Hãy soạn một DoD gồm 6 tiêu chí, đảm bảo mỗi tiêu chí đều "kiểm tra được" (đo lường được, không mơ hồ).
- Phân biệt khái niệm: Với story "Đăng nhập bằng số điện thoại và OTP", hãy liệt kê 3 mục thuộc Acceptance Criteria riêng của story và 3 mục thuộc DoD chung của team. Giải thích sự khác nhau.
- Tình huống xử lý: Cuối sprint, developer nói "tôi làm xong 100% story rồi nhưng chưa kịp viết unit test và chưa merge". Theo DoD, story này Done chưa? Bạn — với vai trò Scrum Master — sẽ ghi nhận velocity thế nào và xử lý cuộc trò chuyện này ra sao?
Tóm tắt
Definition of Ready và Definition of Done là hai "hợp đồng chất lượng" bảo vệ sprint ở hai đầu. DoR là cổng đầu vào: đảm bảo story đủ rõ ràng — đúng format, có acceptance criteria, thiết kế sẵn sàng, dependencies được giải quyết, đã ước lượng và đủ nhỏ — trước khi bước vào sprint. DoD là vạch đích: đảm bảo công việc thực sự hoàn thành — code review, test pass, QA đạt, không còn bug nghiêm trọng, đã deploy — chứ không phải "xong trên máy tôi".
Cần nhớ ba điều cốt lõi: (1) DoR áp dụng ở đầu vào, DoD ở đầu ra; DoD là commitment chính thức trong Scrum, DoR là thực hành tùy chọn. (2) Đừng nhầm Acceptance Criteria (riêng từng story) với DoD (chung cho mọi story). (3) DoR/DoD chỉ có giá trị khi được cả team đồng thuận, được nhúng vào công cụ để cưỡng chế, và được tiến hóa liên tục qua Retrospective.
Những ví dụ từ PayNhanh, VietSoft và Shoply cho thấy cùng một bài học: các tiêu chí hiệu quả nhất không phải copy từ đâu đó, mà được rút ra từ chính nỗi đau lặp lại của team bạn. Hãy bắt đầu ngắn gọn, đo lường được, và nâng chuẩn dần khi team trưởng thành.