Thuật ngữ
Backlog là gì? Product Backlog, Sprint Backlog và cách sắp ưu tiên
Backlog là danh sách mọi việc dự án có thể cần làm, xếp theo ưu tiên. Product Backlog khác Sprint Backlog, một việc cần gì để sẵn sàng, cách sắp ưu tiên, refinement.
Khoảng 6 phút đọc
Trả lời ngắn
Định nghĩaBacklog là danh sách mọi việc dự án có thể cần làm, gồm tính năng, lỗi, cải tiến, nợ kỹ thuật, xếp theo thứ tự ưu tiên. Việc ở trên cùng sẽ làm sớm nhất nên được mô tả rõ nhất; càng xuống dưới càng thô. Backlog không bao giờ “xong”, nó được thêm, bớt và sắp lại liên tục, và chỉ một người chịu trách nhiệm về thứ tự.
Backlog là hiện vật quan trọng nhất của Scrum vì mọi thứ khác bắt đầu từ nó: sprint chọn việc từ backlog, bảng Kanban hiển thị việc của backlog, và yêu cầu khách hàng khi được chấp nhận cũng vào backlog. Backlog lộn xộn thì sprint lộn xộn.
Product Backlog và Sprint Backlog
| Product Backlog | Sprint Backlog | |
|---|---|---|
| Chứa gì | Mọi việc của sản phẩm, có thể vài chục đến vài trăm | Phần việc đội chọn cho sprint này, thường 8–20 việc |
| Ai giữ | Product Owner hoặc quản lý dự án: sắp thứ tự, thêm bớt | Đội: tự chia task con, tự giao người |
| Thay đổi | Liên tục, bất cứ lúc nào | Chốt ở Planning; thêm việc thì phải bớt việc tương đương |
| Đơn vị thời gian | Cả vòng đời sản phẩm | Một sprint, 1–4 tuần |
Đội nhỏ hay nhầm hai thứ này thành một: cứ có việc là nhét vào sprint đang chạy. Kết quả là sprint không bao giờ xong và không ai biết cam kết là gì. Quy tắc dễ nhớ: việc mới vào Product Backlog trước, chờ Planning sau, trừ lỗi khẩn thật sự.
Một việc trong backlog cần gì để sẵn sàng
Việc ở đầu backlog phải đủ năm thứ
- Tiêu đề rõ nghĩa theo mẫu động từ, đối tượng, điều kiện: “Xuất bảng điểm PDF có dấu tiếng Việt”, không phải “PDF lỗi”.
- Mô tả đủ để không phải hỏi lại: story viết từ góc nhìn người dùng kèm tiêu chí chấp nhận; lỗi thì có bước tái hiện, kết quả mong đợi và thực tế.
- Ước lượng bằng story point, đội cùng chấm; việc trên 13 điểm phải tách trước khi vào sprint.
- Phân hệ và ưu tiên để lọc và báo cáo theo mảng; không để mọi việc đều Cao.
- Không phụ thuộc treo: nếu cần API của đơn vị khác, ghi rõ và hỏi lịch bàn giao trước Planning, không phát hiện giữa sprint.
Cách viết story và tiêu chí chấp nhận có bài riêng: User story là gì?; ba loại việc Story, Task, Bug và task con ở chương Backlog và công việc.
Sắp ưu tiên: ba câu hỏi và một người quyết
Thứ tự backlog trả lời ba câu hỏi theo đúng thứ tự này: việc nào đem lại giá trị sớm nhất cho người dùng; việc nào rủi ro nhất nên làm sớm để biết sớm; việc nào mở khóa các việc khác. Chi phí xét sau cùng: việc rẻ mà không ai cần vẫn là lãng phí.
Một người chịu trách nhiệm về thứ tự
Refinement: chăm backlog 30–60 phút mỗi tuần
Backlog refinement là buổi ngắn giữa sprint để làm rõ, tách nhỏ và ước lượng các việc sắp tới, sao cho lúc nào cũng có khoảng một sprint rưỡi việc “sẵn sàng” ở đầu backlog. Đội làm refinement đều thì Planning chỉ mất một giờ; đội bỏ refinement thì Planning kéo ba giờ và vẫn chọn nhầm việc.
Ví dụ: dọn một backlog 60 việc
Ví dụ
Phòng CNTT một trường nhận lại dự án cổng sinh viên từ đội cũ với một file Excel 60 dòng, cột “ưu tiên” toàn chữ Cao. Trưởng nhóm làm ba việc trong một buổi chiều.
Thứ nhất, gộp và xóa: 60 dòng thành 41 việc, 9 dòng là cùng một lỗi viết bốn cách, 10 dòng là ý tưởng không ai còn nhớ. Thứ hai, chọn 12 việc đầu và viết lại đủ năm thứ, các việc còn lại chỉ giữ tiêu đề. Thứ ba, sắp thứ tự bằng ba câu hỏi và gửi phòng Đào tạo một dòng: “Sáu tuần tới làm 12 việc này theo thứ tự này, có gì cần đảo thì báo trước thứ Hai.” Từ đó mỗi thứ Tư có 45 phút refinement, và Planning sprint sau chỉ mất 50 phút.
Bốn lỗi hay gặp
Đội mới hay mắc
- Backlog là kho ý tưởng. Ba trăm việc, phần lớn không ai nhớ. Việc không định làm trong ba tháng tới thì để danh sách riêng hoặc xóa.
- Mọi việc đều chi tiết như nhau. Tốn công viết kỹ việc sáu tháng sau mới làm, đến lúc đó yêu cầu đã đổi. Chỉ việc đầu backlog cần đủ năm thứ.
- Tự kéo việc của mình lên đầu. Backlog phản ánh ưu tiên của người dùng, không phải sở thích kỹ thuật.
- Yêu cầu khách hàng đi thẳng vào sprint. Yêu cầu cần tiếp nhận, phân loại, rồi vào backlog; chỉ lỗi nghiêm trọng mới vào sprint ngay và phải đổi việc khác ra.
Backlog trên Pentara
Tab Backlog liệt kê các sprint và một khối “Backlog: công việc chưa thuộc sprint nào”. Thành viên nào cũng tạo được việc mới, việc mới mặc định nằm ở khối này và ở cột đầu tiên của Board. Kéo tay nắm để sắp thứ tự hoặc đưa việc vào sprint, tích chọn nhiều việc để chuyển một lần; bộ lọc theo người, loại, ưu tiên, phân hệ, nhãn, trễ hạn dùng khi backlog dài.
Yêu cầu khách hàng được chấp nhận chuyển thành việc bằng một nút, vào thẳng backlog với phân hệ và ưu tiên điền sẵn. Mỗi việc có story point, hạn, người thực hiện, task con và tiêu chí chấp nhận trong mô tả. Thử ngay với một dự án thật: đăng ký gói Miễn phí, rồi làm theo Bắt đầu nhanh.
Hỏi đáp nhanh
- Backlog nên có bao nhiêu việc?
- Đủ cho khoảng ba đến sáu sprint tới là hợp lý, thường 30–80 việc với đội nhỏ. Chỉ việc đầu backlog, khoảng một sprint rưỡi, cần đủ rõ để làm; phần còn lại chỉ cần tiêu đề. Việc không định làm trong ba tháng thì để danh sách riêng hoặc xóa.
- Ai được thêm việc vào backlog?
- Ai cũng được thêm: thành viên, tester, khách hàng qua cổng yêu cầu. Nhưng chỉ một người, quản lý dự án hoặc Product Owner, sắp thứ tự và quyết việc nào vào sprint. Thêm việc không có nghĩa là việc sẽ được làm sớm.
- Yêu cầu khách hàng có vào thẳng backlog không?
- Không. Yêu cầu vào hộp tiếp nhận trước, được phân loại và trả lời, rồi khi chấp nhận mới chuyển thành việc trong backlog với phân hệ và ưu tiên. Chỉ lỗi nghiêm trọng mới vào sprint đang chạy ngay, và phải đổi việc khác ra.