Câu trả lời được chấp nhận
Sprint Backlog có thể thay đổi — Scrum Guide 2020 nói Sprint Backlog được Developers cập nhật trong suốt sprint khi họ học thêm, và phạm vi có thể được làm rõ và thương lượng lại với Product Owner. Nhưng có hai ranh giới:
- Không thực hiện thay đổi nào đe doạ Sprint Goal.
- Chất lượng không bị hạ thấp.
Ai quyết? Product Owner chịu trách nhiệm về thứ tự ưu tiên và giá trị — mọi yêu cầu mới phải đi qua PO, không đi thẳng tới từng Developer. Scrum Master có trách nhiệm giúp tổ chức hiểu và tôn trọng điều này.
Cách xử lý khi việc khẩn cấp đến
- Chuyển yêu cầu về PO, PO đánh giá với người yêu cầu: khẩn cấp thật hay chỉ "muốn sớm"?
- Nếu khẩn cấp và vẫn đạt được Sprint Goal: đưa vào, đồng thời bỏ ra khối lượng tương đương không ảnh hưởng mục tiêu.
- Nếu làm thì Sprint Goal mất ý nghĩa: PO cân nhắc — có thể đợi sprint sau (thường chỉ vài ngày), hoặc trong trường hợp mục tiêu sprint đã lỗi thời, chỉ PO mới có quyền huỷ sprint.
- Ghi nhận minh bạch: việc chen ngang hiện trên bảng, được nhắc ở Sprint Review.
Hạn chế lặp lại
- Đo tỉ lệ việc chen ngang qua vài sprint. Nếu ổn định ở mức nào đó (ví dụ 15–20% năng lực), dành sẵn khoảng đệm khi lập kế hoạch sprint.
- Lập kênh tiếp nhận rõ ràng (một người trực luân phiên, hoặc một làn "khẩn cấp" có giới hạn).
- Rút sprint ngắn hơn: khi sprint chỉ một tuần, "đợi sprint sau" dễ được chấp nhận hơn.
- Đưa chủ đề này vào Retrospective để tìm nguyên nhân gốc (thiếu kênh hỗ trợ, nợ kỹ thuật gây lỗi…).
Nguồn: