Backlog Refinement

Đây là hoạt động ăn tiền nhất của BA trong một team Scrum, và cũng là hoạt động dễ bị cắt bỏ nhất khi dự án gấp. Refinement là việc bóc dần những item đang nằm ở giữa Product Backlog: làm rõ nghiệp vụ, chẻ nhỏ, thêm acceptance criteria, ước lượng, đôi khi phát hiện ra item đó chẳng còn cần thiết nữa.

Một lưu ý về tên gọi: ngày trước người ta gọi là Backlog Grooming. Từ này đã bị bỏ khỏi Scrum Guide từ lâu vì mang nghĩa xấu trong tiếng Anh, và thay bằng Refinement. Nếu đồng nghiệp vẫn nói "grooming", họ không sai về ý, chỉ là đang dùng cách gọi cũ.

Refinement không phải là một trong năm event của Scrum. Nó là hoạt động chạy suốt sprint, không cố định lịch, không có timebox chính thức.

Ai làm, làm lúc nào

Developers là người chịu trách nhiệm chính về việc chẻ nhỏ và ước lượng, với sự tham gia của Product Owner. BA thường là người chuẩn bị nội dung trước, đi hỏi nghiệp vụ, dựng luồng, viết nháp acceptance criteria.

Scrum Guide không quy định thời lượng. Con số thường được nhắc trong cộng đồng là không quá 10% dung lượng của team, tức khoảng 4 giờ mỗi tuần cho một team 8 người. Đó là chỉ dẫn tham khảo, không phải luật.

Hai cách tổ chức phổ biến:

• Buổi cố định. Một buổi 60 đến 90 phút giữa sprint, cả team dự. Dễ giữ nhịp, nhưng dễ dài dòng nếu không chuẩn bị.
• Rải rác theo nhu cầu. BA và PO chuẩn bị trước, kéo 2 đến 3 dev liên quan bàn 20 phút cho từng nhóm item. Linh hoạt hơn, hợp team đã quen việc.

Trong buổi refinement làm gì

1. PO nói mục tiêu sản phẩm sắp tới, để cả team hiểu vì sao mấy item này được đưa lên.
2. Đi qua từng item: làm rõ nghiệp vụ, chốt phạm vi, viết acceptance criteria.
3. Chẻ item to. Story trên 13 điểm gần như luôn chẻ được, thường theo luồng nghiệp vụ, theo loại người dùng, hoặc theo trường hợp đơn giản trước phức tạp sau.
4. Ước lượng.
5. Đánh dấu item nào cần đi hỏi thêm và ai phụ trách đi hỏi.

Việc số 5 hay bị quên, và đó là lý do sprint sau vẫn thiếu thông tin y như cũ.

Ví dụ thực tế

Item nằm trong backlog của một hệ thống bán vé rạp phim, viết đúng một dòng: "Áp dụng khuyến mãi khi mua vé." Chuỗi có 14 cụm rạp, và không ai thấy dòng đó có gì đáng bàn.

Ba mươi phút refinement lôi ra được những thứ này: có 4 loại khuyến mãi đang chạy ngoài đời (mã giảm giá, thẻ thành viên, combo bắp nước, ưu đãi ngân hàng), chúng có thể cộng dồn theo quy tắc riêng, và bên marketing đang chốt quy tắc mới cho quý sau.

Item ban đầu ước lượng thô cỡ 20 điểm, được chẻ thành 5 story, làm rải qua hai sprint. Story đầu tiên chỉ xử lý mã giảm giá đơn lẻ, không cộng dồn — 5 điểm, đủ để chạy thí điểm ở 2 cụm rạp và đo xem quy tắc cộng dồn có thật sự cần gấp không.

Nếu không refine, item 20 điểm này rơi thẳng vào Sprint Planning và cả buổi họp sẽ trôi vì bàn quy tắc khuyến mãi.

Giữ backlog ở trạng thái nào là đủ

Cách hình dung quen dùng: backlog như một cái phễu.

Refine quá sâu cho những thứ còn xa là lãng phí, vì tới lúc làm thì bối cảnh đã đổi. Refine quá nông thì sprint nào cũng phải phân tích gấp.

Lỗi hay gặp

• Cắt refinement khi dự án gấp. Sprint sau sẽ trả giá gấp đôi.
• Kéo cả 9 người ngồi 2 tiếng để bàn một item chỉ liên quan tới 3 người.
• Refine mà không ai ghi lại kết quả, tuần sau bàn lại từ đầu.
• Chỉ ước lượng, không làm rõ nghiệp vụ. Buổi đó thành phiên chấm điểm.
• BA đến buổi refinement với tờ giấy trắng. Chuẩn bị trước 30 phút tiết kiệm cho cả team 1 tiếng.