Product Backlog

Chỗ chứa mọi thứ có thể cần làm cho một sản phẩm, xếp thành danh sách có thứ tự từ trên xuống. Nghe đơn giản, nhưng hai chữ "có thứ tự" mới là phần khó: Scrum Guide dùng từ ordered, tức xếp tuyến tính, chứ không phải gắn nhãn High/Medium/Low. Ba mươi item cùng mức High thì không ai biết mai làm cái nào.

Product Backlog là danh sách xếp thứ tự duy nhất cho biết team làm gì tiếp theo. Có hai danh sách song song, hoặc có một danh sách mà không ai dám xếp thứ tự, thì coi như chưa có backlog.

Theo Scrum Guide 2020

Scrum có ba artifact: Product Backlog, Sprint Backlog, Increment. Mỗi artifact đi kèm một commitment — phần mới của bản 2020 và cũng là phần hay bị bỏ qua.

• Commitment của Product Backlog là Product Goal: mục tiêu dài hạn mô tả sản phẩm sẽ trở thành cái gì. Tại một thời điểm chỉ có một Product Goal. Đạt được hoặc quyết định bỏ, rồi mới đặt cái tiếp theo.
• Product Owner chịu trách nhiệm về nội dung backlog, thứ tự các item và việc mọi người hiểu được chúng. PO có thể giao việc soạn cho người khác, ở Việt Nam thường là BA, nhưng trách nhiệm vẫn nằm ở PO.
• Ai cũng được đề xuất item: dev, QC, sale, chăm sóc khách hàng, khách hàng cuối. Chỉ PO quyết định item có được nhận vào và nằm ở vị trí nào. Muốn đẩy việc lên trước thì đi thuyết phục PO, đừng nhắn riêng cho dev.

Thực tế ở nhiều công ty lệch chuẩn đúng chỗ này: "PO" chỉ ngồi viết story, còn thứ tự do trưởng phòng kinh doanh gọi điện quyết. Lúc đó tên gọi vẫn là Scrum nhưng cơ chế đã khác.

Một item gồm những gì

Scrum Guide nêu ba thuộc tính: mô tả, thứ tự, kích cỡ. Không bắt buộc viết theo dạng user story — một câu mô tả, một use case, một ảnh chụp màn hình lỗi đều hợp lệ.

Ngoài đời mỗi item còn có thêm acceptance criteria, loại item (story, bug, spike, nợ kỹ thuật), epic cha, link Figma hoặc Confluence, người đề xuất và ngày đề xuất. Hai trường cuối rẻ tiền mà cực hữu ích lúc dọn backlog hai năm sau.

Độ chi tiết giảm dần theo chiều dọc. Item ở 20 dòng đầu phải nhỏ, rõ, có AC, ước lượng được. Item ở dòng 300 chỉ cần một tiêu đề đọc hiểu là đủ — viết kỹ nó bây giờ phần lớn là công đổ đi.

Refinement giữ cho danh sách còn sống

Backlog không tự gọn. Việc bóc dần item ở tầng giữa — làm rõ nghiệp vụ, chẻ nhỏ, thêm AC, ước lượng — chạy rải rác suốt sprint chứ không phải một buổi họp cố định. Đây là phần việc BA đóng góp nhiều nhất và cũng là phần bị cắt đầu tiên khi dự án gấp. Cắt một sprint thì chưa thấy gì. Cắt ba sprint liên tiếp thì buổi planning nào cũng biến thành buổi hỏi đáp yêu cầu.

Phân biệt với Sprint Backlog

Sai lầm hay gặp: PO nhét thêm item vào sprint đang chạy vì "cái này nhanh thôi". Item mới thuộc về Product Backlog, muốn đưa vào sprint thì phải bàn với Developers và soi lại Sprint Goal.

Dấu hiệu backlog đang mục ruỗng

• Item tạo từ tháng 3 năm 2024, chưa ai sửa dòng nào từ đó. Người viết đã nghỉ việc.
• Tổng cộng 800 item, không ai cuộn quá 30 dòng đầu. Gõ tìm một từ khóa ra sáu item nội dung na ná nhau.
• Bug treo hai năm, không ai sửa mà cũng không ai dám đóng.
• Item viết kiểu "Xử lý case hôm qua chị Hằng nói", sáu tháng sau đọc lại không ai hiểu case nào.
• Backlog thành nơi chôn lời từ chối. Thay vì nói không, PO nói "để anh cho vào backlog nhé", cả hai bên đều ngầm hiểu nó sẽ nằm đó vĩnh viễn.

Hậu quả nặng hơn chuyện tốn dung lượng Jira nhiều. PO mất khả năng trả lời câu "cái gì tiếp theo, vì sao", còn refinement rút xuống thành trò lướt danh sách.

Dọn thế nào

Một team 9 người làm sàn tuyển dụng, sản phẩm chạy được bốn năm, backlog tích 640 item. Họ dọn trong hai buổi, mỗi buổi 90 phút:

1. Lọc theo ngày chỉnh sửa cuối. Item không ai đụng quá 6 tháng gắn nhãn stale — ra 410 item.
2. Với mỗi item stale, hỏi đúng một câu: nếu hôm nay mới nghe yêu cầu này lần đầu, có đưa vào backlog không? Không thì đóng với lý do "hết giá trị". Đóng chứ không xóa, để còn tra lại được.
3. Gộp item trùng, giữ bản mô tả rõ nhất, chép bối cảnh của các bản kia vào phần bình luận.
4. Item còn giá trị nhưng chắc chắn chưa làm trong hai quý tới thì rút thành một dòng ở mức ý tưởng, chuyển sang trang riêng ngoài backlog chính.
5. Backlog chính giữ đúng phần đủ dùng cho hai đến ba sprint tới ở mức đã refine, cộng vài epic thô cho quý sau.

Từ 640 xuống 180 item, buổi refinement rút từ 90 phút còn 45. Người phản đối bao giờ cũng nói một câu quen thuộc: đóng đi rồi mất yêu cầu thì sao. Item đóng vẫn tìm lại được, và một yêu cầu thật sự cần thì nó sẽ quay lại qua tổng đài, qua sale, qua chính khách hàng. Yêu cầu quan trọng không im lặng suốt hai năm.