Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng buổi Sprint Planning của một đội phát triển app fintech tại TP.HCM. Product Owner kéo một backlog item lên màn hình: "Tích hợp cổng thanh toán mới". Developers nhìn nhau. Cổng nào? VNPay, Momo hay ZaloPay? Đã có tài khoản sandbox chưa? API docs ở đâu? Yêu cầu bảo mật PCI-DSS thế nào? Không ai trả lời được. Hai mươi phút trôi qua trong tranh luận, và item đó cuối cùng bị bỏ lại — Sprint Planning kéo dài thêm một tiếng, năng lượng cả đội tụt dốc.
Đây chính xác là vấn đề mà Definition of Ready (DoR) sinh ra để giải quyết. Nó là một thỏa thuận về việc: "Một Product Backlog Item phải đạt mức độ rõ ràng tới đâu trước khi đội tự tin kéo nó vào Sprint?"
Nhưng có một điều bạn PHẢI nắm vững — và đây là điểm dễ bị hỏi nhất trong kỳ thi PSPO I: DoR KHÔNG nằm trong Scrum Guide. Nó là một practice (thông lệ) optional, KHÔNG bắt buộc, KHÔNG phải artifact, KHÔNG phải commitment chính thức của Scrum. Nếu một câu hỏi thi ngụ ý rằng "Scrum yêu cầu có Definition of Ready" — đó là bẫy, và đáp án đúng luôn là phủ nhận.
Trong bài này, chúng ta sẽ tách bạch rõ: DoR thực sự là gì, vì sao nó hữu ích, vì sao nó KHÔNG mandatory, và quan trọng nhất — làm sao dùng nó như một công cụ chứ đừng để nó biến thành một cánh cổng quan liêu giết chết sự linh hoạt của đội.
Khái niệm cốt lõi
DoR là gì?
Definition of Ready là một checklist (danh sách kiểm tra) các tiêu chí mà một Product Backlog Item (PBI) nên thỏa mãn trước khi được đưa vào một Sprint. Mục đích là đảm bảo item đủ "chín" — đủ rõ ràng, đủ nhỏ, đủ thông tin — để Developers có thể bắt tay làm ngay mà không bị tắc giữa chừng vì thiếu dữ kiện.
Một DoR điển hình có thể gồm các tiêu chí như:
- PBI có mô tả rõ ràng giá trị mang lại (vì sao làm cái này?).
- Có Acceptance Criteria (tiêu chí nghiệm thu) cụ thể, kiểm chứng được.
- Đã được estimate (ước lượng) bởi Developers.
- Đủ nhỏ để hoàn thành trong một Sprint.
- Các phụ thuộc (dependencies) đã được nhận diện và xử lý.
- Tài nguyên cần thiết (thiết kế UI, tài khoản test, dữ liệu mẫu) đã sẵn sàng.
DoR có trong Scrum Guide không? KHÔNG.
Đây là phần cốt lõi nhất bạn cần khắc cốt ghi tâm cho kỳ thi. Scrum Guide 2020 định nghĩa rõ ba commitment:
- Product Goal gắn với Product Backlog.
- Sprint Goal gắn với Sprint Backlog.
- Definition of Done gắn với Increment.
Hãy phân biệt thật rõ với "người anh em" của nó:
| Tiêu chí | Definition of Ready (DoR) | Definition of Done (DoD) |
|---|---|---|
| Có trong Scrum Guide? | KHÔNG | CÓ |
| Bản chất | Practice optional | Commitment bắt buộc của Increment |
| Áp dụng cho | PBI trước khi vào Sprint | Increment sau khi hoàn thành |
| Ai sở hữu | Cả đội thỏa thuận (nếu dùng) | Developers (tuân theo chuẩn tổ chức) |
Vì sao DoR vẫn hữu ích?
Optional không có nghĩa là vô dụng. Một DoR tốt giúp:
- Giảm "rác" vào Sprint: ngăn những item mơ hồ làm hỏng Sprint Planning và buộc phải hủy dở giữa chừng.
- Tạo ngôn ngữ chung: cả PO và Developers cùng hiểu thế nào là "đủ rõ để làm".
- Cải thiện forecast: item rõ ràng thì ước lượng chính xác hơn, giảm rủi ro không đạt Sprint Goal.
Cái bẫy lớn nhất: DoR thành cổng quan liêu
Mặt trái nguy hiểm: nếu DoR quá khắt khe, nó biến thành một "stage-gate" kiểu thác nước (waterfall). Đội từ chối nhận bất kỳ item nào chưa "100% Ready", PO bị ép phải viết spec chi tiết tới từng pixel trước khi được phép đưa vào bàn — và thế là tính linh hoạt, tính khám phá (empiricism) của Scrum bị bóp chết. DoR phải là một hướng dẫn (guideline), không phải một hợp đồng pháp lý.
Tình huống thực tế
Ví dụ 1 — DoR cứu Sprint Planning tại một startup logistics ở Hà Nội
Một startup giao hàng chặng cuối (last-mile) tại Hà Nội, đội 6 Developers, gặp vấn đề kinh niên: cứ mỗi Sprint Planning lại mất 2-3 tiếng vì backlog item quá mơ hồ. Tỷ lệ item phải đưa ra khỏi Sprint giữa chừng (carry-over) lên tới 40%.
Scrum Master đề xuất cả đội cùng xây một DoR nhẹ, gồm 4 tiêu chí: (1) có Acceptance Criteria, (2) đã estimate dưới 8 story points, (3) thiết kế UI đã được duyệt nếu có giao diện, (4) không còn câu hỏi mở lớn. Họ dán nó lên bảng Jira như một checklist nhắc nhở trong refinement.
Diễn giải: Sau 4 Sprint, thời gian Planning giảm còn 45 phút, carry-over giảm xuống 15%. Quan trọng là PO không hề phải viết spec dày hơn — DoR chỉ buộc các câu hỏi lớn được hỏi sớm, trong refinement, thay vì để dồn tới lúc Planning.
Bài học: DoR phát huy giá trị nhất khi nó đẩy việc làm rõ về sớm hơn trong dòng thời gian, chứ không phải tạo thêm gánh nặng tài liệu.
Ví dụ 2 — Khi DoR bóp nghẹt sự linh hoạt tại một công ty outsourcing ở Đà Nẵng
Một công ty outsourcing tại Đà Nẵng làm dự án cho khách hàng Nhật. Phòng PMO áp một DoR gồm 14 tiêu chí, trong đó có cả "phải có wireframe chi tiết từng màn hình", "phải có test case viết sẵn", "phải được khách hàng ký duyệt qua email". Hệ quả: PO mất trung bình 2 tuần để đưa được một item qua cổng "Ready".
Khi khách hàng đề xuất một thử nghiệm nhỏ — một tính năng A/B test chỉ cần làm trong 2 ngày để kiểm chứng giả thuyết — đội từ chối nhận vào Sprint vì "chưa đủ Ready". Cơ hội học hỏi nhanh bị bỏ lỡ. Đội đã biến DoR thành waterfall trá hình.
Diễn giải: DoR ở đây không còn phục vụ đội nữa, mà phục vụ quy trình. Nó vi phạm tinh thần empiricism — vốn khuyến khích thử nghiệm nhỏ, học nhanh, điều chỉnh. Một item làm trong 2 ngày để học hỏi đôi khi không cần đủ "Ready" theo nghĩa truyền thống.
Bài học: DoR càng nhiều tiêu chí và càng cứng thì rủi ro biến thành rào cản càng cao. Hãy giữ nó tinh gọn, và luôn cho phép ngoại lệ khi mục tiêu là học hỏi nhanh.
Ví dụ 3 — Câu hỏi của một thí sinh PSPO I
Linh, một Business Analyst tại một ngân hàng ở Sài Gòn, đang ôn thi PSPO I. Trong một bài Open Assessment, cô gặp câu: "Một PBI chưa đáp ứng Definition of Ready của đội. Developers có được phép kéo nó vào Sprint không?" Linh phân vân giữa "Không, vì vi phạm DoR" và "Có thể, nếu đội quyết định".
Đáp án đúng nghiêng về "Có" — bởi vì DoR không phải luật của Scrum. Developers, với tư cách là một Self-Managing Team, có toàn quyền quyết định kéo item nào vào Sprint nếu họ tự tin có thể đạt Sprint Goal. DoR chỉ là hướng dẫn họ tự đặt ra cho mình, không phải xiềng xích.
Bài học: Trong thế giới quan của PSPO I, không bao giờ để một practice optional (DoR) lấn át quyền tự quản của Scrum Team hay các quy tắc chính thức của framework.
Hướng dẫn từng bước
Nếu đội bạn quyết định dùng DoR (nhắc lại: đây là lựa chọn, không bắt buộc), hãy làm theo trình tự sau:
Bước 1 — Xác nhận đội thực sự cần DoR. Đừng áp DoR chỉ vì sách bảo thế. Nếu Sprint Planning của bạn đã trôi chảy và backlog luôn rõ ràng, có thể bạn không cần. DoR là thuốc cho một căn bệnh cụ thể: item vào Sprint quá mơ hồ.
Bước 2 — Cùng nhau xây, đừng áp đặt từ trên xuống. DoR phải do cả Scrum Team thỏa thuận trong một Retrospective hoặc workshop. PO không được tự ra lệnh, PMO cũng không. Một DoR bị áp đặt sẽ bị đội phản kháng và làm cho có.
Bước 3 — Giữ nó tinh gọn. Bắt đầu với 3-5 tiêu chí, không hơn. Câu hỏi vàng cho mỗi tiêu chí: "Nếu thiếu cái này, item có thực sự gây tắc khi làm không?" Nếu không, loại bỏ.
Bước 4 — Gắn DoR vào Product Backlog Refinement. DoR là tiêu chuẩn đầu ra của refinement. Trong mỗi buổi refinement, dùng DoR như một checklist để biết item đã sẵn sàng hay cần làm rõ thêm.
Bước 5 — Cho phép linh hoạt. Tuyên bố rõ ràng: DoR là guideline, không phải rào cản tuyệt đối. Đội có quyền nhận một item chưa đủ Ready nếu họ thấy hợp lý (ví dụ: spike khám phá, thử nghiệm học hỏi nhanh).
Bước 6 — Định kỳ rà soát. Đưa DoR ra xem lại mỗi vài Sprint trong Retrospective. Nó có còn giúp ích không? Có tiêu chí nào thừa, hay đang biến thành cổng quan liêu không? Điều chỉnh hoặc bỏ hẳn nếu cần.
Lỗi thường gặp & mẹo
Lỗi 1 — Tin rằng DoR là bắt buộc trong Scrum. Đây là lỗi chết người trong kỳ thi. DoR không có trong Scrum Guide. Chỉ DoD mới là commitment bắt buộc. Khắc ghi: Ready = optional, Done = mandatory.
Lỗi 2 — Biến DoR thành stage-gate kiểu waterfall. Khi DoR quá khắt khe tới mức PO phải viết spec đầy đủ trước, đội đang lén lút quay về thác nước. Empiricism cần không gian cho cái chưa hoàn hảo.
Lỗi 3 — Dùng DoR như công cụ đổ lỗi. "Item này fail vì PO không làm đủ Ready" — đây là tư duy độc hại. DoR không phải để chỉ tay; nó là thỏa thuận chung để cả đội cùng tốt lên.
Lỗi 4 — Nhầm DoR là điều kiện để item tồn tại trong backlog. Sai. Mọi item, dù mơ hồ tới đâu, vẫn có thể nằm trong Product Backlog. DoR chỉ liên quan tới thời điểm item được kéo vào Sprint, không phải thời điểm nó được thêm vào backlog.
Mẹo cho kỳ thi: Khi gặp bất kỳ câu hỏi nào nói DoR là "required", "mandatory", "part of Scrum" hay "an artifact" — gần như chắc chắn đó là phương án sai. Khi câu hỏi nhấn mạnh quyền của Developers tự quyết nhận item — đó thường là hướng đúng.
Mẹo thực hành: Hãy coi DoR và DoD như cặp đôi đầu-cuối của một item. DoR canh ở cửa vào Sprint ("đủ rõ để bắt đầu chưa?"), DoD canh ở cửa ra ("đủ chất lượng để gọi là xong chưa?"). Chỉ DoD mới có hiệu lực ràng buộc trong Scrum.
Bài tập thực hành
Bài 1 — Phân biệt đúng/sai. Với mỗi phát biểu, ghi Đúng hay Sai và giải thích ngắn: a) "Scrum Guide định nghĩa Definition of Ready là commitment của Product Backlog." b) "Developers có thể kéo một PBI chưa đạt DoR vào Sprint nếu họ tự tin đạt Sprint Goal." c) "DoD là bắt buộc, DoR là optional." d) "Mọi item trong Product Backlog phải đạt DoR thì mới được nằm trong backlog."
Bài 2 — Thiết kế DoR. Cho bối cảnh đội mobile app fintech 5 người, hay bị tắc giữa Sprint vì thiếu thiết kế UI và thiếu tài khoản test. Hãy viết một DoR tối đa 4 tiêu chí, nhắm đúng vào hai vấn đề này. Giải thích vì sao bạn không thêm tiêu chí thứ 5.
Bài 3 — Tình huống xử lý. Đội bạn có DoR gồm 10 tiêu chí. Tốc độ đưa item vào Sprint chậm, PO than phiền mất quá nhiều thời gian làm tài liệu. Bạn là Scrum Master, sẽ đề xuất gì trong Retrospective sắp tới? Viết 3-4 ý.
Gợi ý đáp án Bài 1: a) Sai — DoR không có trong Scrum Guide. b) Đúng — Developers tự quản, DoR chỉ là guideline. c) Đúng. d) Sai — DoR chỉ liên quan tới việc kéo vào Sprint, không phải điều kiện tồn tại trong backlog.
Tóm tắt
Definition of Ready là một practice optional và hữu ích, không phải một phần chính thức của Scrum. Nó là checklist các tiêu chí giúp một Product Backlog Item đủ rõ ràng trước khi vào Sprint, qua đó giảm rủi ro tắc giữa chừng và làm Sprint Planning trơn tru hơn.
Điều quan trọng nhất cần ghi nhớ — đặc biệt cho kỳ thi PSPO I:
- DoR KHÔNG có trong Scrum Guide, KHÔNG bắt buộc, KHÔNG phải commitment. Chỉ có Product Goal, Sprint Goal và Definition of Done là ba commitment chính thức.
- DoD là bắt buộc; DoR là tùy chọn. Đừng nhầm lẫn cặp đôi đầu-cuối này.
- DoR phát huy giá trị khi nó tinh gọn (3-5 tiêu chí), do đội tự thỏa thuận, gắn với Refinement, và linh hoạt.
- DoR trở nên độc hại khi biến thành cổng quan liêu kiểu waterfall, bóp nghẹt empiricism và quyền tự quản của Developers.
- Developers, với tư cách Self-Managing Team, luôn có quyền quyết định nhận item vào Sprint — DoR chỉ là kim chỉ nam, không phải xiềng xích.