Mở đầu — vì sao bài này quan trọng
Nếu phải chọn ra một "vật phẩm" (artifact) mà người Product Owner (PO) gắn bó nhất mỗi ngày, thì đó chính là Product Backlog. Trong đề thi PSPO I, đây là một trong những chủ đề xuất hiện dày đặc nhất — và cũng là nơi nhiều thí sinh trượt điểm vì hiểu sai những điều tưởng chừng đơn giản. Bạn có biết: ai là người được phép thêm item vào Product Backlog? Ai là người quyết định thứ tự? PO có bắt buộc phải tự tay viết từng item không? Một Product Backlog có cần "hoàn chỉnh" trước khi Sprint đầu tiên bắt đầu không?
Những câu hỏi này nghe quen, nhưng nếu trả lời theo "cảm giác công sở" ở nhiều công ty Việt Nam, bạn sẽ sai theo Scrum Guide. Bài học này tập trung riêng vào việc quản trị Product Backlog như một hoạt động sống — bản chất của nó, các thuộc tính, ai chịu trách nhiệm gì, và làm sao để nó luôn ở trạng thái "sẵn sàng tạo giá trị". Chúng ta sẽ không sa đà vào kỹ thuật sắp xếp thứ tự nâng cao hay refinement (những phần đó có bài riêng), mà đặt nền móng vững chắc để bạn hiểu Product Backlog là gì và bạn — với tư cách PO — làm gì với nó.
Hãy hình dung Product Backlog như "thực đơn sống" của nhà hàng. Không phải một văn bản đóng khung treo tường, mà là thứ liên tục được cập nhật theo mùa, theo phản hồi của thực khách, theo nguyên liệu sẵn có. Hiểu được tinh thần đó, bạn đã đi được nửa đường.
Khái niệm cốt lõi
Product Backlog là gì?
Theo Scrum Guide 2020, Product Backlog là một danh sách có thứ tự (ordered), nổi lên và phát triển liên tục (emergent), về những gì cần thiết để cải thiện sản phẩm. Nó là nguồn công việc duy nhất (single source of work) mà Scrum Team thực hiện.
Hãy bóc tách ba từ khóa quan trọng:
- Ordered (có thứ tự) — chú ý: Scrum Guide dùng từ "ordered" chứ không phải "prioritized" (ưu tiên). Đây là điểm tinh tế. "Prioritized" gợi ý chỉ sắp theo độ quan trọng. "Ordered" rộng hơn: PO có thể sắp xếp theo bất kỳ yếu tố nào hợp lý — giá trị, rủi ro, sự phụ thuộc kỹ thuật, cơ hội học hỏi, thời điểm thị trường. Có những item giá trị cực cao nhưng PO vẫn xếp sau, vì nó phụ thuộc một item kỹ thuật phải làm trước. Đề PSPO I rất thích "gài" chỗ này.
- Emergent (nổi lên dần) — Product Backlog không bao giờ hoàn chỉnh. Nó không phải bản đặc tả yêu cầu được "chốt" một lần rồi đóng băng. Khi sản phẩm và môi trường thay đổi, Product Backlog thay đổi theo. Điều này phản ánh trực tiếp tinh thần empiricism (kinh nghiệm chủ nghĩa) của Scrum.
- Single source of work (nguồn công việc duy nhất) — đây là quy tắc sống còn. Mọi việc mà Scrum Team làm để cải thiện sản phẩm đều phải bắt nguồn từ Product Backlog. Không có "kênh ngầm": sếp nhắn riêng Developer, khách hàng gọi điện thẳng cho lập trình viên, một task lén lút trong Jira nằm ngoài backlog... Tất cả những thứ đó phá vỡ tính minh bạch của Scrum.
Product Backlog Item (PBI) gồm những gì?
Một item trong backlog (thường gọi tắt là PBI) tối thiểu nên có: mô tả (description), thứ tự (order), kích thước/ước lượng (size), và giá trị (value). Lưu ý: đây là gợi ý về thuộc tính, không phải định dạng bắt buộc. PBI có thể là user story, có thể là một dòng mô tả tính năng, một bug, một spike nghiên cứu — Scrum không quy định format.
Ai chịu trách nhiệm gì? (Accountability)
Đây là phần thi cử "ăn điểm":
- Product Owner chịu trách nhiệm (accountable) về Product Backlog Management. Cụ thể PO đảm bảo: phát triển và truyền đạt rõ ràng Product Goal; tạo và truyền đạt rõ ràng các PBI; sắp xếp thứ tự (ordering) các PBI; và đảm bảo Product Backlog minh bạch, hiển thị, được hiểu (transparent, visible, understood).
- PO có thể ủy quyền (delegate) việc thực hiện những điều trên cho Developers hoặc người khác, nhưng PO vẫn là người chịu trách nhiệm cuối cùng. Ví dụ: Developers có thể viết PBI giúp PO, nhưng PO chịu trách nhiệm về backlog đó.
- Toàn bộ Scrum Team cộng tác trong việc làm mịn backlog (refinement). Developers ước lượng size — không phải PO áp đặt con số. Nguyên tắc vàng: người làm việc là người ước lượng.
- Một điểm rất hay bị hiểu sai: chỉ Product Owner có quyền quyết định thứ tự cuối cùng và quyết định item nào vào backlog. Bất kỳ ai cũng có thể đề xuất thay đổi, nhưng để thay đổi được áp dụng, họ phải thuyết phục PO. PO là "một người duy nhất", không phải một ủy ban (committee).
Bốn thuộc tính cần đảm bảo
Một Product Backlog được quản trị tốt phải minh bạch (transparent) — phản ánh trung thực hiện trạng; hiển thị (visible) — mọi người liên quan đều xem được; được hiểu (understood) — các bên đọc và hiểu đúng ý nghĩa item; và gọn ở phần trên, thô ở phần dưới — các item gần đầu được làm mịn chi tiết, item xa cuối thì thô và lớn (chúng ta sẽ đào sâu cơ chế làm mịn này ở bài về Refinement).
Tình huống thực tế
Tình huống 1 — Tiki và "cái backlog 700 item"
Một nhóm phát triển tính năng thanh toán tại một sàn thương mại điện tử lớn của Việt Nam (gọi là "TechMart" cho an toàn, mô phỏng bối cảnh kiểu Tiki/Shopee) có một Product Backlog phình lên tới hơn 700 item. PO mới nhận bàn giao và hoảng: nhiều item từ 2 năm trước, mô tả mơ hồ kiểu "cải thiện UX trang checkout", trùng lặp, có cả tính năng cho một thị trường đã đóng.
PO quyết định một việc đơn giản nhưng đúng tinh thần Scrum: một Product Backlog "minh bạch" không phải là backlog đầy đủ, mà là backlog trung thực. Anh tổ chức một buổi "dọn vườn": gộp các item trùng, xóa thẳng 300+ item không còn liên quan, và kéo những item thực sự sắp làm lên đầu để làm mịn. Sau hai tuần, backlog còn 180 item nhưng hữu dụng.
Bài học: Backlog dài không đồng nghĩa với backlog tốt. Một backlog phình to với item "rác" thực ra phá vỡ tính minh bạch — vì nó tạo ảo giác về khối lượng công việc và che lấp những thứ thật sự quan trọng. Việc xóa item không phải là "lãng phí công sức cũ"; giữ lại item vô nghĩa mới là lãng phí sự chú ý của cả team.
Tình huống 2 — "Sếp nhắn riêng" tại một startup fintech ở TP.HCM
Tại một startup fintech, CEO có thói quen nhắn Zalo trực tiếp cho một Developer giỏi: "Em làm gấp cho anh tính năng X nhé, khách VIP đang đợi." Developer nể sếp, làm luôn. Kết quả: Sprint Goal trượt, các item PO đã sắp thứ tự kỹ càng bị xáo trộn, và PO không hề biết tại sao tiến độ chệch.
Khi áp dụng đúng nguyên tắc Product Backlog là nguồn công việc duy nhất, Scrum Master đã làm rõ với CEO: mọi yêu cầu — kể cả của sếp — đều phải đi vào Product Backlog và do PO sắp xếp thứ tự. CEO vẫn có quyền lực: ông là một stakeholder cực kỳ quan trọng, ông có thể thuyết phục PO đẩy tính năng X lên đầu. Nhưng ông không có quyền tiêm việc thẳng vào tay Developer ngoài backlog.
Bài học: Quy tắc "nguồn công việc duy nhất" không phải để cản trở kinh doanh, mà để bảo vệ tính minh bạch và khả năng inspect & adapt. Khi mọi việc đi qua một cổng (PO + Product Backlog), team mới nhìn được toàn cảnh để ra quyết định đánh đổi (trade-off) tỉnh táo. Trong môi trường VN nơi văn hóa "sếp nói là làm" còn phổ biến, đây là cuộc chiến khó nhưng đáng giá của PO và Scrum Master.
Tình huống 3 — PO áp ước lượng tại một công ty outsourcing ở Đà Nẵng
Một công ty gia công phần mềm có PO (kiêm quản lý dự án theo kiểu cũ) tự điền story point cho từng PBI rồi đưa Developers "cứ thế mà làm". Khi team liên tục không hoàn thành những gì đã forecast, ban lãnh đạo trách Developers "làm chậm". Sự thật: các con số ước lượng do PO áp đặt không phản ánh độ phức tạp kỹ thuật thật.
Sau khi điều chỉnh để Developers tự ước lượng size và PO chỉ chịu trách nhiệm về order và value, độ chính xác của forecast cải thiện rõ. Lý do đơn giản: người thực sự làm mới hiểu công việc nặng nhẹ thế nào.
Bài học: Trong Product Backlog Management có sự phân vai rõ. PO quyết làm gì trước, vì sao có giá trị; Developers quyết làm nó tốn bao nhiêu công. Lẫn lộn hai vai trò này là một anti-pattern kinh điển.
Hướng dẫn từng bước
Dưới đây là quy trình thực tế để PO quản trị một Product Backlog lành mạnh. (Lưu ý: đây là cách vận hành backlog hằng ngày; kỹ thuật ordering nâng cao và workshop refinement có bài riêng.)
- Neo backlog vào Product Goal. Trước khi thêm bất kỳ item nào, hãy hỏi: "Item này có phục vụ mục tiêu sản phẩm hiện tại không?" Product Goal là cái đích mà backlog đang hướng tới. Item không phục vụ goal nào thì nên cân nhắc kỹ.
- Thu thập đầu vào từ mọi nguồn — nhưng đổ về một chỗ. Yêu cầu từ stakeholder, phản hồi user, ý tưởng từ Developers, bug từ vận hành... tất cả đề xuất đều được, nhưng cuối cùng PO là người quyết định item nào thực sự vào backlog.
- Diễn đạt item đủ rõ để team hiểu. Item càng gần đầu danh sách càng cần rõ ràng. Item ở xa cuối có thể chỉ là một dòng ý tưởng thô.
- Sắp xếp thứ tự (order), không chỉ ưu tiên. Cân nhắc giá trị, rủi ro, sự phụ thuộc, cơ hội học hỏi. PO ra quyết định cuối cùng về thứ tự.
- Để Developers ước lượng size. PO cung cấp ngữ cảnh và giá trị; Developers cho biết độ lớn/độ phức tạp.
- Giữ backlog minh bạch và hiển thị. Đảm bảo mọi bên liên quan đều truy cập được (qua Jira, Azure DevOps, Trello, hay thậm chí bảng giấy) và hiểu đúng ý nghĩa các item.
- Liên tục tỉa và cập nhật. Khi học được điều mới (từ Sprint Review, từ thị trường), hãy thêm/sửa/xóa/sắp lại. Backlog là vật sống.
Lỗi thường gặp & mẹo
- Nhầm "ordered" với "prioritized". Đề thi PSPO I cố tình dùng từ "prioritized" để gài. Hãy nhớ: backlog được ordered, và order có thể dựa trên nhiều yếu tố ngoài độ quan trọng thuần túy.
- Tưởng PO phải tự viết mọi PBI. Sai. PO chịu trách nhiệm, nhưng có thể ủy quyền việc viết item cho Developers hay người khác. Accountability ≠ phải tự tay làm tất cả.
- Tưởng backlog phải hoàn chỉnh trước Sprint 1. Sai. Backlog chỉ cần đủ item đã làm mịn cho Sprint Planning đầu tiên là khởi động được. Phần còn lại nổi lên dần.
- Để công việc đi vòng ngoài backlog. Mọi "task ngầm" phá vỡ tính minh bạch. Kéo tất cả vào backlog.
- PO áp đặt story point. Hãy để người làm ước lượng. PO giữ phần value và order.
- Coi backlog là kho chứa vô hạn. Mẹo: định kỳ "dọn vườn", mạnh dạn xóa item chết. Một backlog gọn gàng minh bạch hơn một backlog đồ sộ.
- Quên rằng chỉ có một PO ra quyết định. Để có tính nhất quán, quyền quyết định nội dung và thứ tự backlog thuộc về một PO, không phải nhóm hay ủy ban. Nhiều người có thể ảnh hưởng, nhưng phải qua PO.
- Mẹo "đủ rõ ở đỉnh": không cần làm mịn cả 200 item. Chỉ cần phần trên của backlog (những thứ sắp làm) đủ chi tiết để team bắt tay vào việc.
Bài tập thực hành
- Phân biệt accountability: Với mỗi hoạt động sau, ghi xem ai chịu trách nhiệm cuối cùng và ai có thể thực hiện: (a) viết mô tả PBI; (b) quyết định thứ tự backlog; (c) ước lượng size; (d) đảm bảo backlog minh bạch. Đối chiếu với phần Khái niệm cốt lõi.
- Tình huống ra quyết định: Giám đốc Marketing yêu cầu bạn (PO) chèn ngay một tính năng vào đầu backlog vì "chiến dịch quảng cáo tuần sau cần". Hãy viết 4–5 câu mô tả bạn sẽ phản hồi thế nào để vừa tôn trọng stakeholder, vừa giữ đúng nguyên tắc PO là người quyết định thứ tự cuối cùng.
- Audit backlog: Lấy một backlog thật (hoặc giả định) gồm 20 item. Đánh dấu: item nào trùng lặp, item nào mơ hồ cần làm rõ, item nào không phục vụ Product Goal nào. Đề xuất hành động (gộp/xóa/làm mịn) cho từng nhóm.
- Câu hỏi tự kiểm tra (đúng/sai): (a) "Product Backlog phải hoàn chỉnh trước khi bắt đầu Sprint." (b) "Developers có thể giúp PO viết và làm mịn PBI." (c) "PO là người quyết định story point của mỗi item." (d) "Mọi công việc của Scrum Team đến từ Product Backlog." Tự trả lời rồi đối chiếu với bài.
Tóm tắt
- Product Backlog là danh sách có thứ tự (ordered), nổi lên liên tục (emergent), là nguồn công việc duy nhất của Scrum Team. Nó không bao giờ "hoàn chỉnh".
- Chú ý từ "ordered" (không phải "prioritized"): PO sắp xếp dựa trên nhiều yếu tố — giá trị, rủi ro, phụ thuộc, cơ hội học hỏi.
- PO chịu trách nhiệm (accountable) về Product Backlog Management: phát triển Product Goal, tạo và diễn đạt PBI, sắp xếp thứ tự, và giữ backlog minh bạch, hiển thị, được hiểu.
- PO có thể ủy quyền việc thực hiện, nhưng vẫn chịu trách nhiệm cuối cùng. Chỉ một PO ra quyết định nội dung và thứ tự — không phải ủy ban.
- Developers ước lượng size (người làm việc là người ước lượng); PO giữ phần value và order.
- Quản trị tốt nghĩa là giữ backlog trung thực và gọn gàng, không phải đồ sộ. Mọi việc đi qua một cổng để bảo vệ tính minh bạch và khả năng inspect & adapt.