Sprint Backlog là 1 phần nhỏ hơn của Product backlog, là danh sách các hạng mục mà đội phát triển dự định chuyển giao trong 1 Sprint, từ đó hoàn thành Sprint goal và tiến gần hơn đến kết quả mong muốn
Sprint Backlog sẽ chứa các product backlog items mà team đã đồng ý với Product owner sẽ thực hiện vào buổi Sprint Planning.
Hình thành được 1 Sprint Backlog sẽ giúp team có một sự tập trung rõ ràng trong ngắn hạn. Khác với Product backlog là thứ cung cấp 1 cái nhìn tổng thể hơn về sản phẩm, nơi chứa các ý tưởng, hạng mục hướng tới tương lai.
Có một danh sách các Product backlog items trong Sprint backlog sẽ bảo vệ team khỏi việc thay đổi các ưu tiên, và các gián đoạn trong 1 khoảng thời gian ngắn, thường là 2 tuần.
Hơn nữa, giữ cho Sprint backlog minh bạch, hiện hữu được tiến độ thực hiện của các hạng mục là rất cần thiết. Điều này giúp team dễ dàng trao đổi, tương tác dựa trên trạng thái của hạng mục, từ đó tìm cách phối hợp để cùng nhau hoàn thành Sprint Goal.
Development team, (đội phát triển) sẽ là người sở hữu và quản lý Sprint backlog. Họ là người sẽ xác định hạng mục nào mới cần thêm vào hoặc các hạng mục nào cần bỏ đi.
Nếu team phát hiện ra có những nhiệm vụ - task cần hoàn thành để chuyển giao được các hạng mục trong Product Backlog, thì các task đó sẽ trở thành 1 phần của Sprint backlog. Team có thể thêm, bớt các task trong quá trình diễn ra Sprint.
Sprint backlog cũng có thể chứa các hạng mục công việc mà team nhận diện từ buổi Sprint Review, Retrospective ở Sprint trước.
Sprint backlog thường được minh họa và tracking qua 1 bảng Kanban board/task board, thể hiện trạng thái dòng chảy công việc.
Các hạng mục công việc này có thể là user story, được mô tả và có định nghĩa hoàn thành.
Chúng cũng có thể là bug, cần được fix. Cũng có thể là các nghiên cứu cần được thực hiện, các thay đổi đối với sản phẩm, kiến trúc hoặc hạ tầng.
Sprint Backlog chỉ tồn tại trong vòng 1 Sprint. Mỗi Sprint mới chúng ta lại khởi tạo 1 sprint backlog mới. Dù vậy, team có thể chọn thêm các hạng mục vào Sprint backlog của Sprint trước để tạo thành 1 Sprint Backlog mới.
Team này thể hiện Sprint Backlog dưới dạng Kanban với các cột như sau:
Team có thể sử dụng công cụ Trello hoặc Gitlab để lưu giữ, cập nhật, tương tác trao đổi ngay trên các card.
Chính trong buổi Sprint Planning, là lúc đội phát triển cùng xác định mục tiêu của Sprint. Đặt câu hỏi Sprint này team mình cần hoàn thành, chuyển giao các hạng mục gì? Làm sao để đạt được các kết quả như mong muốn.
Bạn có thể xem chi tiết diễn biến 1 buổi Sprint Planning tại đây.
Tựu chung lại, đây là buổi mà có sự tham gia của Product Owner, đội phát triển, và Scrum master.
Các bước cụ thể thường thấy:
Phần đầu PO sẽ trình bày mục tiêu mong muốn đạt được qua Sprint này. Đối với một số team tự chủ có mức độ tự quản cao, đã có kế hoạch công việc từ trước thì team sẽ dành thời gian trước buổi Planning để thêm vào Sprint backlog các hạng mục mình muốn hoàn thành.
Tiếp theo, cả team cùng với PO sẽ bàn bạc, thống nhất các hạng mục quan trọng ưu tiên chuyển giao sớm trong Sprint. Dựa trên năng lực của nhóm mình, team sẽ xác nhận với PO và cam kết với nhau các hạng mục nào là must-have/ ưu tiên cao, các hạng mục nào là should-have/ưu tiên thấp hơn.
Việc tính toán năng lực của nhóm là quan trọng vì nếu không ước lượng kỹ, team bạn có thể nhận nhiều hạng mục hơn sức có thể chuyển giao, dẫn đến quá tải, thậm chí làm nhiều mà chất lượng lại kém.
Đối với các hạng mục công việc được nhắm đến để hoàn thiện trong Sprint, team cần bẻ nhỏ công việc thành các task cụ thể, đủ nhỏ để hoàn thành trong vòng 1 ngày hoặc ít hơn.
Thông thường các task sẽ thuộc các thể loại: thiết kế giải pháp, viết test case, code, viết tài liệu, nghiên cứu kỹ thuật/công nghệ mới, fixx bug, họp với team ABC, trao đổi với khách hàng,...
1 task được đưa vào Sprint Backlog không chỉ là tiêu đề của task mà còn cần có những thông tin chi tiết như:
Sau khi tính toán kỹ lưỡng khối lượng công việc, đội phát triển có thể thương lượng với PO để chủ động nhận thêm hoặc bớt các hạng mục kém quan trọng trong Sprint Backlog.
Team Marketing cũng như các team khác tại Magestore hiện đang vận hành task board trên Gitlab với 8 cột:
Team này định nghĩa 1 cột gọi là Sprint Backlog nơi chứa các hạng mục team muốn hoàn thành trong 1 Sprint nhất định.
Đầu tuần team sẽ họp Sprint Planning, để xác định Sprint Backlog hay còn gọi là Milestone tuần. Các Task được team ấn định vào Milestone tuần sẽ được move từ cột Open sang cột Sprint Backlog. Với mỗi task được đưa vào cột Sprint Backlog, team đã:
Trong tuần, thành viên nào đang làm task nào thì sẽ tự chuyển trạng thái task đó từ cột Sprint Backlog, sang các cột tiếp theo tương ứng với hiện trạng task mình làm.
Cuối tuần, trong buổi họp Sprint Review, các thành viên team và PO sẽ ngồi lại với nhau để