Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng một buổi Sprint Planning quen thuộc: cả team ngồi vào phòng họp, Product Owner mở backlog ra, chọn một story và nói "Cái này làm trong sprint tới nhé". Lập tức một developer hỏi: "Story này áp dụng cho cả khách lẻ và khách doanh nghiệp à?" — PO ngập ngừng. Một bạn khác hỏi: "Acceptance criteria đâu rồi anh?" — chưa có. Bạn QA tiếp lời: "Cái màn hình này design xong chưa?" — design đang vẽ dở. Thế là buổi Planning biến thành buổi refinement bất đắc dĩ, kéo dài gấp đôi thời gian, và team vẫn cam kết một story mà chính họ còn chưa hiểu rõ.
Đây chính là vấn đề mà Definition of Ready (DoR) — Định nghĩa "Sẵn sàng" — sinh ra để giải quyết. DoR là một checklist các điều kiện mà một Product Backlog Item cần thỏa mãn trước khi nó đủ tư cách được đưa vào một Sprint. Nói nôm na, nó là "cửa kiểm soát chất lượng đầu vào" cho công việc của team.
Nhưng — và đây là lý do tiêu đề bài này có chữ "Tool with caveats" (công cụ kèm cảnh báo) — DoR là một trong những công cụ dễ bị lạm dụng nhất trong toolbox của một Scrum Master. Dùng đúng, nó giúp team tránh lãng phí và thất vọng. Dùng sai, nó trở thành một cái cổng quan liêu (bureaucratic gate), biến Scrum linh hoạt thành một dây chuyền kiểu waterfall trá hình. Vì vậy, bài học này không chỉ dạy bạn cách làm một DoR, mà quan trọng hơn, dạy bạn khi nào nên dùng, khi nào nên buông, và làm sao để DoR phục vụ team chứ không trói buộc team.
Khái niệm cốt lõi
DoR là gì và không là gì
DoR là một thỏa thuận của team về việc: "Một item như thế nào thì chúng ta đủ tự tin để bắt tay vào làm?" Nó thường được biểu diễn dưới dạng một checklist ngắn gọn.
Một ví dụ DoR điển hình:
- [ ] Item được viết theo định dạng User Story (As a... I want... so that...) hoặc có mô tả rõ giá trị mong muốn.
- [ ] Đã có Acceptance Criteria (tiêu chí chấp nhận) được viết rõ ràng.
- [ ] Đủ nhỏ để hoàn thành trong một Sprint.
- [ ] Đã được team estimate (ước lượng).
- [ ] Các phụ thuộc (dependencies) đã được xác định và không bị chặn.
- [ ] Design/mockup (nếu cần) đã sẵn sàng.
- [ ] Team đã hiểu và không còn câu hỏi lớn nào chưa được giải đáp.
Phân biệt DoR và DoD — đừng nhầm lẫn
Đây là điểm hay gây rối cho người mới:
| Definition of Ready | Definition of Done | |
|---|---|---|
| Áp dụng cho | Item trước khi vào Sprint | Increment khi hoàn thành |
| Trả lời câu hỏi | "Đã đủ rõ để bắt đầu chưa?" | "Đã đủ chất lượng để release chưa?" |
| Trong Scrum Guide | Không bắt buộc | Bắt buộc |
| Rủi ro khi lạm dụng | Cao (thành cổng quan liêu) | Thấp |
Vì sao DoR là "con dao hai lưỡi"
Mục đích đẹp đẽ ban đầu của DoR là giảm lãng phí: team không nên bắt đầu làm một thứ mơ hồ rồi giữa sprint mới phát hiện thiếu thông tin, phải dừng lại, chờ đợi, làm lại. DoR giúp đẩy phần "làm rõ" về phía Refinement, nơi nó thuộc về.
Nhưng cái bẫy là: khi DoR trở thành một danh sách quá dài, quá cứng nhắc, nó tạo ra hai tác hại lớn.
Thứ nhất, DoR có thể trở thành cái cớ để đẩy việc qua lại như bóng. PO ném story sang team, team nói "chưa đủ DoR, trả lại", PO bực bội ném lại... Thay vì cùng nhau làm rõ trong tinh thần hợp tác, hai bên biến DoR thành ranh giới phòng thủ.
Thứ hai, DoR tạo ra một "mini-waterfall". Nếu DoR yêu cầu mọi thứ phải hoàn hảo trước khi bắt đầu — design xong 100%, mọi câu hỏi được trả lời, mọi cạnh đều được lường trước — thì bạn đã giết chết tinh thần "thanh tra và thích nghi" của Scrum. Nhiều câu hỏi tốt nhất chỉ nảy sinh khi team thực sự bắt tay vào làm. DoR cứng nhắc bắt team phải biết tất cả trước khi làm, điều đó phi thực tế và phản Agile.
Vì vậy nguyên tắc vàng là: DoR nên là một "guideline" (kim chỉ nam), không phải một "gate" (cánh cổng cứng). Nó là lời nhắc, không phải hợp đồng pháp lý.
Tình huống thực tế
Tình huống 1 — Tiki: DoR cứu một team khỏi vòng lặp lãng phí
Một team phát triển tính năng thanh toán tại một công ty thương mại điện tử lớn ở Việt Nam (tạm gọi theo bối cảnh Tiki) gặp tình trạng kinh điển: trong 3 sprint liên tiếp, trung bình mỗi sprint có 2 story phải "carry over" (kéo sang sprint sau) vì lý do giống nhau — bắt đầu làm mới phát hiện thiếu thông tin. Có story làm được 2 ngày thì khựng lại vì chưa rõ luồng hoàn tiền cho đơn hàng quốc tế; có story chờ design màn hình mất 3 ngày giữa sprint.
Scrum Master tổ chức một retro tập trung vào vấn đề này, và team quyết định thử một DoR tối giản gồm đúng 4 mục: (1) có acceptance criteria, (2) design sẵn sàng nếu có UI, (3) dependencies đã rõ, (4) team đã estimate và không còn câu hỏi chặn.
Kết quả sau 4 sprint: tỷ lệ carry-over giảm từ trung bình 2 story/sprint xuống còn 0.5. Quan trọng hơn, các câu hỏi như "luồng hoàn tiền quốc tế" giờ được nêu ra trong buổi Refinement — sớm hơn cả tuần — thay vì giữa sprint.
Bài học rút ra: DoR phát huy tác dụng nhất khi nó được sinh ra từ chính nỗi đau của team (qua retro), nhắm đúng vào nguyên nhân lặp lại, và đủ ngắn để không ai phải tra cứu. DoR không phải thứ áp từ trên xuống — nó là thỏa thuận của team.
Tình huống 2 — Một startup fintech ở TP.HCM: DoR biến thành cổng quan liêu
Một startup fintech khoảng 40 người tại TP.HCM có một Delivery Manager mới về, vốn xuất thân từ môi trường outsourcing kiểu waterfall. Anh ấy ban hành một DoR gồm 14 mục, trong đó có những yêu cầu như "phải có tài liệu thiết kế kỹ thuật chi tiết được duyệt", "phải có test case viết sẵn", "phải được kiến trúc sư phê duyệt".
Hậu quả xảy ra nhanh chóng. Backlog ùn ứ vì rất ít story "đủ điều kiện" vào sprint. PO phải dành phần lớn thời gian viết tài liệu thay vì làm việc với khách hàng. Tệ hơn, mỗi Sprint Planning biến thành một phiên "soi DoR": developer chỉ tay vào checklist nói "mục số 9 chưa đạt, không nhận". Tinh thần hợp tác bốc hơi. Velocity thực tế giảm 30% trong hai tháng vì lượng story sẵn sàng quá ít, dù chất lượng từng story có cao hơn chút.
Scrum Master (một bạn được thuê coaching ngoài) đã can thiệp bằng cách đưa cả team vào một retro và đặt một câu hỏi sắc bén: "Trong 14 mục này, mục nào thực sự ngăn được một lỗi mà chúng ta đã từng gặp?" Cả nhóm rà soát và phát hiện chỉ có 5 mục từng thực sự cứu họ. 9 mục còn lại là "phòng xa" theo bản năng waterfall. Họ cắt DoR xuống còn 5 mục và đổi cách diễn đạt từ "bắt buộc phải có" sang "thông thường nên có — nếu thiếu thì cùng bàn".
Bài học rút ra: Một DoR dài chưa chắc tốt hơn. Mỗi mục trong DoR đều có "chi phí" — nó làm chậm dòng chảy công việc. Hãy chỉ giữ lại những mục đã chứng minh được giá trị qua kinh nghiệm thực tế. Và đặc biệt: ngôn ngữ của DoR nên là ngôn ngữ hợp tác ("cùng bàn"), không phải ngôn ngữ pháp lý ("bắt buộc, nếu không thì trả lại").
Tình huống 3 — Team Grab khu vực Đông Nam Á: bỏ DoR khi đã trưởng thành
Một team backend tại một công ty công nghệ vận tải lớn ở Đông Nam Á (bối cảnh kiểu Grab) đã dùng DoR khoảng một năm và rất hiệu quả ở giai đoạn đầu, khi team còn mới và PO chưa quen viết yêu cầu rõ ràng. Sau một năm, văn hóa refinement của họ đã chín muồi: việc làm rõ story trở thành phản xạ, mọi người tự động hỏi đúng câu hỏi, design và dependencies luôn được xử lý sớm một cách tự nhiên.
Trong một retro, một developer kỳ cựu nêu: "Đã 6 sprint rồi chúng ta chưa bao giờ reject một story vì DoR. Vậy DoR còn cần thiết không, hay nó chỉ là một bước kiểm tra hình thức?" Sau khi thảo luận, team quyết định "tốt nghiệp" khỏi DoR như một checklist chính thức, và chuyển nó thành một nguyên tắc chung không thành văn: "Chỉ kéo vào sprint những thứ chúng ta thực sự hiểu."
Bài học rút ra: DoR là một "cây nạng" (scaffolding). Nạng rất hữu ích khi chân còn yếu, nhưng khi đã đi vững thì nạng trở thành vướng. Một dấu hiệu trưởng thành của team là khi họ không còn cần DoR thành văn nữa, vì chất lượng đầu vào đã trở thành thói quen. Scrum Master giỏi biết khi nào nên gỡ giàn giáo.
Hướng dẫn từng bước
Nếu bạn quyết định team mình cần một DoR, đây là cách triển khai sao cho lành mạnh:
Bước 1 — Xác định xem có thực sự cần DoR không. Đừng tạo DoR chỉ vì "sách bảo thế". Hãy nhìn vào dữ liệu: team có thường xuyên carry-over vì thiếu thông tin không? Có hay phải dừng giữa sprint để chờ làm rõ không? Nếu câu trả lời là "không", có thể team chưa cần DoR. Nếu "có", DoR là một ứng viên đáng thử.
Bước 2 — Cùng team đồng sáng tạo, đừng áp đặt. Tổ chức một workshop ngắn (30–45 phút). Đặt câu hỏi: "Một story như thế nào thì chúng ta tự tin bắt tay làm ngay?" và "Những lần phải dừng giữa sprint, thường là vì thiếu cái gì?" Để chính team viết ra DoR. DoR áp từ trên xuống gần như chắc chắn thất bại.
Bước 3 — Giữ nó ngắn. Nhắm tới 4–6 mục. Mỗi mục phải vượt qua bài kiểm tra: "Mục này đã từng thực sự cứu chúng ta khỏi một rắc rối chưa?" Nếu chỉ là "phòng xa cho chắc", hãy loại bỏ.
Bước 4 — Dùng ngôn ngữ hướng dẫn, không phải pháp lý. Viết "thông thường một story sẵn sàng sẽ có..." thay vì "story BẮT BUỘC phải có... nếu không sẽ bị từ chối". Sự khác biệt về sắc thái này quyết định DoR là công cụ hợp tác hay vũ khí phòng thủ.
Bước 5 — Đặt nó ở nơi dễ thấy. Dán DoR lên tường phòng họp hoặc ghim trên board (Jira/Trello). Mục đích là để nhắc nhở trong Refinement, không phải để tra cứu khi tranh cãi.
Bước 6 — Áp dụng tinh thần linh hoạt với ngoại lệ. Đôi khi một story khẩn cấp (ví dụ một bug production nghiêm trọng) chưa thỏa DoR nhưng vẫn phải làm ngay. DoR phải cho phép ngoại lệ một cách có ý thức — team cùng quyết định "lần này ta phá lệ vì lý do X". Một DoR không bao giờ được phép phá lệ là một DoR đã chết cứng.
Bước 7 — Định kỳ rà soát trong retro. Mỗi vài sprint, hỏi: "DoR có còn giúp ích không? Mục nào thừa? Mục nào thiếu? Chúng ta còn cần nó không?" 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 cứng. Đây là lỗi nguy hiểm nhất. Khi DoR thành "gate", nó tạo ra văn hóa đổ lỗi và đẩy việc. Mẹo: Luôn ưu tiên đối thoại trên checklist. Khi một story thiếu thông tin, phản ứng đúng là "ngồi xuống làm rõ cùng nhau", không phải "trả lại PO".
Lỗi 2 — DoR quá dài. Checklist 10+ mục làm nghẽn dòng chảy. Mẹo: Quy tắc ngón tay cái — nếu vượt quá 6 mục, hãy nghi ngờ. Mỗi mục đều có chi phí về tốc độ.
Lỗi 3 — Yêu cầu sự hoàn hảo trước khi bắt đầu (mini-waterfall). DoR đòi "design hoàn chỉnh 100%, mọi câu hỏi được trả lời" giết chết tính thích nghi. Mẹo: Chấp nhận rằng "đủ rõ để bắt đầu" khác với "rõ hết mọi thứ". Một số khám phá chỉ đến khi làm.
Lỗi 4 — Áp DoR từ trên xuống. Sếp/manager ban hành DoR cho team. Mẹo: DoR không phải của bạn (Scrum Master), không phải của manager — nó là của team. Hãy facilitate để team tự tạo.
Lỗi 5 — Nhầm DoR với DoD. Nhiều người mới gộp hai khái niệm. Mẹo: Nhớ câu thần chú — DoR là cổng vào sprint (đủ rõ để bắt đầu), DoD là cổng ra (đủ chất lượng để release).
Lỗi 6 — Để DoR thành tài liệu chết. Viết một lần rồi không bao giờ nhìn lại. Mẹo: Đưa DoR vào danh sách rà soát định kỳ trong retro. Sẵn sàng cắt giảm hoặc xóa bỏ khi team trưởng thành.
Mẹo nâng cao cho bối cảnh Việt Nam: Trong nhiều môi trường outsourcing/gia công ở Việt Nam, văn hóa "làm theo spec" và tâm lý sợ sai khiến team dễ trượt về DoR kiểu waterfall nặng nề. Là Scrum Master, bạn cần đặc biệt cảnh giác với xu hướng này. Một cách hữu hiệu là thường xuyên hỏi "mục này giúp gì cho chúng ta?" để giữ DoR tinh gọn, và nhấn mạnh tinh thần hợp tác giữa PO và Dev thay vì ranh giới trách nhiệm.
Bài tập thực hành
Bài tập 1 — Audit DoR hiện tại (nếu có). Nếu team bạn đang có DoR, hãy liệt kê từng mục và với mỗi mục, trả lời: "Mục này đã từng thực sự ngăn được một rắc rối cụ thể nào chưa? Hãy kể ra một ví dụ." Mục nào không kể được ví dụ → đánh dấu là ứng viên để loại bỏ. Mục tiêu: cắt DoR xuống còn tối đa 6 mục đã chứng minh giá trị.
Bài tập 2 — Thiết kế DoR từ nỗi đau. Nhìn lại 3 sprint gần nhất của team bạn (hoặc một team giả định). Liệt kê tất cả các lần một story phải dừng giữa chừng hoặc carry-over vì thiếu thông tin. Nhóm các nguyên nhân lại. Từ đó, viết ra một DoR 4–5 mục nhắm thẳng vào những nguyên nhân lặp lại nhất. Lưu ý: viết bằng ngôn ngữ hướng dẫn, không phải ngôn ngữ bắt buộc.
Bài tập 3 — Đóng vai xử lý xung đột. Tình huống: PO mang một story khẩn cấp vào Planning nhưng chưa có acceptance criteria. Một developer nói "không đạt DoR, không nhận". Hãy viết ra cách bạn — với vai trò Scrum Master — sẽ facilitate cuộc đối thoại này, sao cho vừa tôn trọng DoR vừa không biến nó thành rào cản cứng. Gợi ý: hướng tới việc cùng làm rõ tại chỗ hoặc cùng quyết định một ngoại lệ có ý thức.
Bài tập 4 — Suy ngẫm về sự trưởng thành. Tự đánh giá: team bạn đã sẵn sàng "tốt nghiệp" khỏi DoR chưa? Trả lời: trong N sprint gần nhất, đã bao nhiêu lần DoR thực sự chặn được một story chưa sẵn sàng? Nếu con số gần bằng 0 và refinement đã thành thói quen, hãy cân nhắc thảo luận với team về việc chuyển DoR thành nguyên tắc không thành văn.
Tóm tắt
Definition of Ready là một checklist các điều kiện mà một backlog item nên thỏa mãn trước khi được kéo vào Sprint — giúp team tránh bắt đầu công việc mơ hồ rồi mắc kẹt giữa chừng. Đây là công cụ hữu ích, nhưng đi kèm cảnh báo rõ ràng:
- DoR không phải artifact bắt buộc trong Scrum Guide (khác với DoD). Bạn có quyền dùng, sửa, hoặc bỏ nó.
- DoR nên là kim chỉ nam, không phải cánh cổng cứng. Khoảnh khắc nó trở thành công cụ đẩy việc và đổ lỗi giữa PO và Dev là khoảnh khắc nó phản tác dụng.
- Giữ nó ngắn (4–6 mục), do team đồng sáng tạo, dùng ngôn ngữ hợp tác, và cho phép ngoại lệ có ý thức.
- Cảnh giác với mini-waterfall: "đủ rõ để bắt đầu" không có nghĩa là "biết hết mọi thứ".
- DoR là giàn giáo. Team trưởng thành có thể "tốt nghiệp" khỏi nó khi chất lượng đầu vào đã thành thói quen.