Mở đầu — vì sao bài này quan trọng
Hãy hình dung một buổi sáng thứ Hai đầu Sprint. Cả nhóm tập trung vào phòng họp, mọi người háo hức bắt tay làm việc. Nhưng đến khi kéo item đầu tiên ra để Sprint Planning, bạn — với vai trò Product Owner — phát hiện ra rằng tính năng "Cho phép thanh toán qua ví MoMo" thực ra chưa có ai xác nhận luồng hoàn tiền sẽ xử lý ra sao, chưa có ai biết MoMo trả về mã lỗi gì khi giao dịch thất bại, và bản thân Acceptance Criteria thì chỉ vỏn vẹn một dòng "Người dùng thanh toán được bằng MoMo". Kết quả: nửa buổi Planning trôi qua trong tranh luận, lập trình viên thì đoán mò, và đến giữa Sprint mọi thứ phải làm lại.
Đây chính là khoảnh khắc mà Definition of Ready (DoR) — Định nghĩa Sẵn Sàng — ra đời để giải quyết. Nếu Definition of Done (Bài 30) là cam kết về chất lượng đầu ra của một item, thì Definition of Ready là một bộ tiêu chí giúp nhóm trả lời câu hỏi: "Item này đã đủ rõ ràng để chúng ta dám đưa vào Sprint chưa?"
Có một điểm cực kỳ quan trọng mà tôi muốn bạn ghi nhớ ngay từ đầu, vì nó sẽ định hình toàn bộ cách bạn áp dụng công cụ này: Definition of Ready KHÔNG nằm trong Scrum Guide. Nó không phải là một artifact hay commitment chính thức của Scrum. Tuy nhiên, rất nhiều nhóm trong thực tế thấy nó hữu ích như một thỏa thuận làm việc (working agreement). Bài học này sẽ giúp bạn dùng DoR như một con dao sắc — đúng cách thì cắt gọn vấn đề, sai cách thì tự cắt vào tay mình.
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í mà một Product Backlog Item (PBI) cần thỏa mãn trước khi nhóm Developers cảm thấy đủ tự tin để đưa nó vào một Sprint. Nói cách khác, nó là một "checklist sàng lọc" ở cửa vào của Sprint Planning.
Mục đích cốt lõi của DoR là giảm thiểu sự mơ hồ và rủi ro. Một item "Ready" thường có nghĩa là:
- Nhóm hiểu rõ giá trị mà item mang lại (tại sao làm).
- Nhóm hiểu rõ phạm vi đủ để bắt đầu (làm cái gì).
- Các phụ thuộc (dependencies) lớn đã được nhận diện hoặc gỡ bỏ.
- Item đủ nhỏ để có thể hoàn thành trong một Sprint.
Các tiêu chí DoR thường gặp
Mỗi nhóm sẽ tự xây DoR riêng, nhưng có một số tiêu chí xuất hiện rất phổ biến. Tôi liệt kê kèm giải thích ngắn để bạn hiểu vì sao chúng có mặt:
- Acceptance Criteria (AC) viết rõ ràng: Tiêu chí nghiệm thu mô tả cụ thể khi nào item được coi là làm xong. Đây gần như là tiêu chí số một trong mọi DoR.
- Đã được ước lượng (Estimated): Nhóm đã estimate, và kích thước nằm trong ngưỡng chấp nhận được — ví dụ "≤ 8 story points" hoặc "≤ 1/2 capacity của một người trong Sprint". Item quá lớn là dấu hiệu chưa Ready.
- Đủ nhỏ để vừa một Sprint: Một item chiếm trọn cả Sprint của cả nhóm thường là rủi ro lớn và cần được tách nhỏ (xem Bài 32 — Story Splitting).
- Dependencies đã được nhận diện: Nếu item phụ thuộc API của đội khác, vào dữ liệu chưa có, hay quyết định pháp lý chưa xong — phải biết trước.
- Có thiết kế / wireframe nếu cần: Với những item liên quan UI, nhóm cần ít nhất phác thảo để hình dung.
- Đã được nhóm thảo luận trong Refinement: Item không phải lần đầu xuất hiện trong Planning mà đã được "chạm tay" qua trong các buổi Backlog Refinement.
Phân biệt DoR với DoD và Definition of Refined
Đây là chỗ học viên hay nhầm, nên tôi muốn làm rõ:
- Definition of Ready: kiểm tra item ở cửa vào Sprint — "đủ rõ để bắt đầu chưa?"
- Definition of Done: kiểm tra increment ở cửa ra — "đủ chất lượng để release chưa?" Đây là commitment chính thức trong Scrum.
Vì sao Scrum Guide cố tình không có DoR?
Một câu hỏi sâu sắc: nếu DoR hữu ích thế, sao Scrum Guide không đưa vào? Lý do nằm ở triết lý empirical (Bài 9). Scrum tin vào việc bắt đầu sớm và học hỏi qua thực nghiệm. Nếu DoR trở thành một bộ tiêu chí cứng nhắc, nó dễ biến thành một "cổng phê duyệt" (stage-gate) kiểu Waterfall — nơi item phải hoàn hảo 100% mới được làm. Điều đó giết chết tính linh hoạt. Vì vậy Scrum để DoR là tùy chọn, và trách nhiệm của PO là giữ nó ở mức "đủ tốt để bắt đầu", chứ không phải "hoàn hảo tuyệt đối".
Tình huống thực tế
Ví dụ 1: Sàn TMĐT "ShopViet" — DoR cứu một Sprint Planning hỗn loạn
ShopViet là một sàn thương mại điện tử giả định ở TP.HCM, nhóm Scrum gồm 6 Developers, Sprint 2 tuần. Trong quý trước, họ liên tục gặp tình trạng: trung bình mỗi Sprint có 2–3 item bị "kẹt" giữa chừng vì thiếu thông tin, làm velocity dao động từ 28 xuống 19 điểm.
PO tên Linh quyết định cùng nhóm xây một DoR đơn giản gồm 4 tiêu chí: (1) AC rõ ràng và testable, (2) đã estimate ≤ 8 điểm, (3) dependencies đã được nhận diện và ghi rõ, (4) nếu có UI thì phải có wireframe đính kèm.
Kết quả sau 3 Sprint: số item bị kẹt giữa Sprint giảm từ 2–3 xuống còn 0–1. Đáng chú ý là item "Tích hợp ví MoMo" — vốn từng gây tranh cãi — nay được Linh chủ động giữ lại ngoài Sprint thêm một tuần vì nó vi phạm tiêu chí số 3: chưa có xác nhận từ phía MoMo về luồng hoàn tiền. Nhờ vậy, khi item này vào Sprint sau, nhóm hoàn thành gọn gàng trong 4 ngày.
Bài học rút ra: DoR phát huy tác dụng lớn nhất với những item có rủi ro phụ thuộc bên ngoài. Nó cho PO một "lý do chính đáng" để nói "chưa" với một item chưa chín, thay vì đẩy rủi ro vào nhóm.
Ví dụ 2: Fintech "PayNgay" — khi DoR biến thành cái bẫy Waterfall
PayNgay là một startup fintech giả định ở Hà Nội. Sau khi đọc về DoR, một Scrum Master quá nhiệt tình đã xây một DoR gồm... 14 tiêu chí, bao gồm cả "đã có mockup high-fidelity được Giám đốc thiết kế duyệt", "đã có tài liệu kỹ thuật chi tiết", "đã được phân tích bảo mật đầy đủ".
Hậu quả: Product Backlog ùn ứ. Các item nằm chờ trung bình 3 Sprint mới đủ "Ready". Developers phàn nàn rằng họ "đói việc Ready" trong khi backlog thì đầy. Tệ hơn, vì mọi thứ phải hoàn hảo trước khi bắt đầu, nhóm mất luôn cơ hội học hỏi sớm — có item làm xong mockup cầu kỳ rồi mới phát hiện khách hàng không cần tính năng đó. Velocity thực tế giảm 30% so với trước khi áp dụng DoR.
Sau một buổi Retrospective căng thẳng, nhóm cắt DoR xuống còn 4 tiêu chí cốt lõi và thêm một nguyên tắc vàng: "DoR là hướng dẫn, không phải cổng kiểm soát. Nếu nhóm tự tin bắt đầu được, một tiêu chí chưa đủ không nên chặn item lại."
Bài học rút ra: DoR quá nặng còn tệ hơn không có DoR. Nó tạo ra hàng tồn kho (inventory) của các item "đang chờ Ready", trì hoãn giá trị, và lén lút đưa Waterfall trở lại.
Ví dụ 3: Đội outsource Đà Nẵng làm việc với khách Singapore — DoR như công cụ giao tiếp xuyên múi giờ
Một công ty phần mềm ở Đà Nẵng nhận dự án cho khách hàng tại Singapore. Chênh lệch múi giờ chỉ 1 tiếng, nhưng vấn đề lớn là PO phía khách (proxy PO) chỉ online được 2 tiếng mỗi ngày. Mỗi khi Developers gặp item mơ hồ giữa Sprint, họ phải chờ gần 24 giờ mới có câu trả lời — gây tắc nghẽn nghiêm trọng.
Nhóm đưa vào DoR một tiêu chí đặc thù: "Mọi item phải có phần Q&A đã được PO trả lời bằng văn bản trước Planning, và không còn câu hỏi mở (open question) nào ở mức blocker." Họ dùng một template trong Jira với mục "Open Questions" bắt buộc phải trống thì item mới được gắn nhãn Ready.
Kết quả: số lần Developers bị block để chờ PO trả lời giảm từ khoảng 5 lần/Sprint xuống còn 1 lần/Sprint. DoR ở đây không chỉ là checklist chất lượng mà còn là giao thức giao tiếp giúp nhóm phân tán làm việc trơn tru (chủ đề liên quan Bài 56 — Cross-cultural PO).
Bài học rút ra: DoR có thể được "may đo" theo bối cảnh cụ thể của nhóm. Với nhóm phân tán hoặc làm việc xuyên múi giờ, tiêu chí "không còn câu hỏi blocker" đáng giá hơn nhiều so với một nhóm ngồi cùng phòng.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên bạn dùng để xây và vận hành DoR cho nhóm của mình:
Bước 1 — Bắt đầu từ nỗi đau thật. Đừng copy DoR từ Internet. Hãy mở một buổi với nhóm và hỏi: "Những lần item bị kẹt giữa Sprint, nguyên nhân thường là gì?" Liệt kê 3–5 nguyên nhân phổ biến nhất. Đó chính là nguyên liệu cho DoR.
Bước 2 — Chọn tối đa 4–6 tiêu chí. Quy tắc của tôi: nếu DoR dài hơn một màn hình điện thoại, nó đã quá dài. Ưu tiên những tiêu chí giải quyết nỗi đau ở Bước 1. Hãy đảm bảo mỗi tiêu chí đều kiểm chứng được (ai cũng đồng ý là đạt hay chưa đạt), tránh những câu mơ hồ như "item đủ rõ ràng".
Bước 3 — Để cả nhóm đồng thuận, đặc biệt là Developers. DoR là thỏa thuận của nhóm, không phải mệnh lệnh của PO. Chính Developers — những người sẽ làm — phải đồng ý rằng các tiêu chí này khiến họ tự tin bắt đầu.
Bước 4 — Gắn DoR vào Backlog Refinement, không phải Sprint Planning. DoR phải được "đạt" trong các buổi Refinement diễn ra trước đó (Bài 18, Bài 53). Nếu bạn dùng DoR để sàng lọc ngay tại Planning thì đã muộn — bạn sẽ thiếu item Ready để lập kế hoạch.
Bước 5 — Làm cho trạng thái Ready hiển thị rõ. Dùng một label, một cột trên Kanban, hoặc một trường tùy chỉnh trong Jira/Azure DevOps để ai cũng thấy item nào đã Ready. Sự minh bạch này giúp nhóm chủ động "nuôi" đủ item Ready trước mỗi Sprint.
Bước 6 — Định kỳ thanh lọc DoR trong Retrospective. Mỗi vài Sprint, hỏi: "Tiêu chí nào trong DoR đang cản trở mà không tạo giá trị?" Nếu một tiêu chí chưa từng giúp ích, hãy mạnh dạn bỏ. DoR là tài liệu sống, không phải bia đá.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến DoR thành cổng phê duyệt cứng nhắc. Như ví dụ PayNgay, khi DoR yêu cầu mọi thứ hoàn hảo, bạn vô tình tái lập Waterfall. Mẹo: thêm nguyên tắc "DoR là hướng dẫn, không phải rào chắn tuyệt đối" và cho phép nhóm linh hoạt với những item đặc biệt.
Lỗi 2 — Nhầm DoR là bắt buộc trong Scrum. Tôi nhắc lại lần nữa vì rất hay gặp trong các kỳ thi và phỏng vấn: DoR không có trong Scrum Guide. Nếu ai đó nói "Scrum bắt buộc phải có DoR", họ đã sai. (Lưu ý này quan trọng cho Bài 57 — PSPO I Exam Preparation.)
Lỗi 3 — DoR quá dài. Một DoR 12–15 tiêu chí gần như chắc chắn sẽ tạo tồn kho item chờ đợi. Mẹo: giới hạn ở 4–6 tiêu chí cốt lõi.
Lỗi 4 — Dùng DoR để đổ lỗi. Khi item lỗi giữa Sprint, một số nhóm dùng DoR như vũ khí: "Tại item này chưa đủ Ready, lỗi của PO." DoR không phải để chỉ tay. Nó là công cụ học hỏi tập thể.
Lỗi 5 — Để DoR đứng im. Một DoR viết một lần rồi quên trong wiki suốt một năm là DoR chết. Hãy đưa nó ra Retrospective định kỳ.
Mẹo nâng cao: Hãy nghĩ về DoR và DoD như một cặp. Nếu item "Ready" mà DoD vẫn liên tục bị miss, có thể vấn đề không nằm ở cửa vào mà ở năng lực nhóm hay quy trình. Đừng giải quyết mọi vấn đề bằng cách siết DoR.
Bài tập thực hành
- Tự đánh giá: Lấy một Product Backlog Item gần nhất mà nhóm bạn từng làm bị kẹt giữa Sprint. Viết ra 3 thông tin nào nếu có sẵn từ đầu sẽ giúp item đó không bị kẹt. Đây là phôi của DoR cho nhóm bạn.
- Soạn thảo DoR: Dựa trên kết quả bài 1, viết một DoR gồm tối đa 5 tiêu chí. Mỗi tiêu chí phải kiểm chứng được — hãy tự hỏi "hai người khác nhau nhìn vào có đồng ý đạt/không đạt không?"
- Phân biệt khái niệm: Cho 5 phát biểu sau, hãy xếp mỗi cái vào DoR hay DoD: (a) "Đã viết unit test và pass"; (b) "Acceptance Criteria đã rõ ràng"; (c) "Code đã được review"; (d) "Dependencies đã được nhận diện"; (e) "Đã deploy lên staging". (Đáp án gợi ý: a, c, e thuộc DoD; b, d thuộc DoR.)
- Tình huống phản biện: Sếp bạn yêu cầu "mọi item phải có tài liệu thiết kế chi tiết được duyệt mới được vào Sprint". Hãy viết 3–4 câu phản biện, giải thích vì sao tiêu chí này có thể gây hại và đề xuất phiên bản nhẹ hơn.
Tóm tắt
Definition of Ready là một bộ tiêu chí giúp nhóm quyết định khi nào một item đủ rõ ràng để đưa vào Sprint. Nó không phải thành phần chính thức của Scrum Guide, nhưng rất nhiều nhóm thấy hữu ích như một thỏa thuận làm việc — đặc biệt với những item có rủi ro phụ thuộc hoặc nhóm làm việc phân tán.
Các tiêu chí phổ biến gồm: AC rõ ràng và testable, đã được ước lượng và đủ nhỏ (ví dụ ≤ 8 điểm), dependencies đã nhận diện, có wireframe khi cần, và đã được thảo luận trong Refinement.
Ranh giới mỏng manh nằm ở chỗ: DoR vừa đủ thì giúp nhóm tự tin và giảm rủi ro; DoR quá nặng thì biến thành cổng Waterfall, tạo tồn kho item chờ đợi và trì hoãn giá trị. Hãy giữ DoR ngắn (4–6 tiêu chí), gắn nó vào Refinement chứ không phải Planning, để cả nhóm đồng thuận, và định kỳ thanh lọc trong Retrospective. Dùng đúng cách, DoR là một con dao sắc giúp PO bảo vệ cả nhóm khỏi những Sprint hỗn loạn.