Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi mười Product Owner "Product Backlog là gì?", chín người sẽ trả lời: "Là danh sách những việc cần làm." Câu trả lời đó không sai, nhưng nó hời hợt đến mức nguy hiểm. Nó giống như nói "ngân sách quốc gia là một danh sách các khoản chi" — đúng về mặt câu chữ nhưng bỏ qua toàn bộ bản chất của thứ đang được nói tới.
Trong kỳ thi PSPO I, Product Backlog là một trong những chủ đề bị hiểu sai nhiều nhất. Người ra đề rất thích "gài" những câu hỏi xoáy vào việc: Product Backlog có cố định không? Ai sở hữu nó? Nó có phải là một tài liệu yêu cầu (requirements document) được viết một lần rồi để đó không? Ai được phép thay đổi thứ tự các mục? Nếu bạn nắm chắc bản chất và đặc tính của Product Backlog, bạn sẽ trả lời đúng cả một cụm câu hỏi mà không cần học thuộc lòng.
Quan trọng hơn cả kỳ thi: trong công việc thực tế, cách bạn hiểu về Product Backlog quyết định cách bạn vận hành sản phẩm. Một PO coi Product Backlog là "danh sách việc cần làm cố định do sếp giao" sẽ vận hành sản phẩm như một nhà máy gia công. Một PO hiểu Product Backlog là một thực thể "sống", luôn thay đổi (emergent) và được sắp xếp theo giá trị (ordered) sẽ vận hành sản phẩm như một người thật sự dẫn dắt giá trị. Bài học này tập trung làm rõ bản chất và các đặc tính cốt lõi của Product Backlog — đây là nền móng cho rất nhiều bài sau (refinement, ordering, Product Goal) mà chúng ta sẽ học riêng.
Khái niệm cốt lõi
Định nghĩa theo Scrum Guide 2020
Theo Scrum Guide 2020, Product Backlog là một danh sách emergent (luôn nổi lên, luôn tiến hóa), được sắp xếp theo thứ tự (ordered) của 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 đọc lại định nghĩa đó thật chậm. Trong một câu ngắn, Scrum Guide đã nhét vào ba đặc tính then chốt mà bạn phải khắc cốt ghi tâm:
- Emergent — Product Backlog không bao giờ "hoàn thành". Nó liên tục thay đổi để phản ánh hiểu biết mới về sản phẩm, thị trường, công nghệ và khách hàng. Backlog của tháng này khác backlog của tháng trước, và điều đó là bình thường, là đáng mong đợi.
- Ordered — các mục trong backlog được sắp xếp theo thứ tự, không phải xếp ngẫu nhiên hay xếp theo thời gian nhập vào. Lưu ý từ "ordered" chứ không phải "prioritized" — đây là điểm tinh tế mà chúng ta sẽ đào sâu ở Bài 13.
- Single source of work — đây là nguồn công việc DUY NHẤT của Scrum Team. Không có "danh sách bí mật" nào khác, không có việc nào lọt vào Sprint mà không đi qua Product Backlog. Nếu một việc không có trên backlog, Developers không làm nó.
Product Backlog Item (PBI) là gì?
Mỗi dòng trong Product Backlog gọi là một Product Backlog Item (PBI). Một điểm rất quan trọng và hay bị hỏi trong thi: Scrum Guide KHÔNG quy định PBI phải có định dạng nào. PBI có thể là một User Story, một feature, một bug fix, một spike nghiên cứu kỹ thuật, một yêu cầu cải thiện hiệu năng... Định dạng là tùy chọn của team. User Story chỉ là một format phổ biến chứ không phải bắt buộc trong Scrum.
Các PBI ở phần trên cùng của backlog (sắp được làm) thường nhỏ, rõ ràng, được làm mịn kỹ (refined). Các PBI ở dưới đáy thường lớn, mơ hồ hơn. Hình ảnh kinh điển là một "tảng băng": phần đỉnh chi tiết và sẵn sàng, phần dưới ngày càng thô và lớn dần.
Ai sở hữu Product Backlog?
Product Owner chịu trách nhiệm về Product Backlog (accountable), bao gồm nội dung, sự sẵn có (availability) và thứ tự (ordering) của nó. Đây là tuyên bố nguyên văn trong Scrum Guide và là một trong những câu hỏi thi gần như chắc chắn xuất hiện.
Một sự tinh tế: PO chịu trách nhiệm, nhưng PO có thể ủy quyền (delegate) công việc quản lý backlog cho người khác — ví dụ nhờ Developers viết PBI kỹ thuật, nhờ Business Analyst soạn chi tiết. Tuy nhiên, trách nhiệm cuối cùng vẫn thuộc về PO. Delegate được công việc, không delegate được accountability. Trong bài thi, nếu một câu hỏi nói "PO nhờ team viết mô tả PBI", điều đó hoàn toàn hợp lệ; nhưng nếu nói "trách nhiệm về backlog chuyển sang Scrum Master", đó là sai.
Product Backlog gắn với một Product Goal
Scrum Guide 2020 đưa Product Goal vào như "commitment" của Product Backlog. Nghĩa là Product Backlog tồn tại để phục vụ một Product Goal — đích đến dài hạn của sản phẩm. Mọi PBI lý tưởng nên góp phần đưa sản phẩm tiến gần Product Goal hơn. Chúng ta sẽ học sâu về Product Goal ở Bài 9, nhưng ở đây bạn cần ghi nhớ: backlog không phải là một mớ việc rời rạc, nó có một "ngôi sao dẫn đường".
Đặc tính "single source" — vì sao nó quan trọng
Hãy hình dung một đội phát triển nhận việc từ năm nguồn: email của giám đốc, tin nhắn Zalo của sales, ticket trên Jira, yêu cầu miệng trong cuộc họp, và backlog chính thức. Đó là công thức của hỗn loạn. Không ai biết việc gì quan trọng hơn việc gì, Developers bị kéo bốn phương tám hướng, và không ai có cái nhìn toàn cảnh.
Nguyên tắc single source giải quyết chính xác vấn đề đó: mọi yêu cầu, dù đến từ đâu, đều phải được đưa vào Product Backlog và được PO sắp xếp thứ tự. Khi đó backlog trở thành "tấm bản đồ" duy nhất, minh bạch cho cả team lẫn stakeholder. Đây không phải là quan liêu hành chính — đây là kỷ luật giúp PO bảo vệ team khỏi sự xao nhãng và giúp tổ chức có một sự thật chung.
Tình huống thực tế
Tình huống 1: Sàn TMĐT "Tiệm Việt" và cái backlog đông cứng
Một startup TMĐT giả định ở TP.HCM tên "Tiệm Việt" có một PO mới tên Linh. Khi nhận việc, Linh được bàn giao một file Excel 380 dòng mang tên "Yêu cầu sản phẩm 2025", do giám đốc soạn từ đầu năm. Mọi người gọi đó là "backlog". Suốt sáu tháng, đội dev cắm đầu làm từ trên xuống dưới theo đúng thứ tự file.
Vấn đề bộc lộ khi đối thủ tung tính năng "mua trước trả sau" và tỷ lệ bỏ giỏ hàng của Tiệm Việt tăng vọt lên 71%. Đội dev lúc đó vẫn đang làm dòng số 142: "đổi màu nút yêu thích sang hồng". Khi Linh đề nghị chèn việc xử lý giỏ hàng lên đầu, giám đốc gạt đi: "Backlog đã chốt từ đầu năm rồi, cứ làm theo thứ tự."
Diễn giải: Tổ chức này đã biến Product Backlog từ một thực thể emergent thành một tài liệu yêu cầu đông cứng (frozen requirements document). Họ đánh mất đặc tính quan trọng nhất — khả năng tiến hóa theo hiểu biết mới. Một backlog không thay đổi được khi thị trường thay đổi thì về bản chất không còn là Product Backlog theo nghĩa Scrum nữa.
Bài học: Product Backlog phải emergent. Việc thị trường thay đổi và backlog phải được sắp xếp lại không phải là dấu hiệu PO "lập kế hoạch kém", mà chính là cơ chế Scrum được thiết kế để vận hành. PO phải có thẩm quyền điều chỉnh thứ tự backlog dựa trên giá trị, và tổ chức phải tôn trọng điều đó.
Tình huống 2: Fintech "MoMoney" và năm nguồn việc
Một công ty fintech giả định "MoMoney" ở Hà Nội có đội 8 Developers. PO tên Tuấn nhận thấy đội liên tục trễ Sprint dù làm rất chăm. Khi điều tra, Tuấn phát hiện ngoài backlog chính thức trên Jira, Developers còn nhận việc trực tiếp: trưởng phòng vận hành nhắn Telegram nhờ "sửa nhanh báo cáo cuối ngày", một kỹ sư senior tự thêm task refactor, và bộ phận chăm sóc khách hàng gửi email lỗi thẳng cho một dev quen.
Kết quả: trong mỗi Sprint, khoảng 30% năng lực của team bị tiêu cho công việc không nằm trên backlog, không ai theo dõi, và Sprint Goal thường xuyên lỡ.
Tuấn áp dụng nguyên tắc single source: mọi yêu cầu, từ bất kỳ ai, phải vào Product Backlog. Anh tạo một "cửa tiếp nhận" duy nhất, refine và sắp xếp các yêu cầu đó theo giá trị. Sau hai Sprint, tỷ lệ hoàn thành Sprint Goal tăng từ 50% lên trên 85%, và quan trọng hơn, lần đầu tiên ban lãnh đạo nhìn thấy bức tranh đầy đủ về những gì đội đang gánh.
Diễn giải & bài học: Đặc tính single source không phải là rào cản hành chính, mà là công cụ bảo vệ sự tập trung và tạo minh bạch. Khi mọi việc đều đi qua một backlog duy nhất do PO sắp xếp, tổ chức mới có thể đưa ra quyết định đánh đổi (trade-off) một cách tỉnh táo, thay vì để "ai la to thì việc nấy được làm".
Tình huống 3: Backlog "tảng băng" tại một team ở Grab
Tại một đội sản phẩm giả định trong môi trường công ty công nghệ lớn kiểu Grab, PO tên Mai duy trì một backlog gọn gàng theo mô hình "tảng băng". Mười PBI trên cùng đều nhỏ, có acceptance criteria rõ, ước tính xong, sẵn sàng cho 2 Sprint tới. Phần giữa là các feature cỡ vừa đang được refine dần. Phần đáy chỉ là vài dòng ý tưởng thô như "Cá nhân hóa màn hình chủ" hay "Tích hợp ví tỉnh".
Một PO ở đội khác từng chê Mai "lười", vì backlog của Mai chỉ có khoảng 60 mục trong khi đội kia có 600 mục được mô tả chi tiết tới tận đáy. Sáu tháng sau, đội kia phải vứt bỏ hơn 200 mục đã viết chi tiết vì chiến lược sản phẩm đổi hướng — toàn bộ công sức viết chi tiết đó thành lãng phí.
Diễn giải & bài học: Một Product Backlog tốt KHÔNG phải là backlog dài và chi tiết nhất. Việc làm chi tiết quá sâu cho các mục còn xa (trong khi tương lai còn nhiều bất định) chính là một dạng lãng phí — bạn đầu tư công sức vào thứ rất có thể sẽ thay đổi hoặc bị bỏ. Đặc tính emergent cho phép chúng ta chỉ chi tiết hóa "vừa đủ, vừa kịp" (just enough, just in time). Backlog của Mai mỏng ở đáy không phải vì lười, mà vì kỷ luật.
Hướng dẫn từng bước
Dưới đây là cách thiết lập và duy trì một Product Backlog đúng bản chất Scrum. Lưu ý: các kỹ thuật chuyên sâu về refinement và ordering sẽ được học riêng ở Bài 12 và Bài 13; ở đây ta tập trung vào việc dựng nền móng đúng đắn.
- Xác định nguồn duy nhất. Chọn một công cụ (Jira, Azure DevOps, Trello, thậm chí một bảng tính) làm nơi chứa Product Backlog chính thức. Tuyên bố rõ với cả team và stakeholder: đây là single source, mọi yêu cầu đều đi qua đây.
- Neo backlog vào Product Goal. Viết rõ Product Goal hiện tại ở vị trí dễ thấy. Mỗi khi thêm PBI, tự hỏi: "Mục này có giúp tiến tới Product Goal không?" Nếu không, hãy cân nhắc kỹ trước khi đưa vào hoặc xếp nó xuống thấp.
- Đảm bảo mỗi PBI đủ thông tin để hữu ích. Một PBI tốt thường nên có: mô tả ngắn (cái gì, cho ai, vì sao), một thước đo giá trị, và (với các mục ở trên cùng) tiêu chí chấp nhận. Đừng ép một format cứng nhắc — chọn cái phù hợp với team.
- Sắp xếp theo thứ tự, không chỉ theo mức ưu tiên. Backlog là một danh sách có thứ tự tuyến tính — mục số 1, số 2, số 3... PO quyết định trật tự này dựa trên giá trị, rủi ro, sự phụ thuộc và cơ hội học hỏi.
- Giữ hình dạng "tảng băng". Chi tiết hóa kỹ phần trên cùng (đủ cho 1–2 Sprint tới), để phần dưới thô và lớn. Kháng lại cám dỗ viết chi tiết tới tận đáy.
- Liên tục cập nhật (embrace emergence). Sau mỗi Sprint Review, mỗi feedback khách hàng, mỗi thay đổi thị trường, hãy điều chỉnh backlog. Thêm, sửa, xóa, sắp xếp lại. Một backlog không thay đổi trong nhiều tuần là một dấu hiệu đáng ngờ.
- Đảm bảo tính minh bạch (transparency). Backlog phải dễ truy cập và dễ hiểu cho mọi người liên quan. Đây là cơ sở cho empiricism — không có minh bạch thì inspect và adapt đều vô nghĩa.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi Product Backlog là tài liệu yêu cầu cố định. Đây là sai lầm phổ biến nhất, đặc biệt ở các tổ chức chuyển từ waterfall. Backlog không phải bản đặc tả viết một lần. Mẹo: tự nhắc rằng "backlog là một động từ, không phải danh từ" — nó là hoạt động liên tục, không phải vật thể tĩnh.
Lỗi 2 — Nhiều nguồn việc song song. Khi Developers nhận việc ngoài backlog, đặc tính single source bị phá vỡ. Mẹo: thiết lập một "cửa tiếp nhận" duy nhất và lịch sự nhưng kiên quyết hướng mọi yêu cầu vào đó.
Lỗi 3 — Nhầm "ordered" với "prioritized theo độ quan trọng". Nhiều người nghĩ chỉ cần gắn nhãn High/Medium/Low là xong. Nhưng "ordered" nghĩa là một trật tự tuyến tính cụ thể — mục nào trước mục nào. Hai mục cùng nhãn "High" vẫn phải có cái đứng trước cái đứng sau. (Đào sâu ở Bài 13.)
Lỗi 4 — Over-refinement, viết chi tiết tới đáy backlog. Lãng phí công sức cho thứ có thể không bao giờ được làm. Mẹo: chỉ refine sâu những gì sắp được kéo vào Sprint.
Lỗi 5 — Nhầm lẫn về quyền sở hữu trong câu hỏi thi. Hãy nhớ chắc: PO accountable cho backlog; PO có thể delegate công việc nhưng không delegate accountability; chỉ PO mới có thẩm quyền cuối cùng về thứ tự. Nếu một câu hỏi gợi ý Scrum Master hay Developers "quyết định thứ tự backlog", đó là bẫy.
Mẹo thi quan trọng: Khi gặp câu hỏi về Product Backlog trong PSPO I, hãy quét xem đáp án có vi phạm một trong ba đặc tính cốt lõi không (emergent / ordered / single source) và có vi phạm quyền accountable của PO không. Phần lớn đáp án sai sẽ "vấp" vào đúng những điểm này.
Bài tập thực hành
- Tự kiểm định nghĩa. Không nhìn tài liệu, viết lại định nghĩa Product Backlog theo Scrum Guide bằng một câu, đảm bảo có đủ ba từ khóa: emergent, ordered, single source. Sau đó so với bản gốc.
- Soi backlog thực tế. Nếu bạn đang đi làm, mở backlog hiện tại của đội bạn và trả lời: (a) Nó có thật sự là single source không, hay đội bạn còn nhận việc từ kênh khác? (b) Nó có hình dạng tảng băng không, hay chi tiết đều tới đáy? (c) Lần cuối nó được cập nhật là khi nào? Ghi ra ba điều cần cải thiện.
- Phân biệt format. Liệt kê 5 loại PBI khác nhau (không chỉ User Story): ví dụ bug, spike, cải thiện hiệu năng, nợ kỹ thuật, yêu cầu tuân thủ. Điều này giúp bạn ghi nhớ rằng PBI không bắt buộc là User Story.
- Tình huống ra quyết định. Giám đốc gửi cho bạn một danh sách 50 tính năng và yêu cầu "làm hết theo thứ tự này, đừng đổi". Bạn sẽ giải thích bản chất emergent và quyền ordering của PO như thế nào để vừa giữ được nguyên tắc Scrum vừa không làm sếp mất lòng? Viết một đoạn 5–6 câu.
- Câu hỏi luyện thi tự tạo. Soạn 3 câu hỏi trắc nghiệm kiểu PSPO I về Product Backlog (mỗi câu 4 đáp án, 1 đúng), trong đó các đáp án sai cố tình vi phạm một trong các đặc tính đã học. Tự giải và giải thích.
Tóm tắt
Product Backlog không phải là một "danh sách việc cần làm" tĩnh, mà là một thực thể sống với ba đặc tính bản lề: emergent (luôn tiến hóa theo hiểu biết mới), ordered (được sắp xếp theo thứ tự tuyến tính dựa trên giá trị), và single source of work (nguồn công việc duy nhất của Scrum Team). Mỗi dòng trong đó là một PBI, và PBI không bắt buộc theo format nào — User Story chỉ là một lựa chọn.
Về trách nhiệm, Product Owner accountable cho nội dung, sự sẵn có và thứ tự của backlog; PO có thể delegate công việc nhưng không bao giờ delegate được accountability. Product Backlog tồn tại để phục vụ một Product Goal, và phải luôn minh bạch để làm nền cho empiricism.
Ba tình huống — backlog đông cứng ở "Tiệm Việt", năm nguồn việc ở "MoMoney", và mô hình tảng băng kỷ luật ở đội kiểu Grab — cho thấy hiểu sai bản chất backlog dẫn tới lãng phí và mất tập trung như thế nào, còn hiểu đúng thì giúp PO dẫn dắt giá trị thực sự. Nắm vững nền móng này, bạn không chỉ trả lời đúng một cụm câu hỏi PSPO I, mà còn vận hành sản phẩm như một Product Owner đích thực. Các kỹ thuật cụ thể để làm mịn (refinement) và sắp xếp (ordering) backlog sẽ là chủ đề của hai bài kế tiếp.