Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi một Product Owner (PO) giàu kinh nghiệm rằng "tài sản quý giá nhất trong tay anh/chị là gì?", phần lớn sẽ trả lời ngay: Product Backlog. Đây không phải là một danh sách công việc tẻ nhạt nằm im trong Jira, mà là bản đồ sống động dẫn đường cho cả nhóm phát triển hướng tới sản phẩm mà khách hàng thực sự cần.
Trong Scrum, Product Owner là người duy nhất chịu trách nhiệm về Product Backlog. Nói cách khác, nếu backlog hỗn loạn — mục tiêu mơ hồ, ưu tiên lẫn lộn, hạng mục trên cùng vẫn chưa sẵn sàng để làm — thì đó là lỗi của PO, không phải của Developer hay Scrum Master. Ngược lại, một backlog được quản lý tốt giúp mỗi buổi Sprint Planning diễn ra trơn tru, nhóm luôn biết "làm gì tiếp theo" và stakeholder tin tưởng rằng những thứ quan trọng nhất đang được làm trước.
Bài này tập trung sâu vào nghệ thuật làm chủ Product Backlog: hiểu bản chất của nó, nắm vững bốn đặc tính DEEP, biết cách sắp xếp thứ tự ưu tiên một cách có lý lẽ, và quan trọng nhất là giữ cho backlog luôn "khỏe mạnh". Đây là kỹ năng nền tảng mà mọi PO giỏi đều phải thành thạo trước khi bàn đến những chủ đề nâng cao hơn.
Khái niệm cốt lõi
Product Backlog là gì?
Product Backlog là một danh sách có thứ tự (ordered list) chứa tất cả những gì cần có để cải thiện sản phẩm. Nó là nguồn công việc duy nhất, chính thức mà nhóm Scrum dựa vào để làm việc. Mọi tính năng mới (feature), bản sửa lỗi (fix), cải tiến (improvement), hay yêu cầu kỹ thuật đều phải đi qua backlog.
Có vài điểm bản chất bạn cần khắc cốt ghi tâm:
- Nó luôn có thứ tự, không chỉ là "ưu tiên". Hai hạng mục không thể cùng ở vị trí số 1. Backlog là một danh sách xếp dọc từ trên xuống — thứ ở trên cùng sẽ được làm trước. Việc bắt buộc xếp thứ tự tuyến tính buộc PO phải đưa ra quyết định thật, thay vì gắn nhãn "tất cả đều High priority" (một cái bẫy rất phổ biến).
- Nó không bao giờ "hoàn thành". Chừng nào sản phẩm còn tồn tại và còn được dùng, backlog vẫn còn sống. Thị trường thay đổi, khách hàng phản hồi, công nghệ tiến hóa — backlog phản chiếu tất cả những thay đổi đó. Một backlog "đông cứng" là dấu hiệu sản phẩm đang chết dần.
- Nó là một artifact, gắn với một cam kết (commitment) gọi là Product Goal. Theo Scrum Guide 2020, mỗi artifact có một commitment riêng. Với Product Backlog, đó là Product Goal — đích đến dài hạn mà backlog đang hướng tới. (Phần Product Goal được đào sâu ở Bài 21, ở đây bạn chỉ cần nhớ backlog luôn phục vụ một mục tiêu lớn hơn).
Bốn đặc tính DEEP của một Product Backlog tốt
DEEP là khung tư duy do Roman Pichler và Mike Cohn phổ biến, mô tả bốn phẩm chất của một backlog khỏe mạnh. Đây là phần "ruột" của bài học này, hãy đọc kỹ.
D — Detailed Appropriately (Chi tiết một cách phù hợp). Mức độ chi tiết của một hạng mục phải tỷ lệ nghịch với khoảng cách của nó tới hiện tại. Hạng mục sẽ làm trong Sprint tới phải được mô tả rõ ràng, có tiêu chí chấp nhận (acceptance criteria), đủ nhỏ để hoàn thành trong một Sprint. Ngược lại, hạng mục dự kiến làm sau ba tháng nữa chỉ cần một câu ý tưởng. Đừng phí công viết chi tiết cho thứ rất có thể sẽ thay đổi hoặc bị loại bỏ. Nguyên tắc: chi tiết hóa muộn nhất có thể (just-in-time), không phải sớm nhất có thể.
E — Estimated (Đã được ước lượng). Mỗi hạng mục nên có một con số ước lượng về độ lớn (thường là Story Points). Lưu ý: hạng mục càng ở dưới, ước lượng càng thô (ví dụ "khoảng T-shirt size L"); hạng mục trên cùng có ước lượng tinh hơn. Ước lượng giúp PO cân nhắc đánh đổi giá trị-công sức (value vs effort) khi sắp xếp ưu tiên. (Cách ước lượng cụ thể với Story Points và Planning Poker thuộc Bài 24, ở đây ta chỉ nói rằng backlog tốt thì các hạng mục quan trọng đều có ước lượng).
E — Emergent (Tiến hóa / nổi lên liên tục). Backlog là một thực thể sống. Hạng mục mới được thêm vào, hạng mục cũ bị xóa hoặc viết lại, thứ tự được sắp xếp lại liên tục dựa trên những gì nhóm học được. Một backlog "đóng băng" suốt nhiều tháng là dấu hiệu PO không lắng nghe thị trường. Tính emergent đòi hỏi PO thường xuyên cập nhật, không phải lập kế hoạch một lần rồi để đó.
P — Prioritized / Ordered (Đã được sắp xếp thứ tự). Đây là đặc tính quan trọng nhất và cũng khó nhất. Backlog phải được sắp theo thứ tự để hạng mục mang lại giá trị cao nhất, rủi ro lớn nhất, hoặc phụ thuộc quan trọng nhất nằm ở trên cùng. Thứ tự này không phải do cảm tính — PO phải có lý lẽ dựa trên giá trị kinh doanh, chi phí, rủi ro và sự phụ thuộc.
Một vài kỹ thuật sắp xếp ưu tiên
Để biến chữ "P" thành hành động, PO thường dùng vài khung quen thuộc:
- Value vs Effort (Giá trị / Công sức): vẽ ma trận 2x2, ưu tiên những hạng mục giá trị cao - công sức thấp ("quick wins").
- MoSCoW: phân loại Must have, Should have, Could have, Won't have — hữu ích khi đàm phán phạm vi với stakeholder.
- WSJF (Weighted Shortest Job First): dùng nhiều trong SAFe, tính điểm = (Giá trị kinh doanh + Tính cấp thiết theo thời gian + Giảm rủi ro) chia cho Kích thước công việc.
Tình huống thực tế
Ví dụ 1 — Tiki và cái bẫy "tất cả đều quan trọng"
Hãy tưởng tượng một nhóm phát triển tính năng tại một sàn thương mại điện tử lớn như Tiki. PO mới nhận việc, mở Jira ra và thấy backlog có 240 hạng mục, trong đó 180 hạng mục được gắn nhãn "High priority". Mỗi sáng stakeholder từ phòng Marketing, phòng Logistics, phòng Thanh toán đều nhảy vào đòi tính năng của mình "phải làm gấp".
Hậu quả: Sprint Planning kéo dài bốn tiếng mà nhóm vẫn không rõ làm gì trước. Developer nhặt đại vài hạng mục ở trên, làm xong thì stakeholder bảo "cái này không gấp bằng cái kia".
Cách PO xử lý: PO áp đặt quy tắc thứ tự tuyến tính — không còn nhãn High/Medium/Low nữa, mọi hạng mục phải nằm ở một vị trí số cụ thể trên danh sách dọc. Khi phòng Marketing đòi đẩy tính năng "voucher sinh nhật" lên, PO hỏi thẳng: "Vậy nó nên đứng trên hay dưới tính năng 'tối ưu tốc độ thanh toán' mà phòng Payment đang chờ? Một trong hai phải lùi xuống." Câu hỏi buộc các bên ngồi lại đối thoại về giá trị thực.
Bài học: Khi mọi thứ đều ưu tiên cao nghĩa là chẳng có gì được ưu tiên. Sắp xếp tuyến tính ép ra quyết định thật và làm minh bạch sự đánh đổi.
Ví dụ 2 — Startup Fintech với backlog "đông cứng"
Một startup fintech tại TP.HCM (gọi là PayViet) xây ứng dụng ví điện tử. Trong giai đoạn gọi vốn, founder đã viết một backlog rất đồ sộ: 150 hạng mục chi tiết tới từng nút bấm, cho cả lộ trình 12 tháng. Họ tự hào vì "đã lên kế hoạch xong xuôi".
Sáu tháng sau, thị trường thay đổi: Ngân hàng Nhà nước ra quy định mới về eKYC, đối thủ tung tính năng chia hóa đơn, người dùng phản hồi rằng họ cần liên kết nhiều ngân hàng hơn. Nhưng backlog vẫn y nguyên như sáu tháng trước. Nhóm vẫn cặm cụi làm những hạng mục đã được viết chi tiết từ đầu — nhiều trong số đó nay đã lỗi thời.
Cách khắc phục: PO mới áp dụng đúng hai chữ trong DEEP. Thứ nhất là Emergent — backlog phải được rà soát mỗi tuần, mạnh dạn xóa những hạng mục không còn phù hợp (họ đã xóa gần 40 hạng mục). Thứ hai là Detailed Appropriately — chỉ chi tiết hóa hạng mục cho 1-2 Sprint tới, phần còn lại để ở dạng ý tưởng thô. Nhờ đó công sức viết chi tiết không còn bị lãng phí khi kế hoạch thay đổi.
Bài học: Backlog không phải bản hợp đồng đóng dấu một lần. Một backlog "đẹp và chi tiết toàn bộ" ngay từ đầu thường là dấu hiệu của lãng phí, không phải của sự chuyên nghiệp.
Ví dụ 3 — Đội nội bộ ngân hàng và sức mạnh của "Detailed Appropriately"
Một ngân hàng ở Đông Nam Á có đội phát triển nội bộ làm hệ thống quản lý khoản vay. PO ban đầu mắc lỗi ngược với ví dụ 2: ông viết quá ít chi tiết cho cả backlog. Đến Sprint Planning, hạng mục trên cùng chỉ vỏn vẹn dòng "Cải thiện màn hình duyệt hồ sơ vay". Developer hỏi: "Cải thiện cái gì? Tiêu chí chấp nhận là gì? Khi nào coi là xong?" Không ai trả lời được, buổi planning đổ vỡ, nhóm lãng phí nửa ngày.
Cách xử lý: PO thiết lập một quy ước gọi là "tầng sẵn sàng" (definition of ready ở mức nhẹ): bất kỳ hạng mục nào dự kiến vào hai Sprint tới đều phải có mô tả rõ, tiêu chí chấp nhận, và đã được ước lượng. PO dành 5-10% thời lượng mỗi Sprint để chuẩn bị tầng trên cùng này (hoạt động chuẩn bị backlog sẽ học sâu ở Bài 23 — Backlog Refinement). Kết quả: ba Sprint sau đó, mỗi buổi planning chỉ còn kéo dài 90 phút và nhóm luôn rõ việc.
Bài học: Chữ D trong DEEP có hai mặt — không quá chi tiết cho hạng mục xa (ví dụ 2), nhưng phải đủ chi tiết cho hạng mục gần (ví dụ 3). Cân bằng đúng mức là dấu hiệu của một PO trưởng thành.
Hướng dẫn từng bước
Dưới đây là quy trình thực dụng để bạn xây dựng và duy trì một Product Backlog khỏe mạnh:
- Gom mọi nguồn đầu vào về một nơi. Yêu cầu từ stakeholder, phản hồi khách hàng, ý tưởng từ Developer, lỗi từ vận hành — tất cả đều đưa vào một backlog duy nhất. Không để các danh sách công việc "ngầm" tồn tại song song trong email hay file Excel riêng.
- Viết mỗi hạng mục dưới dạng đem lại giá trị. Mỗi mục nên trả lời được: Ai cần? Cần gì? Để làm gì? (Format User Story học chi tiết ở Bài 22). Tránh viết hạng mục thuần kỹ thuật mà không ai hiểu giá trị.
- Sắp xếp thành một danh sách dọc, từ trên xuống. Buộc bản thân trả lời: "Nếu chỉ được làm một việc tiếp theo, đó là việc gì?" Đó là hạng mục số 1. Lặp lại cho số 2, số 3... Dùng Value vs Effort hoặc MoSCoW để hỗ trợ.
- Chi tiết hóa phần trên cùng theo nguyên tắc just-in-time. Đảm bảo 8-10 hạng mục trên cùng đủ rõ ràng, có tiêu chí chấp nhận, đủ nhỏ để vừa một Sprint, và đã được ước lượng. Phần dưới cứ để thô.
- Rà soát định kỳ (thường xuyên, đều đặn). Mỗi tuần hoặc mỗi Sprint, dành thời gian thêm/xóa/sắp xếp lại, cập nhật ước lượng. Mạnh dạn xóa những gì không còn phục vụ Product Goal.
- Giữ minh bạch. Backlog phải mở cho cả nhóm và stakeholder xem được, để mọi người hiểu vì sao thứ tự lại như vậy. Sự minh bạch này nuôi dưỡng lòng tin.
Lỗi thường gặp & mẹo
- Lỗi: Backlog phình to vô tận. Thêm hoài mà không bao giờ xóa khiến backlog có hàng trăm hạng mục vô dụng. Mẹo: coi việc xóa là một hành động lành mạnh. Nếu một hạng mục nằm dưới cùng suốt sáu tháng mà chẳng bao giờ được nhắc tới, gần như chắc chắn nó không quan trọng — hãy xóa.
- Lỗi: Gắn nhãn ưu tiên thay vì xếp thứ tự. "High / Medium / Low" dẫn tới 80% hạng mục là "High". Mẹo: ép bản thân xếp thứ tự tuyến tính, mỗi hạng mục một vị trí duy nhất.
- Lỗi: Chi tiết hóa quá sớm toàn bộ backlog. Lãng phí công sức cho thứ sẽ thay đổi. Mẹo: nhớ hình ảnh tảng băng — chỉ phần nổi mới cần rõ.
- Lỗi: Để stakeholder hoặc Scrum Master tự ý sửa thứ tự backlog. Điều này phá vỡ quyền sở hữu của PO. Mẹo: PO có thể ủy quyền việc viết hạng mục, nhưng quyết định thứ tự cuối cùng phải thuộc về PO — đó là trách nhiệm không thể chuyển giao theo Scrum Guide.
- Mẹo vàng: Mỗi khi thêm một hạng mục mới, hãy tự hỏi "Hạng mục này phục vụ Product Goal như thế nào?". Nếu không trả lời được, có lẽ nó không nên nằm trong backlog.
Bài tập thực hành
- Tự đánh giá DEEP: Mở backlog của sản phẩm bạn đang làm (hoặc một sản phẩm bạn quen thuộc, ví dụ một app đặt đồ ăn). Chấm điểm từng chữ D-E-E-P trên thang 1-5. Viết ra hai hành động cụ thể để cải thiện chữ yếu nhất.
- Bài tập sắp xếp tuyến tính: Lấy 10 hạng mục giả định cho một ví điện tử (ví dụ: liên kết ngân hàng, quét QR thanh toán, lịch sử giao dịch, đổi mật khẩu, chia hóa đơn, thông báo đẩy, hỗ trợ chat, dark mode, khóa vân tay, mời bạn nhận thưởng). Xếp chúng thành danh sách dọc từ 1 đến 10 và viết một câu lý do cho ba vị trí trên cùng.
- Bài tập "dọn rác": Tìm trong backlog (thật hoặc giả định) năm hạng mục bạn nghĩ nên xóa. Với mỗi hạng mục, viết một câu giải thích vì sao nó không còn phục vụ Product Goal.
- Mức chi tiết phù hợp: Chọn một hạng mục bạn nghĩ sẽ làm trong Sprint tới và viết mô tả đầy đủ kèm ba tiêu chí chấp nhận. Sau đó chọn một hạng mục dự kiến làm sau ba tháng và cố tình chỉ viết một câu — luyện thói quen "detailed appropriately".
Tóm tắt
Product Backlog là tài sản trung tâm trong tay Product Owner — một danh sách có thứ tự, sống động, chứa tất cả những gì cần để cải thiện sản phẩm, và luôn hướng về Product Goal. Một backlog tốt mang bốn đặc tính DEEP: Detailed Appropriately (chi tiết vừa đủ, just-in-time), Estimated (đã ước lượng), Emergent (tiến hóa liên tục), và Prioritized/Ordered (xếp thứ tự tuyến tính theo giá trị).
Ba sai lầm phổ biến nhất là: gắn nhãn ưu tiên thay vì xếp thứ tự, chi tiết hóa quá sớm toàn bộ backlog, và để backlog phình to mà không bao giờ dọn dẹp. Qua ba tình huống thực tế — từ sàn thương mại điện tử, startup fintech tới đội nội bộ ngân hàng — ta thấy rằng làm chủ backlog không phải kỹ năng viết lách, mà là kỹ năng ra quyết định và đối thoại có lý lẽ. PO giỏi là người dám nói "không", dám xóa, dám xếp một thứ xuống dưới để thứ quan trọng hơn lên trên.
Hãy ghi nhớ: một Product Backlog khỏe mạnh khiến mọi sự kiện Scrum khác trở nên dễ dàng hơn. Đây là nền tảng bạn cần vững vàng trước khi bước sang các chủ đề như Sprint Planning, ước lượng hay quản lý stakeholder ở những bài tiếp theo.