Mở đầu — vì sao bài này quan trọng
Nếu bạn đã đọc kỹ Scrum Guide từ đầu đến cuối, bạn sẽ nhận ra một điều thú vị: cụm từ "Definition of Ready" (DoR) không hề xuất hiện một lần nào. Trong khi đó, "Definition of Done" (DoD) lại được nhắc đi nhắc lại như một cam kết (commitment) chính thức gắn với Increment. Sự bất đối xứng này không phải ngẫu nhiên — và nó chính là một trong những cái bẫy mà đề thi PSM I rất thích giăng ra.
Trong thực tế đi làm, hầu hết các team Scrum mà bạn gặp ở Việt Nam — từ FPT Software, VNG, đến các startup fintech ở Sài Gòn — đều dùng một dạng "checklist sẵn sàng" nào đó trước khi đưa item vào Sprint. Điều đó hoàn toàn ổn. Vấn đề nảy sinh khi bạn bước vào phòng thi PSM I với tư duy "DoR là bắt buộc, không có DoR thì làm Scrum sai". Đó là lúc bạn mất điểm oan.
Bài này có hai nhiệm vụ song song. Thứ nhất, giúp bạn hiểu DoR thực sự là gì, dùng để làm gì, và khi nào nó hữu ích — vì với tư cách Scrum Master tương lai, bạn sẽ phải tư vấn cho team về công cụ này. Thứ hai, và quan trọng hơn cho kỳ thi, giúp bạn ghi nhớ dứt khoát: DoR là một technique tùy chọn (optional), KHÔNG phải là một phần bắt buộc của Scrum framework. Hai chữ "optional" và "by the book" sẽ là kim chỉ nam xuyên suốt bài học này.
Khái niệm cốt lõi
Definition of Ready là gì?
Definition of Ready là một tập hợp các tiêu chí (criteria) mà một Product Backlog Item (PBI) nên thỏa mãn trước khi nó được team xem là đủ rõ ràng để đưa vào Sprint Planning và bắt đầu làm. Nói nôm na, đó là một "checklist sẵn sàng" — một thỏa thuận của team về việc thế nào là một item "đủ chín" để bắt tay vào.
Một Definition of Ready điển hình có thể trông như thế này:
- Item được viết theo định dạng rõ ràng (ví dụ user story có đủ "As a... I want... so that...").
- Acceptance criteria (tiêu chí nghiệm thu) đã được mô tả rõ.
- Item đủ nhỏ để hoàn thành gọn trong một Sprint.
- Các dependency (phụ thuộc) bên ngoài đã được xác định.
- Team đã thảo luận và hiểu chung về item; không còn câu hỏi lớn nào treo lơ lửng.
- Đã có ước lượng (estimate) sơ bộ.
Vì sao DoR KHÔNG nằm trong Scrum Guide
Đây là phần cốt lõi cho kỳ thi, hãy đọc thật chậm.
Scrum Guide 2020 chỉ định nghĩa ba commitment chính thức, mỗi cái gắn với một artifact:
- Product Goal — gắn với Product Backlog.
- Sprint Goal — gắn với Sprint Backlog.
- Definition of Done — gắn với Increment.
Tại sao những người viết Scrum Guide cố tình không đưa DoR vào? Có một lý do triết lý sâu sắc, và đề thi rất thích kiểm tra điều này:
DoR có thể trở thành một "stage-gate" (cổng kiểm soát theo giai đoạn) cứng nhắc, làm hỏng tính empirical và self-management của team. Khi DoR được áp đặt như một quy tắc cứng — "item nào chưa đạt 100% DoR thì cấm đưa vào Sprint" — nó dễ biến thành một dạng phê duyệt quan liêu. Nó có thể tạo ra một "mini-waterfall": phải hoàn tất toàn bộ phân tích trước khi được phép bắt đầu. Điều này đi ngược lại tinh thần Scrum, nơi sự rõ ràng (clarity) xuất hiện dần qua quá trình làm và học hỏi.
Quan trọng nữa: trong Scrum, công cụ chính thức để làm cho item "sẵn sàng" không phải là một văn bản DoR, mà là Product Backlog Refinement — hoạt động liên tục (ongoing activity) mà Product Owner và Developers cùng làm để thêm chi tiết, ước lượng và sắp xếp item. Refinement đảm bảo các item ở phía trên Product Backlog đủ rõ để chọn vào Sprint. Nếu refinement được làm tốt, nhu cầu có một DoR cứng giảm đi rất nhiều.
DoR vs DoD — đừng nhầm lẫn
Một điểm gây rối thường gặp: nhiều học viên gộp chung DoR và DoD vì cả hai đều là "checklist". Nhưng bản chất chúng khác nhau hoàn toàn, và đề thi rất thích điểm này.
| Đặc điểm | Definition of Done (DoD) | Definition of Ready (DoR) |
|---|---|---|
| Có trong Scrum Guide? | Có — là commitment chính thức | Không — chỉ là technique tùy chọn |
| Gắn với artifact nào? | Increment | (Không có — không phải commitment) |
| Áp dụng ở thời điểm nào? | Khi item được coi là hoàn thành | Khi item được coi là sẵn sàng để bắt đầu |
| Bắt buộc? | Bắt buộc — không có DoD thì không tạo được transparency về Increment | Không bắt buộc |
| Mục đích | Đảm bảo chất lượng đầu ra, minh bạch về "xong" | Đảm bảo chất lượng đầu vào của Backlog Item |
Khi nào DoR thực sự hữu ích?
Đừng hiểu nhầm rằng "không bắt buộc" nghĩa là "không nên dùng". Với tư cách Scrum Master, bạn cần biết DoR là một công cụ tốt trong đúng hoàn cảnh:
- Team mới, còn non, hay kéo vào Sprint những item mơ hồ rồi tắc giữa chừng.
- Có nhiều dependency phức tạp với team khác hoặc bên thứ ba.
- Product Owner thường viết item quá sơ sài, khiến Developers liên tục phải đoán.
Tình huống thực tế
Tình huống 1 — Công ty fintech "MoMo-style" và cái cổng DoR cứng nhắc
Một team 6 Developers tại một ví điện tử ở TP.HCM (gọi là VíViệt cho dễ hình dung) áp dụng một DoR rất nghiêm: mỗi item phải đạt đủ 9 tiêu chí — gồm có wireframe đã duyệt, API contract đã ký với team backend, ước lượng story point, và chữ ký phê duyệt của một Business Analyst — thì mới được phép vào Sprint Planning.
Kết quả sau 3 Sprint: Sprint Planning nào cũng thiếu item "đạt chuẩn". Có Sprint, team chỉ kéo được 12 story point vào dù capacity là 30, đơn giản vì phần lớn backlog "chưa đủ ready". Developers ngồi chơi nửa Sprint chờ BA hoàn tất tài liệu. Tệ hơn, vì sợ "không đạt DoR", PO bắt đầu phình to mọi item với hàng tá chi tiết phân tích trước — chính là cái mini-waterfall mà Scrum muốn tránh.
Diễn giải: DoR ở đây đã biến thành stage-gate. Nó tạo ra hàng đợi (queue) chờ phê duyệt, giết throughput, và đẩy team về tư duy "phân tích xong hết rồi mới làm".
Bài học rút ra: Scrum Master vào cuộc, hướng dẫn team nới DoR thành một guideline ngắn gọn (3 tiêu chí cốt lõi thay vì 9), và đẩy mạnh refinement liên tục để clarity xuất hiện dần. Capacity sử dụng tăng từ 40% lên 85% sau 2 Sprint. Bài học PSM I: DoR cứng có thể vi phạm chính tinh thần empirical của Scrum, dù bản thân DoR không bị Scrum cấm.
Tình huống 2 — Bẫy trong phòng thi của bạn Linh
Linh, một học viên ở Đà Nẵng, làm bài thi thử PSM I và gặp câu: "Để một Product Backlog Item được chọn vào Sprint, nó BẮT BUỘC phải thỏa mãn Definition of Ready. Đúng hay Sai?"
Linh — vốn quen với team ở công ty mình luôn dùng DoR — bấm "Đúng". Sai. Cô mất điểm.
Diễn giải: Đáp án đúng là "Sai", vì Scrum không yêu cầu DoR. Việc một item có được chọn hay không là quyết định của Developers (những người sẽ làm), dựa trên việc họ tin item đủ rõ để hoàn thành trong Sprint và đóng góp vào Sprint Goal — chứ không dựa trên một checklist DoR bắt buộc nào do framework áp đặt.
Bài học rút ra: Trong phòng thi, hãy tách bạch hai thế giới: "thực tế công ty tôi làm" và "Scrum theo sách". Khi câu hỏi dùng các từ như bắt buộc, phải, yêu cầu, mandatory, required đi kèm DoR — hãy cảnh giác cao độ. Trả lời "by the book": DoR là optional.
Tình huống 3 — Startup edtech dùng DoR đúng cách như một guideline
Một startup edtech 15 người ở Hà Nội (gọi là HọcNhanh) có team thường xuyên kéo vào Sprint những item kiểu "Cải thiện trang chủ" — quá mơ hồ, không ai biết "cải thiện" là gì, dẫn đến tranh cãi giữa Sprint và Sprint Goal hay bị trật.
Scrum Master đề xuất team tự thống nhất một DoR nhẹ, gồm đúng 3 điểm: (1) item có một câu mô tả giá trị người dùng rõ ràng; (2) có ít nhất 2–3 acceptance criteria; (3) đủ nhỏ để xong trong một Sprint. Quan trọng: DoR này là thỏa thuận của chính team, không phải do quản lý áp xuống, và được phép linh hoạt — nếu một item chưa đạt đủ 3 điểm nhưng Developers vẫn tự tin làm được, họ vẫn có quyền kéo vào.
Sau 4 Sprint, số lần "tắc giữa Sprint vì item mơ hồ" giảm từ trung bình 4 lần/Sprint xuống còn 1. Sprint Goal đạt đều đặn hơn.
Diễn giải: Đây là cách dùng DoR đúng tinh thần — một heuristic hỗ trợ self-management, do team sở hữu, linh hoạt, không phải cổng phê duyệt quan liêu.
Bài học rút ra: DoR không xấu. Cái xấu là khi nó cứng nhắc và bị áp đặt. Scrum Master tốt giúp team dùng DoR như một công cụ phục vụ họ, chứ không để team phục vụ DoR.
Hướng dẫn từng bước
Nếu team của bạn muốn áp dụng DoR một cách lành mạnh, đây là quy trình mentor khuyên dùng:
- Xác nhận nhu cầu thật sự. Hỏi: "Chúng ta có thực sự đang tắc vì item mơ hồ không?" Nếu refinement đang làm tốt và item vào Sprint luôn rõ ràng, có thể bạn không cần DoR. Đừng thêm process chỉ vì "ai cũng có".
- Để team tự định nghĩa, không áp đặt. DoR phải do Scrum Team (đặc biệt là Developers, vì họ là người làm) cùng xây trong một buổi workshop hoặc Retrospective. DoR áp từ trên xuống gần như luôn biến thành stage-gate.
- Giữ nó tối giản. Bắt đầu với 3–5 tiêu chí cốt lõi nhất. Càng dài, càng dễ thành quan liêu. Ưu tiên các tiêu chí về sự rõ ràng (clarity) hơn là về tài liệu (documentation).
- Định khung nó là guideline, không phải gate. Nói rõ với team: DoR là kim chỉ nam giúp ta quyết định, không phải luật cấm. Developers vẫn có toàn quyền chọn item vào Sprint dựa trên phán đoán chuyên môn.
- Gắn DoR với Refinement, không phải với phê duyệt. DoR là thước đo để biết một item đã được refine đủ chưa — chứ không phải một checkpoint cần ai đó ký duyệt.
- Thanh tra và thích nghi (inspect & adapt) trong Retrospective. Mỗi vài Sprint, hỏi: "DoR có còn giúp ta không, hay đang cản ta?" Sửa hoặc bỏ nếu cần. DoR không phải bất biến.
- Tuyệt đối tách bạch khi đi thi. Dù công ty bạn dùng DoR ra sao, trong phòng thi PSM I luôn nhớ: Scrum framework không yêu cầu DoR.
Lỗi thường gặp & mẹo
Lỗi 1 — Tưởng DoR là bắt buộc trong Scrum. Đây là lỗi số một và là cái bẫy phổ biến nhất trong đề thi. Khắc cốt ghi tâm: DoR là optional, giống User Stories, Story Points, Planning Poker.
Lỗi 2 — Nhầm DoR với DoD. Nhớ: DoD bắt buộc và gắn với Increment (đầu ra); DoR tùy chọn và liên quan đến input của Backlog Item. Một cái là cổng RA, một cái là cổng VÀO.
Lỗi 3 — Biến DoR thành stage-gate cứng. Khi DoR thành cổng phê duyệt, nó tạo hàng đợi, mini-waterfall, giết tính linh hoạt. Đây vừa là sai lầm thực tế, vừa là nội dung mà câu hỏi tình huống PSM I hay xoáy vào.
Lỗi 4 — Nghĩ "không bắt buộc" nghĩa là "vô dụng". Sai hướng ngược lại. DoR là công cụ tốt khi dùng đúng. Scrum Master cần biết tư vấn cả hai chiều: khi nào nên dùng và khi nào nên buông.
Lỗi 5 — Để ai đó bên ngoài team quyết một item có "ready" không. Quyết định item nào vào Sprint thuộc về Developers. DoR không nên trao quyền đó cho một BA, manager hay PO đơn lẻ.
Mẹo thi nhanh: Khi gặp từ khóa DoR trong câu hỏi, tự động gắn nhãn "optional / not in Scrum Guide" trong đầu. Nếu một phương án nói DoR là phần chính thức/bắt buộc của Scrum → loại. Nếu một phương án nói DoR là một technique bổ trợ tùy chọn mà team có thể chọn dùng → nhiều khả năng đúng.
Mẹo phân biệt với Refinement: Refinement là hoạt động liên tục, chính thức được nhắc trong Scrum Guide (dù không phải event). DoR chỉ là một tiêu chí tùy chọn có thể dùng kèm refinement. Đừng để câu hỏi đánh tráo hai khái niệm này.
Bài tập thực hành
- Tự kiểm tra trí nhớ: Liệt kê ba commitment chính thức trong Scrum và artifact tương ứng. Sau đó tự trả lời: DoR có nằm trong danh sách đó không? Vì sao?
- Phân loại đúng/sai: Với mỗi câu sau, đánh dấu Đúng hay Sai theo Scrum Guide, và giải thích một câu:
- Tình huống tư vấn: Một team đến gặp bạn (Scrum Master) than rằng họ liên tục tắc giữa Sprint vì item mơ hồ, và một manager đề nghị áp một DoR 12 mục có chữ ký phê duyệt. Viết 4–5 câu bạn sẽ nói để hướng team đến một giải pháp lành mạnh hơn.
- So sánh: Lập một bảng nhỏ của riêng bạn so sánh DoR và DoD theo 4 trục: có-trong-Scrum-Guide, bắt-buộc-hay-không, gắn-với-cái-gì, áp-dụng-ở-thời-điểm-nào. Làm xong rồi mới đối chiếu lại với bảng trong bài.
Tóm tắt
- Definition of Ready (DoR) là một checklist tiêu chí mà một Product Backlog Item nên thỏa mãn trước khi được đưa vào Sprint — giúp đảm bảo chất lượng đầu vào.
- DoR KHÔNG có trong Scrum Guide. Nó là một technique tùy chọn (optional), không phải commitment, artifact, event hay accountability. Đây là điểm thi quan trọng nhất của bài.
- Ba commitment chính thức là Product Goal, Sprint Goal và Definition of Done — DoD mới là cái bắt buộc, gắn với Increment.
- Đừng nhầm DoR (cổng đầu VÀO, tùy chọn) với DoD (cổng đầu RA, bắt buộc).
- DoR dùng đúng cách là một guideline linh hoạt do team sở hữu; dùng sai cách nó biến thành stage-gate cứng nhắc, tạo mini-waterfall và giết tính empirical.
- Công cụ chính thức của Scrum để làm item "đủ rõ để bắt đầu" là Product Backlog Refinement, không phải một văn bản DoR.
- Trong phòng thi: thấy DoR đi kèm các từ bắt buộc / phải / yêu cầu → cảnh giác, gần như chắc chắn là đáp án sai. Luôn trả lời "by the book": DoR là optional.