Sprint Backlog
Kế hoạch của Developers cho một sprint, gồm Sprint Goal, các hạng mục lấy từ Product Backlog và cách làm chúng. Do chính đội phát triển sở hữu và cập nhật hằng ngày.
Định nghĩa
Đầu mỗi sprint, đội lấy một nhúm việc từ Product Backlog xuống, thống nhất sprint này để làm gì, rồi vạch cách làm. Cái nhúm việc đó cộng với mục tiêu và kế hoạch chính là Sprint Backlog. Nghe đơn giản, mà đây là chỗ nhiều đội hiểu lệch nhất, chủ yếu ở câu hỏi ai có quyền đụng vào nó.
Product Backlog là của Product Owner. Sprint Backlog là của Developers. Ranh giới này là thứ giữ cho sprint không biến thành một cái sọt đựng việc.
Gồm ba phần
Theo Scrum Guide bản 2020, Sprint Backlog có đúng ba thành phần:
- Sprint Goal — vì sao. Một câu mô tả giá trị sprint này mang lại, và đây là cam kết của Sprint Backlog.
- Các hạng mục được chọn từ Product Backlog — cái gì.
- Kế hoạch bàn giao — làm thế nào. Thường là các đầu việc kỹ thuật đội tự chia ra.
Phần thứ nhất hay bị bỏ. Không có Sprint Goal thì sprint chỉ còn là một danh sách việc rời rạc, và khi cần đánh đổi giữa hai story vào ngày thứ tám, không ai có căn cứ để quyết cái nào nhường cái nào.
So với Product Backlog
| Product Backlog | Sprint Backlog | |
|---|---|---|
| Ai sở hữu | Product Owner | Developers |
| Phạm vi | Toàn bộ sản phẩm, không có điểm kết | Đúng một sprint |
| Cam kết đi kèm | Product Goal | Sprint Goal |
| Mức chi tiết | Trên cùng thì kỹ, dưới thì thô | Đủ chi tiết để bắt tay làm ngay |
| Ai được thêm bớt | PO quyết thứ tự, ai cũng đề xuất được | Chỉ Developers, trong phạm vi Sprint Goal |
| Nhịp cập nhật | Liên tục, có buổi refinement | Hằng ngày, thường ở Daily Scrum |
Một nhầm lẫn phổ biến khác: coi bảng Jira của sprint là toàn bộ Sprint Backlog. Bảng đó thể hiện phần "cái gì" và một phần "thế nào", còn Sprint Goal thì nằm trong đầu vài người hoặc chẳng nằm ở đâu. Ghi Sprint Goal vào ngay tên sprint trong Jira, một dòng thôi.
Ai được đụng vào giữa sprint
Đội được quyền tự điều chỉnh: tách một story thành hai, thêm việc kỹ thuật phát sinh, bỏ bớt phần thừa, miễn là Sprint Goal còn nguyên. Đó là quyền của Developers, không cần xin ai.
Người ngoài đội nhét thêm việc giữa sprint thì khác hẳn. Nếu chuyện đó xảy ra, cách xử lý theo thứ tự: hỏi việc mới có phục vụ Sprint Goal không; nếu không thì hỏi đổi lấy việc nào ra khỏi sprint; nếu vẫn không đổi được và việc mới thật sự cấp, PO có quyền huỷ sprint — hiếm khi dùng, nhưng nó tồn tại chính vì tình huống này.
Ở nhiều công ty Việt Nam, sếp nhắn thẳng cho dev trong Zalo nhóm và việc mới lặng lẽ được làm. Không ai ghi vào bảng, sprint trượt, retro thì kết luận là "đội ước lượng chưa tốt". Cách chữa rẻ nhất: mở một cột "việc chen ngang" trên bảng, ghi mọi thứ vào đó kèm giờ công. Sau ba sprint, bạn có số liệu để nói chuyện thay vì cảm giác.
Ví dụ thực tế
Đội 6 người làm ứng dụng đặt lịch cắt tóc, sprint hai tuần.
Sprint Goal: khách hàng đặt được lịch và trả trước bằng ví điện tử mà không cần gọi salon.
Sprint Backlog gồm 5 story, tổng 34 điểm, và 11 đầu việc kỹ thuật đội tự chia thêm, trong đó có việc dựng môi trường sandbox của cổng thanh toán và việc viết job đối soát giao dịch treo.
Ngày thứ tư, cổng thanh toán trả về lỗi ở luồng hoàn tiền, phát sinh thêm ước chừng hai ngày công. Đội tự thêm việc vào Sprint Backlog và cắt bớt phần lịch sử đặt chỗ có bộ lọc nâng cao — thứ nằm ngoài Sprint Goal. Không cần họp xin phép, chỉ báo trong Daily Scrum và cho PO biết ở buổi review.
Sprint đóng với 29 trên 34 điểm hoàn thành. Nhìn qua như trượt, nhưng Sprint Goal đạt: khách đặt và trả tiền được. Đó là cách đọc đúng một sprint.
Câu hay bị hỏi phỏng vấn
- Sprint Backlog khác Product Backlog chỗ nào. Trả lời theo bốn trục: chủ sở hữu, phạm vi thời gian, mức chi tiết, cam kết đi kèm.
- Giữa sprint khách đòi thêm việc thì làm sao. Đừng trả lời "em nhận thêm". Nói về Sprint Goal, về việc đổi ngang, và về quyền huỷ sprint của PO.
- Sprint Backlog do ai lập. Developers, trong buổi Sprint Planning, cùng PO làm rõ phần "cái gì" và "vì sao".
