Các bên liên quan từ chối một tính năng tại sprint review. Bước tiếp theo là gì?

Trước hết tôi giữ thái độ tò mò thay vì phòng thủ. Sprint Review nhằm kiểm tra increment và thu thập phản hồi, nên việc bị từ chối là thông tin, không phải thất bại.

1. Hiểu lý do. Hỏi chính xác điều gì sai: thiếu nhu cầu, hành vi sai, khả năng sử dụng, hay ưu tiên đã đổi. Ghi lại phản hồi nguyên văn.
2. Tách các nguyên nhân. Chúng ta hiểu sai yêu cầu, nhu cầu đã thay đổi, hay chất lượng kém? Mỗi nguyên nhân dẫn đến cách sửa khác nhau: refinement tốt hơn, thay đổi backlog, hoặc Definition of Done chặt hơn.
3. Quyết định dựa trên dữ liệu. Điều chỉnh Product Backlog: làm lại, định hình lại hoặc bỏ mục đó, và sắp xếp lại thứ tự so với các việc khác. Bỏ cũng là một kết quả hợp lệ, vì ta tránh được việc đầu tư thêm vào thứ sai.
4. Khép vòng. Thống nhất với các bên liên quan thế nào là "đạt" và khi nào họ sẽ thấy phiên bản tiếp theo.
5. Kiểm tra quy trình trong retrospective, ví dụ bằng cách mời các bên liên quan tham gia sớm hơn, với prototype hoặc demo giữa sprint.

Product Owner vẫn chịu trách nhiệm về thứ tự backlog kết quả.