Mở đầu — vì sao bài này quan trọng
Nếu bạn để ý kỹ cấu trúc của Scrum Guide 2020, bạn sẽ thấy có một sự đối xứng rất đẹp: mỗi Artifact (sản phẩm bàn giao trung gian) được "ghép đôi" với đúng một Commitment (cam kết). Sprint Backlog gắn với Sprint Goal, Increment gắn với Definition of Done, và Product Backlog gắn với Product Goal. Bài 17 này là bài đầu tiên trong nhóm ba bài về Artifacts, và Product Backlog chính là điểm khởi đầu của toàn bộ dòng chảy công việc trong Scrum.
Tại sao bạn phải nắm thật chắc Product Backlog cho kỳ thi PSM I? Bởi vì đây là khái niệm bị hiểu sai nhiều nhất trên thực tế. Rất nhiều người làm Scrum nhiều năm vẫn tin rằng Product Backlog là "một danh sách yêu cầu cố định do sếp giao", hoặc "một cái kho chứa mọi thứ ai cũng có thể vứt việc vào". Cả hai cách hiểu đó đều khiến bạn mất điểm trong phòng thi và làm sai trong thực tế. Đề thi PSM I rất thích những câu hỏi tinh vi về ai sở hữu (ownership), ai sắp xếp thứ tự (ordering), tính chất emergent (luôn biến đổi), và mối quan hệ với Product Goal.
Trong bài này, tôi sẽ giảng cho bạn đúng "theo sách" — vì đó là cách PSM I chấm điểm — nhưng đồng thời gắn với những tình huống thật để bạn không chỉ thuộc lòng mà còn hiểu bản chất. Lưu ý: bài này chỉ tập trung vào Product Backlog với tư cách Artifact và mối quan hệ với Product Goal ở mức cơ bản. Phần Product Goal sâu sẽ ở Bài 21, Sprint Backlog ở Bài 18, và kỹ thuật Refinement ở Bài 33 — tôi sẽ không lấn sang các bài đó.
Khái niệm cốt lõi
Định nghĩa chuẩn theo Scrum Guide 2020
Scrum Guide định nghĩa Product Backlog là: "An emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team."
Hãy mổ xẻ từng chữ, vì mỗi từ đều có thể trở thành một câu hỏi thi:
- Emergent (liên tục nổi lên, biến đổi): Product Backlog không bao giờ "hoàn thành". Nó sống và thay đổi liên tục để phản ánh điều mà sản phẩm cần để trở nên giá trị hơn. Khi thị trường đổi, khi học được điều mới về khách hàng, Product Backlog đổi theo. Đây là điểm hoàn toàn ngược với tư duy "viết một bản đặc tả yêu cầu đầy đủ ngay từ đầu rồi đóng băng nó".
- Ordered (được sắp thứ tự), không phải "prioritized" (ưu tiên). Đây là một bẫy thi kinh điển. Scrum dùng từ "ordered" có chủ đích: danh sách có một thứ tự duy nhất từ trên xuống dưới. Thứ tự đó có thể dựa trên giá trị, nhưng cũng có thể dựa trên rủi ro, sự phụ thuộc kỹ thuật, học hỏi... "Priority" chỉ là một trong nhiều yếu tố. Đáp án đúng trong phòng thi gần như luôn là "ordered".
- Single source of work (nguồn công việc duy nhất): Mọi việc mà Scrum Team thực hiện đều bắt nguồn từ Product Backlog. Không có "danh sách việc bí mật" nào bên cạnh.
Ai sở hữu Product Backlog?
Product Owner chịu trách nhiệm (accountable) cho Product Backlog, bao gồm nội dung, tính khả dụng (availability) và thứ tự của các mục. Đây là điểm cực kỳ quan trọng cho PSM I.
Hãy phân biệt rõ:
- Product Owner chịu trách nhiệm cho việc sắp xếp thứ tự. Đây là accountability không thể chuyển nhượng.
- Nhưng Product Owner có thể ủy quyền việc thực hiện cụ thể (ví dụ để Developers viết một số mục), nhưng vẫn giữ accountability.
- Developers là người ước lượng (sizing/estimating) các mục — Product Owner không được áp đặt con số ước lượng cho Developers.
Product Backlog Item (PBI) là gì?
Mỗi dòng trong Product Backlog là một Product Backlog Item. Scrum Guide cố tình KHÔNG quy định PBI phải có hình thức gì. Nó không bắt buộc phải là "User Story". Nó có thể là tính năng, bản sửa lỗi, cải tiến kỹ thuật, công việc nghiên cứu (spike)... Việc dùng User Story chỉ là một kỹ thuật tùy chọn (tôi sẽ nói kỹ ở Bài 34).
Một đặc điểm thực dụng: các mục ở đỉnh danh sách (sẽ làm sớm) thường nhỏ, rõ ràng, chi tiết và đã được ước lượng. Các mục ở đáy danh sách thường to, mơ hồ hơn. Đây là kết quả tự nhiên của hoạt động Refinement diễn ra liên tục.
Commitment của Product Backlog: Product Goal
Scrum Guide 2020 bổ sung khái niệm Commitment cho mỗi Artifact để tăng tính minh bạch và sự tập trung. Commitment của Product Backlog là Product Goal.
Product Goal là mục tiêu dài hạn mà Scrum Team hướng tới — một trạng thái tương lai của sản phẩm dùng làm đích ngắm. Product Backlog emerges để định nghĩa "phần việc cần làm" nhằm đạt Product Goal. Một sản phẩm có một Product Goal tại một thời điểm; Scrum Team phải hoàn thành (hoặc từ bỏ) một Product Goal trước khi nhận một cái mới.
Ở bài này bạn chỉ cần nhớ mối quan hệ: Product Goal nằm bên trong Product Backlog, là kim chỉ nam cho toàn bộ việc sắp xếp và lựa chọn mục. Phân tích sâu Product Goal là việc của Bài 21.
Refinement — nhắc ngắn, không lấn sân
Product Backlog Refinement là hoạt động liên tục để chia nhỏ, làm rõ và bổ sung chi tiết cho các mục. Điểm bạn cần ghi nhớ ngay tại đây: Refinement không phải là một Scrum Event và không có timebox cố định trong Scrum Guide. Nó là một activity ongoing. Chi tiết để dành cho Bài 33.
Tình huống thực tế
Tình huống 1 — Tiki và cái "kho rác" Product Backlog
Hãy tưởng tượng một đội 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 như Tiki. Ban đầu, đội này có một Product Backlog với hơn 800 mục, tích lũy suốt hai năm. Bất kỳ ai trong công ty — bộ phận marketing, chăm sóc khách hàng, kế toán — đều có thể tạo ticket và "ném" vào backlog. Không ai xóa gì cả vì sợ "mất thông tin".
Kết quả: Product Owner mất khả năng nhìn thấy điều gì thực sự quan trọng. Mỗi buổi Sprint Planning trở thành một cuộc tranh cãi về việc "mục này có còn liên quan không". 60% số mục đã lỗi thời vì sản phẩm đã thay đổi.
Diễn giải: Đội này đã quên hai tính chất cốt lõi. Thứ nhất, Product Backlog là emergent — nó phải phản ánh hiện tại, nên các mục lỗi thời cần được loại bỏ thẳng tay, không phải "lưu trữ vĩnh viễn". Thứ hai, Product Owner phải thực sự sở hữu thứ tự, chứ không để backlog biến thành nơi mọi người tự do đổ việc. Việc ai đó đề xuất một mục là tốt; nhưng quyết định mục đó có vào backlog hay không, và nằm ở đâu, là của Product Owner.
Bài học: Một Product Backlog tốt thường gọn hơn bạn tưởng. Nếu đáy danh sách chứa hàng trăm mục mà cả năm không bao giờ được chạm tới, đó là dấu hiệu của một "kho rác" chứ không phải một Artifact minh bạch.
Tình huống 2 — Startup fintech ở Singapore và bài học "ordered ≠ prioritized"
Một startup fintech tại Singapore xây dựng ứng dụng ví điện tử cho thị trường Đông Nam Á. Product Owner — tạm gọi là chị Mei — sắp xếp Product Backlog hoàn toàn theo "giá trị kinh doanh": tính năng nào mang lại doanh thu cao nhất thì lên đầu. Theo logic đó, mục "tích hợp chương trình hoàn tiền cashback" được đưa lên đỉnh.
Nhưng Developers chỉ ra một vấn đề: tính năng cashback phụ thuộc vào module xác thực danh tính KYC (Know Your Customer) chưa được xây. Nếu làm cashback trước, đội sẽ bị kẹt giữa Sprint. Ngoài ra, có một rủi ro pháp lý lớn cần được kiểm chứng sớm: liệu giấy phép tại Indonesia có cho phép giữ số dư của người dùng không.
Chị Mei điều chỉnh thứ tự: đưa một spike nghiên cứu pháp lý và module KYC lên trên cashback — dù cashback "có giá trị cao hơn".
Diễn giải: Đây chính là minh họa sống động cho lý do Scrum dùng từ ordered thay vì prioritized. Thứ tự của Product Backlog phải cân nhắc đồng thời giá trị, rủi ro, sự phụ thuộc và cơ hội học hỏi. Một mục có thể nằm cao không phải vì giá trị tức thời lớn nhất, mà vì làm nó trước giúp giảm rủi ro hoặc mở khóa cho các mục khác.
Bài học: Khi gặp câu hỏi thi kiểu "Yếu tố duy nhất quyết định thứ tự Product Backlog là giá trị kinh doanh — đúng hay sai?", đáp án là SAI. Giá trị là một yếu tố quan trọng nhưng không phải duy nhất.
Tình huống 3 — Đội nội bộ của một ngân hàng Việt và mối quan hệ với Product Goal
Một đội thuộc khối ngân hàng số của một ngân hàng tại TP.HCM được giao xây dựng tính năng "mở tài khoản tiết kiệm online trong 5 phút". Họ đặt Product Goal: "Giúp khách hàng cá nhân mở và kích hoạt tài khoản tiết kiệm hoàn toàn online, không cần ra quầy, với tỷ lệ hoàn thành trên 80%."
Trước khi có Product Goal rõ ràng, Product Backlog của họ lẫn lộn đủ thứ: vài mục về tiết kiệm, vài mục về vay tiêu dùng, vài mục về thẻ tín dụng — vì "tiện thì làm luôn". Sau khi chốt Product Goal, Product Owner rà soát lại toàn bộ backlog và mạnh dạn gỡ những mục không phục vụ mục tiêu này ra (chuyển sang một danh sách ý tưởng riêng, không phải Product Backlog đang hoạt động). Backlog từ 140 mục co lại còn 45 mục thực sự liên quan.
Hệ quả: mỗi Sprint, đội biết chính xác mình đang đóng góp gì cho mục tiêu lớn. Khi một mục mới được đề xuất, câu hỏi đầu tiên trở thành: "Mục này có giúp đạt Product Goal không?"
Diễn giải: Product Goal đóng vai trò bộ lọc và kim chỉ nam cho Product Backlog. Product Backlog emerges để định nghĩa công việc cần làm nhằm đạt Product Goal. Khi mối quan hệ này được tôn trọng, backlog trở nên tập trung và minh bạch.
Bài học: Một Product Backlog thiếu Product Goal dễ trở thành tập hợp rời rạc của những việc "ai cũng thấy hay". Commitment (Product Goal) chính là thứ tạo nên sự gắn kết.
Hướng dẫn từng bước
Dưới đây là cách tư duy về một Product Backlog "khỏe mạnh" theo đúng tinh thần Scrum. Đây không phải quy trình bắt buộc của Scrum (Scrum không quy định "cách làm" chi tiết), mà là hướng dẫn thực hành để bạn vừa thi tốt vừa làm tốt.
- Xác lập Product Goal trước. Trước khi nói chuyện sắp xếp từng mục, Scrum Team cần một Product Goal rõ ràng. Đây là đích để mọi mục trong backlog hướng về.
- Thu thập và biểu diễn nhu cầu thành các PBI. Mỗi nhu cầu — từ stakeholder, từ dữ liệu sử dụng, từ phản hồi trong Sprint Review — được ghi thành một mục. Đừng câu nệ định dạng; quan trọng là rõ ý.
- Sắp xếp thứ tự (order), không chỉ ưu tiên. Product Owner đặt thứ tự dựa trên tổ hợp giá trị, rủi ro, sự phụ thuộc, và cơ hội học hỏi. Mục nào làm sớm thì lên trên.
- Để Developers ước lượng. Những người sẽ làm việc đó là người ước lượng kích thước. Product Owner cung cấp ngữ cảnh kinh doanh để giúp đánh đổi, nhưng không áp số.
- Refinement liên tục để các mục ở đỉnh đủ "ready". Chia nhỏ mục to thành mục nhỏ, làm rõ, bổ sung chi tiết — sao cho các mục sắp được chọn vào Sprint đủ minh bạch để đội tự tin nhận. (Chi tiết kỹ thuật ở Bài 33.)
- Giữ backlog emergent. Định kỳ loại bỏ mục lỗi thời, cập nhật theo điều mới học được. Một backlog không bao giờ thay đổi là một dấu hiệu cảnh báo.
- Đảm bảo minh bạch và khả dụng. Mọi thành viên Scrum Team — và lý tưởng là cả stakeholder liên quan — có thể nhìn thấy Product Backlog. Đây là Artifact, mà Artifact tồn tại để tạo Transparency.
Lỗi thường gặp & mẹo
Lỗi 1 — Nghĩ Product Backlog là một bản đặc tả cố định. Sai. Nó emergent, biến đổi liên tục. Mẹo nhớ: nếu backlog của bạn không thay đổi suốt nhiều Sprint, nó đang "chết".
Lỗi 2 — Nhầm "ordered" với "prioritized". Trong phòng thi, khi thấy lựa chọn giữa hai từ này, gần như luôn chọn "ordered". Thứ tự cân nhắc nhiều yếu tố, không chỉ độ ưu tiên.
Lỗi 3 — Tin rằng Scrum Master hoặc cả team sở hữu thứ tự backlog. Không. Product Owner chịu accountability cho nội dung và thứ tự. Scrum Master chỉ hỗ trợ, huấn luyện về kỹ thuật Refinement và quản lý backlog — không quyết định thứ tự thay PO.
Lỗi 4 — Tin rằng PBI bắt buộc phải là User Story. Sai. Scrum không quy định định dạng PBI. User Story chỉ là một kỹ thuật tùy chọn.
Lỗi 5 — Lẫn lộn Product Backlog với Sprint Backlog. Product Backlog là toàn bộ việc cần để cải thiện sản phẩm (thuộc về cả vòng đời sản phẩm). Sprint Backlog là tập con việc đội chọn cho một Sprint cộng với kế hoạch thực hiện. Một bẫy thi kinh điển — sẽ được mổ xẻ riêng ở Bài 45.
Lỗi 6 — Để ai cũng tự thêm mục vào backlog mà không qua Product Owner. Stakeholder có thể đề xuất; nhưng quyết định mục có vào backlog và nằm ở đâu là của Product Owner.
Mẹo ghi nhớ nhanh cho phòng thi:
- Product Backlog = Artifact, Commitment = Product Goal.
- Emergent + ordered + single source of work.
- Owner thứ tự = Product Owner. Ước lượng = Developers.
- Không bao giờ "hoàn thành", không có định dạng bắt buộc.
Bài tập thực hành
- Phân biệt thuật ngữ: Viết ra bằng lời của bạn sự khác nhau giữa "ordered" và "prioritized", kèm một ví dụ trong đó mục có giá trị thấp hơn lại được xếp lên trên (gợi ý: nghĩ về rủi ro hoặc sự phụ thuộc).
- Soi backlog thật: Nếu bạn đang làm trong một đội, hãy lấy 10 mục ở đáy Product Backlog của đội bạn. Bao nhiêu mục trong đó còn thực sự liên quan đến Product Goal hiện tại? Nếu nhiều mục đã lỗi thời, đó là dữ liệu để bạn thảo luận với Product Owner.
- Câu hỏi tự kiểm tra (tự trả lời rồi đối chiếu với bài):
- Tình huống ra quyết định: Một stakeholder yêu cầu chèn một tính năng "rất gấp" vào đầu Product Backlog, vượt qua cả những mục đang phục vụ Product Goal. Theo Scrum, ai là người quyết định cuối cùng việc mục này có được chèn lên không, và họ nên cân nhắc điều gì? Viết câu trả lời khoảng 4–5 câu.
Tóm tắt
Product Backlog là Artifact đầu tiên trong ba Artifact của Scrum, và là nguồn công việc duy nhất của Scrum Team. Hãy khắc cốt ghi tâm định nghĩa: nó emergent (luôn biến đổi), ordered (được sắp thứ tự, không chỉ ưu tiên), và là single source of work to improve the product. Product Owner chịu accountability cho nội dung, tính khả dụng và thứ tự; Developers là người ước lượng kích thước công việc. PBI không có định dạng bắt buộc — User Story chỉ là một lựa chọn.
Commitment đi cùng Product Backlog là Product Goal — đích dài hạn để toàn bộ backlog hướng về và làm bộ lọc cho việc chọn lựa, sắp xếp các mục. Một Product Backlog khỏe mạnh thì gọn, minh bạch, liên tục được làm tươi, và luôn phục vụ Product Goal — chứ không phải một "kho rác" tích lũy mọi ý tưởng.
Cho kỳ thi PSM I, hãy cảnh giác với các bẫy về ownership, về "ordered vs prioritized", và về việc nhầm Product Backlog với Sprint Backlog. Nắm chắc bài này, bạn đã có nền tảng vững để bước sang Bài 18 (Sprint Backlog) và Bài 21 (Product Goal sâu).