Definition of Ready(DoR)
Bộ điều kiện tối thiểu để một hạng mục backlog được đưa vào sprint: đủ rõ, đủ nhỏ, có acceptance criteria, không còn phụ thuộc chặn. Không nằm trong Scrum Guide.
Định nghĩa
Story được kéo vào sprint, dev đọc xong ngẩng lên hỏi một câu mà không ai trả lời được. "Cho phép khách hàng đổi lịch giao hàng" — đổi được mấy lần? Đổi chậm nhất bao lâu trước giờ giao? Có tính phí không? BA nói để hỏi lại khách.
Thế là hết buổi planning, và story đó vẫn nằm đấy. Definition of Ready tồn tại để chặn đúng tình huống này: một bộ điều kiện tối thiểu mà item phải đạt trước khi được phép vào sprint.
Nói ngay cho rõ: DoR không có trong Scrum Guide, cả bản 2017 lẫn 2020. Đây là thực hành do cộng đồng đặt ra. Nhiều người trong giới Agile phản đối nó khá gay gắt, và họ có lý do đáng nghe, sẽ nói ở phần dưới.
DoR là bộ lọc để buổi planning không biến thành buổi phân tích yêu cầu. Nó là thói quen làm việc, không phải luật của Scrum.
Một DoR gọn gàng
Team thường dùng 5 đến 7 tiêu chí, kiểm ở cuối buổi refinement:
- Story viết theo dạng ai, muốn gì, để làm gì. Người ngoài team đọc hiểu được.
- Có acceptance criteria, tối thiểu bao gồm luồng chính và một trường hợp lỗi rõ ràng.
- Đã ước lượng và kích cỡ vừa một sprint. Trên 13 điểm thì trả về chẻ tiếp.
- Nếu có giao diện thì đã có wireframe hoặc bản Figma được chốt.
- Không còn phụ thuộc nào đang chặn: API bên thứ ba đã sẵn, quyền truy cập đã cấp, dữ liệu mẫu đã có.
- Đã xác định cách kiểm thử, ai kiểm và trên môi trường nào.
- Đã nêu rõ cần dữ liệu chuyển đổi hay không nếu đụng tới hệ thống cũ.
Không phải story nào cũng cần đủ bảy dòng. Story sửa nhãn nút không cần wireframe. DoR nên đọc như danh sách gợi nhắc, không như biểu mẫu ký duyệt.
Vì sao nhiều người phản đối DoR
Lý lẽ chính: DoR dễ biến thành cửa ải. Khi phải đạt đủ tiêu chí mới được vào sprint, team bắt đầu làm hết phần phân tích trước, và nhịp làm việc trượt dần về kiểu thác nước chia nhỏ. Tệ hơn, nó tạo cớ để Developers từ chối trao đổi: "story chưa đạt DoR, chưa làm được", trong khi năm phút nói chuyện với PO là đủ để bắt đầu.
Cách dùng lành mạnh: xem DoR là mục tiêu chung của cả team, chứ không phải hợp đồng giữa PO và Developers.
| Tình huống | DoR dùng lành mạnh | DoR biến thành cửa ải |
|---|---|---|
| Item thiếu một chi tiết nhỏ | Hỏi PO 5 phút rồi làm | Trả về backlog, chờ sprint sau |
| Ai kiểm tiêu chí | Cả team cùng soi ở refinement | PO trình, Developers duyệt |
| Khi tiêu chí cản trở | Team sửa lại DoR | Giữ nguyên vì đã ban hành |
Ví dụ thực tế
Trước khi có DoR, một team 6 người làm phần mềm quản lý đơn hàng cho xưởng in bao bì trung bình mỗi sprint có 3 story treo giữa chừng vì thiếu thông tin, phải chờ bên khách trả lời từ 2 đến 5 ngày.
Team đưa vào một DoR năm dòng, kiểm ở buổi refinement giữa sprint. Điều kiện gắt nhất là dòng số 5 về phụ thuộc: story nào cần thông tin từ phía xưởng thì phải có câu trả lời bằng văn bản trước, dù chỉ là một tin nhắn được chụp lại dán vào Jira.
Sau bốn sprint, số story treo giữa chừng xuống còn trung bình 0,75 mỗi sprint. Đổi lại, buổi refinement dài thêm khoảng 30 phút và BA phải chủ động đuổi theo khách sớm hơn một tuần. Đó là cái giá phải trả, và team thấy đáng.
Lỗi hay gặp
- Biến DoR thành 12 tiêu chí, có cả ô ký duyệt. Không story nào đạt nổi, mọi người bỏ qua luôn.
- Dùng DoR để đá trách nhiệm: Developers từ chối mọi story chưa hoàn hảo, PO thì bảo phải vào sprint mới biết chi tiết. Cả hai đều đang né việc nói chuyện với nhau.
- Yêu cầu thiết kế chi tiết đến từng pixel cho mọi story, kể cả story chỉ sửa logic phía sau.
- Nhầm DoR với Definition of Done. Một cái gác cửa vào, một cái gác cửa ra.
Bắt đầu bằng ba dòng thôi: story viết theo dạng ai-muốn-gì-để-làm-gì, có acceptance criteria kèm một ca lỗi, và không còn thứ gì đang chặn. Chạy bốn sprint rồi hẵng bàn có cần thêm dòng nào không. Phần lớn team không cần.
