Product backlog là gì? Khác sprint backlog thế nào?
Định nghĩa product backlog theo Scrum Guide 2020, khác sprint backlog ở đâu, ai sắp xếp, và cách dọn một backlog đã thành bãi chứa việc.
Viết bởi Phan Lâm Duy Khôi
Product backlog là danh sách có thứ tự, luôn thay đổi, gồm những gì cần làm để cải thiện sản phẩm, và là nguồn việc duy nhất của Scrum Team. Sprint backlog là phần dành cho một sprint: Sprint Goal, các mục được chọn từ product backlog và kế hoạch thực hiện, do Developers lập và dùng.
Product backlog là gì?
Product backlog là danh sách có thứ tự, luôn thay đổi, gồm những gì cần làm để cải thiện sản phẩm. Sprint backlog thì khác: đó là kế hoạch cho một sprint, gồm Sprint Goal, các mục được chọn từ product backlog và cách làm, do Developers lập và dùng.
Định nghĩa thì gọn như vậy. Cái khó nằm ở chỗ khác. Hãy hình dung tình huống minh họa sau: bạn vừa nhận vai Product Owner cho một app đặt cơm trưa văn phòng. Người trước bàn giao một board có khoảng 240 mục (số minh họa). Gần như mục nào cũng gắn nhãn “High”. Có mục tạo từ hơn một năm trước, có mục chỉ ghi “Tối ưu UX”, có ba mục cùng nói về việc đặt lại món hôm qua. Hai ngày nữa team họp sprint planning và hỏi bạn: “Sprint này làm gì trước?”
Bài này giúp bạn hiểu product backlog đúng theo Scrum Guide 2020, phân biệt nó với sprint backlog và một to-do list, rồi đi qua cách dọn một backlog lộn xộn thành một danh sách team dùng được. Cuối bài có checklist kiểm tra sức khỏe backlog để bạn dùng ngay.
Vì sao backlog dễ biến thành bãi chứa việc?
Backlog phình ra không phải vì ai đó làm sai một lần. Nó là kết quả của nhiều quyết định nhỏ, mỗi cái đều có vẻ hợp lý lúc đó.
- Thêm vào thì dễ, bỏ ra thì ngại. Ghi một yêu cầu vào backlog giúp cuộc trao đổi kết thúc êm. Xóa nó đi lại giống như từ chối người đã gửi.
- Nhãn ưu tiên mất nghĩa. Khi ai cũng muốn việc của mình được làm trước, mọi mục đều thành “High”, và nhãn đó không còn giúp ai chọn được gì.
- Không có đích để so. Nếu team chưa viết ra Product Goal, không có cách nào nói một mục là lạc đề.
- Nhầm backlog với danh sách việc kỹ thuật. Những dòng như “thêm cột vào bảng đơn hàng” nói cách làm, không nói làm cho ai và để thay đổi điều gì.
PO mới dễ gặp thêm một khó khăn: bạn chưa biết lịch sử của từng mục. Có mục trông vô nghĩa nhưng lại là lời hứa với một khách hàng lớn. Vì vậy dọn backlog không phải là xóa thật nhanh, mà là xem lại có lý do và để lại dấu vết.
Product backlog khác sprint backlog và to-do list thế nào?
Scrum Guide 2020 mô tả hai artifact này rất rõ. Mỗi artifact đi kèm một cam kết: product backlog đi với Product Goal, sprint backlog đi với Sprint Goal. To-do list không phải khái niệm của Scrum, nhưng hay bị nhầm với backlog nên được đặt vào đây để so.
| Tiêu chí | Product backlog | Sprint backlog | To-do list |
|---|---|---|---|
| Là gì | Danh sách có thứ tự, luôn thay đổi, gồm những gì cần để cải thiện sản phẩm | Sprint Goal, các mục được chọn cho sprint và kế hoạch thực hiện | Danh sách việc của một người hoặc một nhóm, không theo khung nào |
| Cam kết đi kèm | Product Goal, mục tiêu dài hạn của Scrum Team | Sprint Goal, mục tiêu duy nhất của sprint | Không có |
| Ai chịu trách nhiệm | Product Owner chịu trách nhiệm, kể cả khi giao bớt việc | Developers lập và dùng cho chính họ | Người viết ra nó |
| Khoảng thời gian | Cả vòng đời sản phẩm | Một sprint | Tùy người dùng |
| Mức chi tiết | Phần đầu rõ và nhỏ, phần dưới còn thô | Đủ chi tiết để Developers theo dõi tiến độ hằng ngày | Tùy người viết |
| Thay đổi thế nào | Người muốn đổi cần thuyết phục PO | Developers cập nhật trong sprint khi biết thêm; phạm vi có thể làm rõ lại với PO | Ai viết thì người đó sửa |
Điểm dễ nhầm nhất là quyền với sprint backlog. Đó là kế hoạch của Developers, không phải danh sách PO giao xuống. PO mang vào sprint planning các mục đã được sắp thứ tự và một đề xuất về giá trị của sprint. Phần tách việc và lên kế hoạch làm thế nào thuộc về Developers.
Từ “Developers” trong Scrum chỉ những người trong Scrum Team làm ra Increment, không chỉ lập trình viên. Tester, designer hay người viết nội dung trong team cũng là Developers nếu họ cùng làm ra phần việc đó.
Ai sở hữu và sắp xếp product backlog?
Theo Scrum Guide 2020, Product Owner chịu trách nhiệm quản lý product backlog hiệu quả. Việc đó gồm xây dựng và truyền đạt Product Goal, viết và truyền đạt rõ các mục backlog, sắp xếp thứ tự, và giữ cho backlog minh bạch, dễ thấy, dễ hiểu. PO có thể tự làm hoặc giao cho người khác, nhưng vẫn là người chịu trách nhiệm.
Điều này không có nghĩa là PO viết mọi thứ một mình. Developers, stakeholder hay đội hỗ trợ khách hàng đều có thể đề xuất mục mới. Theo Scrum Guide, ai muốn thay đổi product backlog thì cần thuyết phục PO. Quyết định của PO được nhìn thấy qua nội dung và thứ tự của backlog.
Hai chi tiết đáng nhớ. Thứ nhất, Scrum Guide nói backlog được sắp thứ tự (ordered), không chỉ gắn nhãn ưu tiên. Thứ tự buộc bạn chọn: chỉ có một mục ở vị trí số một. Thứ hai, ước lượng kích thước do Developers, những người sẽ làm việc đó, chịu trách nhiệm. PO giải thích và trả lời câu hỏi, không tự điền số.
Khi nhiều yêu cầu cùng “gấp”, bạn cần một cách sắp thứ tự có thể giải thích được với stakeholder. Phần đó đã có bài riêng, kèm các khung như value vs effort, MoSCoW và RICE.
Một product backlog lành mạnh trông như thế nào?
Mountain Goat Software mô tả rằng các mục ở gần đầu backlog nên rõ hơn và nhỏ hơn các mục ở dưới. Scrum Guide cũng nói các mục mà Scrum Team có thể làm xong trong một sprint được xem là sẵn sàng để chọn trong sprint planning. Từ đó, một cách hình dung hữu ích là chia backlog thành ba tầng:
- Phần đầu: đủ việc cho khoảng một đến hai sprint tới (gợi ý của bài, team tự điều chỉnh). Mỗi mục đủ nhỏ để làm xong trong một sprint, có acceptance criteria, team đã hiểu và đã ước lượng.
- Phần giữa: đã rõ vấn đề và người dùng, nhưng chưa cần chi tiết. Chỉ cần một câu mô tả kết quả và vài câu hỏi mở.
- Phần cuối: ý tưởng còn thô. Không ai cần đầu tư viết kỹ cho đến khi chúng tiến lên gần đầu.
Backlog lành mạnh không có nghĩa là ngắn. Nó có nghĩa là mỗi mục có lý do để ở đó, thứ tự phản ánh Product Goal, và phần đầu luôn sẵn sàng. Việc làm rõ dần các mục từ giữa lên đầu chính là product backlog refinement. Scrum Guide gọi đây là hoạt động diễn ra liên tục, để thêm chi tiết như mô tả, thứ tự và kích thước.
Ngược lại, đây là những dấu hiệu backlog đang không khỏe:
- Hàng trăm mục không ai đụng tới trong nhiều tháng, và không ai dám xóa.
- Mọi mục đều “High priority”, nên nhãn không giúp chọn được gì.
- Các mục là task kỹ thuật (“thêm API”, “sửa bảng”) thay vì kết quả cho người dùng.
- Cùng một yêu cầu xuất hiện nhiều lần dưới tên khác nhau.
- Tới sprint planning mà các mục đầu vẫn chưa ai hiểu đủ để ước lượng.
- Không ai trong team nói được Product Goal hiện tại là gì.
Cách dọn một product backlog lộn xộn
Quy trình dưới đây là cách làm bài này đề xuất. Scrum Guide không quy định cách dọn backlog, nên bạn có thể điều chỉnh theo team. Lần dọn đầu tiên có thể tốn vài buổi. Sau đó, giữ nhịp nhẹ qua refinement để backlog không phình lại.
- Viết Product Goal: Đặt lên đầu backlog, một câu
- Lọc từng mục: Lưu trữ, gộp, viết lại hoặc để thô
- Sắp một thứ tự: Mỗi vị trí chỉ một mục
- Refine phần đầu: Cùng Developers làm rõ và ước lượng
Sau mỗi sprint, xem lại phần đầu và lọc các mục mới. Không cần dọn lại toàn bộ.
Bước 1 là nền cho cả quá trình. Product Goal mô tả trạng thái tương lai của sản phẩm mà team nhắm tới. Nếu chưa có, hãy cùng stakeholder và team viết một bản nháp. Không cần hoàn hảo, nhưng cần đủ rõ để hỏi được “mục này có giúp tới đó không?”.
Bước 2 là phần tốn công nhất. Với mỗi mục, đi qua bốn câu hỏi theo thứ tự:
Một mục trong backlog
- Mục này còn phục vụ Product Goal hoặc một vấn đề người dùng đang gặp? Chuyển vào kho lưu trữ, ghi lý do và báo người đã yêu cầu
- Mục này là bản duy nhất trong backlog? Gộp các bản trùng thành một mục, giữ tên tất cả người yêu cầu
- Mục này nói được sẽ thay đổi điều gì, cho ai? Viết lại theo kết quả; phần cách làm để Developers lên kế hoạch
- Team định làm mục này trong một đến hai sprint tới? Để thô ở phần giữa hoặc cuối, chỉ ghi câu hỏi mở
Đặt vào phần đầu backlog và đưa vào refinement để sẵn sàng cho sprint planning
Lưu trữ khác xóa. Mục đã lưu trữ vẫn tìm lại được, kèm lý do. Nếu sau này vấn đề quay lại, bạn có lịch sử để xem. Khi báo người đã yêu cầu, hãy nói rõ lý do và điều gì sẽ khiến bạn xem lại.
Khi viết lại một mục theo kết quả, bạn có thể dùng định dạng user story hoặc một câu đơn giản. Mountain Goat Software lưu ý rằng không phải mục backlog nào cũng cần là user story. Việc kỹ thuật thật sự cần thiết, như nâng cấp thư viện đã hết hỗ trợ, vẫn có thể là một mục riêng, miễn là ghi rõ vì sao cần làm.
Bước 3, sắp thứ tự, là quyết định của PO. Hãy so từng mục với Product Goal, ảnh hưởng tới người dùng và rủi ro nếu chưa làm. Bước 4 làm cùng Developers: các mục ở đầu được tách nhỏ, viết acceptance criteria và ước lượng.
Ví dụ: dọn backlog của app đặt cơm trưa
Quay lại app đặt cơm trưa văn phòng trong tình huống minh họa ở đầu bài. Sau khi trao đổi với team và stakeholder, PO viết Product Goal (giả định): “Nhân viên văn phòng đặt xong bữa trưa trước 10 giờ 30 mà không cần nhắn tin riêng cho quán.” Bảng dưới đây là năm mục tiêu biểu, đi qua bộ lọc ở trên.
| Mục ban đầu | Trước khi dọn | Sau khi dọn | Câu hỏi quyết định |
|---|---|---|---|
| “Làm lại giao diện trang chủ” | High, tạo hơn một năm trước, không ai nhắc lại | Chuyển vào kho lưu trữ, ghi lý do, báo người đã đề xuất | Không phục vụ Product Goal hiện tại và không gắn với vấn đề nào người dùng đang báo |
| Ba mục “Đặt lại món hôm qua” từ kinh doanh, hỗ trợ khách hàng và giám đốc | Ba mục rời, mỗi mục một mức ưu tiên | Gộp thành một mục, ghi đủ ba người yêu cầu; xếp vị trí 2 | Không phải bản duy nhất |
| “Thêm cột ghi chú vào bảng đơn hàng” | High, chỉ mô tả kỹ thuật | Viết lại: “Người đặt gửi được ghi chú cho quán, ví dụ ít cay, không hành.” Việc thêm cột để Developers tự lên kế hoạch; xếp vị trí 3 | Chưa nói được thay đổi gì, cho ai |
| “Thanh toán ví điện tử” | High, chỉ có tên | Viết lại một câu: “Người đặt trả tiền ngay trong app thay vì chuyển khoản rồi gửi ảnh cho quán.” Để ở phần giữa, ghi câu hỏi mở về phí và đối soát | Đã viết lại theo kết quả, nhưng team chưa định làm trong hai sprint tới |
| “Lỗi: Button Đặt món không bấm được trên màn hình nhỏ” | Medium, nằm sâu ở trang 9 | Xếp vị trí 1, đưa vào refinement ngay | Qua đủ bốn câu hỏi: chặn người dùng đặt món, đúng với Product Goal |
Có hai điều đáng chú ý trong ví dụ. Mục quan trọng nhất lại đang bị gắn “Medium” và nằm sâu phía dưới, vì nhãn ưu tiên đã mất nghĩa. Và mục “Thanh toán ví điện tử” không bị bỏ, chỉ được để đúng chỗ: đủ rõ để không quên, chưa tốn công viết chi tiết.
Sau lần dọn này, backlog minh họa còn ít mục hơn nhiều, phần còn lại nằm trong kho lưu trữ. Ba mục ở đầu được mang vào buổi refinement để tách nhỏ, viết acceptance criteria và ước lượng trước sprint planning. Câu hỏi “Sprint này làm gì trước?” giờ đã có câu trả lời dựa trên Product Goal, không dựa trên nhãn.
Mẫu checklist kiểm tra sức khỏe product backlog
Dùng checklist này lần đầu khi nhận một backlog mới, sau đó định kỳ theo nhịp team chọn, ví dụ mỗi sprint một lần cho phần đầu và mỗi quý một lần cho toàn bộ. Bạn copy về rồi điền các mốc theo thỏa thuận của team.
PRODUCT GOAL [ ] Product Goal được viết ra, nằm ở đầu backlog [ ] Developers và stakeholder chính nói lại được Product Goal PHẦN ĐẦU BACKLOG [ ] Đủ mục cho khoảng [số] sprint tới [ ] Mỗi mục đủ nhỏ để làm xong trong một sprint [ ] Mỗi mục có acceptance criteria [ ] Developers đã cùng làm rõ và ước lượng [ ] Mỗi mục nói được thay đổi điều gì, cho ai THỨ TỰ [ ] Backlog có một thứ tự duy nhất, không có hai mục cùng vị trí [ ] Thứ tự giải thích được bằng Product Goal [ ] Stakeholder biết đề xuất thay đổi thứ tự qua ai VỆ SINH [ ] Không có mục trùng nội dung [ ] Mục không ai đụng tới sau [số] tháng đã được xem lại [ ] Mục bị loại được lưu trữ kèm lý do, không xóa mất dấu [ ] Người yêu cầu được báo khi mục của họ bị lưu trữ LẦN KIỂM TRA TIẾP THEO: [ngày]
Nếu một dòng chưa đạt, đừng sửa hết một lúc. Chọn dòng ảnh hưởng tới sprint planning gần nhất trước, thường là phần đầu backlog, rồi sửa dần các dòng còn lại.
Những lỗi hay gặp khi quản lý product backlog
- Xóa hàng loạt mà không báo ai. Backlog gọn hơn, nhưng stakeholder mất niềm tin khi phát hiện yêu cầu của họ biến mất. Hãy lưu trữ kèm lý do và báo người yêu cầu.
- Viết chi tiết mọi mục. Thời gian viết kỹ cho một mục ở cuối backlog dễ bị phí, vì đến lúc làm thì bối cảnh đã khác.
- Coi sprint backlog là danh sách PO giao việc. Sprint backlog là kế hoạch của Developers. PO đề xuất giá trị và trả lời câu hỏi, không chia task cho từng người.
- Tự điền ước lượng. Kích thước do Developers sẽ làm việc đó chịu trách nhiệm. Con số PO tự điền dễ thành áp lực thay vì một ước lượng thật.
- Dọn một lần rồi bỏ đó. Không có nhịp xem lại qua refinement, backlog sẽ phình lại sau vài tháng.
- Giữ nhiều backlog song song. Một file cho sếp, một board cho dev và một danh sách riêng của PO làm mất ý nghĩa “nguồn việc duy nhất” mà Scrum Guide mô tả.
Khi một yêu cầu mới tới, đừng vội thêm vào backlog. Hỏi rõ vấn đề phía sau trước, rồi mới quyết định nó vào đâu.
Tóm tắt
- Product backlog là danh sách có thứ tự, luôn thay đổi, gồm những gì cần để cải thiện sản phẩm, và là nguồn việc duy nhất của Scrum Team. Cam kết của nó là Product Goal.
- Sprint backlog gồm Sprint Goal, các mục được chọn cho sprint và kế hoạch thực hiện, do Developers lập và dùng.
- Product Owner chịu trách nhiệm sắp xếp thứ tự backlog, có thể giao việc nhưng vẫn chịu trách nhiệm. Ước lượng do Developers chịu trách nhiệm.
- Backlog lành mạnh có phần đầu rõ và nhỏ, phần dưới còn thô, và mỗi mục có lý do để ở đó.
- Dọn backlog bằng bốn bước: viết Product Goal, lọc từng mục, sắp một thứ tự, refine phần đầu. Lưu trữ thay vì xóa, và báo người yêu cầu.
Mình đang soạn thêm các tình huống PO khác theo cùng khung này, kèm mẫu dùng ngay. Nếu bạn muốn nhận khi có bài mới, đăng ký bản tin bên dưới.
Câu hỏi thường gặp
Product backlog là gì?
Product backlog là danh sách có thứ tự, luôn thay đổi, gồm những gì cần làm để cải thiện sản phẩm. Theo Scrum Guide 2020, đó là nguồn việc duy nhất của Scrum Team, và Product Goal nằm trong nó.
Product backlog và sprint backlog khác nhau thế nào?
Product backlog bao trùm cả sản phẩm và do Product Owner chịu trách nhiệm. Sprint backlog chỉ cho một sprint, gồm Sprint Goal, các mục được chọn và kế hoạch thực hiện, do Developers lập và dùng.
Ai sắp xếp thứ tự product backlog?
Product Owner chịu trách nhiệm sắp xếp thứ tự product backlog. PO có thể giao việc này cho người khác nhưng vẫn là người chịu trách nhiệm, và ai muốn đổi backlog thì cần thuyết phục PO.
Nguồn kiểm tra
Bài liên quan
- User story là gì? Cách viết cho người mới, kèm mẫu và ví dụ: Mẫu “Là…, tôi muốn…, để…” là phần dễ. Bài này chỉ cách chọn đúng người dùng, đúng vấn đề và cắt story đủ nhỏ, kèm ví dụ trước và sau.
- Acceptance criteria là gì? Cách viết để QA kiểm thử được: Cách viết acceptance criteria rõ đến mức QA đọc xong là biết phải thử gì, kèm ví dụ mã giảm giá và mẫu dùng ngay.
- Ưu tiên backlog khi việc nào cũng gấp: chọn cách nào?: Cách chọn giữa value vs effort, MoSCoW và RICE, tách hạn chót thật khỏi cảm giác gấp, và gửi stakeholder một ghi chú ưu tiên một trang.
- Cách nói không với sếp và stakeholder mà không mất lòng: Ba cách nói không thay cho một chữ “không”, cách xử lý khi người yêu cầu là sếp hoặc CEO, lúc nào nên escalate, kèm hội thoại mẫu và tin nhắn theo từng cấp.