Sprint backlog là danh sách các công việc đã được Scrum team xác định là cần phải hoàn thành trong 1 sprint. Trong suốt cuộc họp sprint planning, cả team chọn một vài item trong product backlog (thường được viết dưới dạng các user story), và xác định các task cần làm để hoàn thành mỗi user story. Hầu hết team cũng ước lượng thời gian để một thành viên trong team có thể hoàn thành từng task.
Điều cần tuân thủ nghiêm ngặt là team sẽ chọn các item và khối lượng của sprint backlog. Bởi vì họ là người sẽ hoàn thành các task, cho nên chính họ phải là người chọn việc sẽ làm trong Scrum sprint.
Sprint backlog thường được theo dõi bằng một bảng tính, nhưng nó cũng có thể được theo dõi bằng một hệ thống hoặc bất kỳ phần mềm nào được thiết kế chuyên biệt cho Scrum hoặc Agile. Dưới đây là một ví dụ về một sprint backlog trong một bảng tính:
Sprint backlog
Trong một sprint, các thành viên phải cập nhật sprint backlog khi có thông tin mới, ít nhất một ngày một lần. Nhiều team làm việc này trong daily scrum. Mỗi ngày một lần, khối lượng công việc còn lại được tính toán và vẽ thành biểu đồ bởi Scrum Master, tạo thành sprint burndown chart như bên dưới.
Team phải gắng sức để chọn khối lượng công việc tương xứng với Sprint, nhưng thỉnh thoảng sẽ gặp trường hợp một sprint quá nhiều việc, hoặc quá ít việc. Trong các trường hợp đó, team phải thêm hoặc bớt task.
Sprint burndown chart
Hãy làm một ví dụ với biểu đồ phía trên. Như chúng ta có thể thấy, trong tình huống này, ban đầu cả team đã chọn quá nhiều việc trong sprint backlog, cho nên ở ngày thứ 13 (trong tổng số 20 ngày) của sprint, khối lượng công việc phải làm vẫn còn đến gần 600 giờ. Product owner đã được xin ý kiến và đã đồng ý giảm bớt user story trong sprint. Kết quả là đã có một sự sụt giảm trên biểu đồ từ ngày 13 đến ngày 14. Từ đó, team đã chạy ổn định và hoàn thành Scrum sprint.
Theo longnguyen.site
Japan IT Works
