Mở đầu — vì sao bài này quan trọng
Nếu phải chọn một artifact duy nhất nói lên sức khỏe của cả Scrum Team, tôi luôn chọn Product Backlog. Lý do rất đơn giản: mọi thứ team làm — từ Sprint Planning, refinement, cho đến từng dòng code Developer viết ra — đều bắt nguồn từ Product Backlog. Nó là single source of work (nguồn công việc duy nhất) cho toàn bộ team. Không có gì được xây mà không xuất phát từ đây.
Trong thực tế, tôi đã chứng kiến nhiều team Scrum "đúng quy trình" trên giấy tờ: có Sprint Planning, có Daily Scrum, có Retrospective đầy đủ. Nhưng sản phẩm vẫn lệch hướng, Developer làm nhầm việc, stakeholder bức xúc. Đào sâu vào thì gần như lần nào nguyên nhân cũng nằm ở một Product Backlog lộn xộn: hàng trăm item chưa được sắp xếp, mục tiêu mơ hồ, item cũ nằm chất đống không ai dọn. Backlog xấu thì mọi sự kiện Scrum phía sau đều "rác vào, rác ra".
Với một Product Owner, Product Backlog không phải là một danh sách công việc bạn quản lý cho vui. Đó là công cụ quyền lực nhất của bạn. Đây là nơi bạn thể hiện chiến lược sản phẩm, thể hiện sự ưu tiên, và truyền đạt định hướng cho cả team mà không cần họp hành liên miên. Bài học hôm nay sẽ giúp bạn hiểu sâu Product Backlog là gì, đặc tính DEEP làm nên một backlog khỏe mạnh, và cách bạn — với tư cách PO — sở hữu và chăm sóc nó mỗi ngày.
Khái niệm cốt lõi
Product Backlog là gì
Theo Scrum Guide, Product Backlog là một danh sách có thứ tự, nổi lên (emergent) và được sắp xếp, gồm tất cả 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 mà Scrum Team thực hiện. Hãy chú ý ba từ khóa quan trọng trong định nghĩa này.
Thứ nhất, có thứ tự (ordered). Product Backlog không phải một cái túi đựng đồ lộn xộn — nó được sắp xếp từ trên xuống dưới theo mức độ ưu tiên. Item ở đỉnh là thứ team sẽ làm sớm nhất; item ở đáy là thứ xa nhất, mơ hồ nhất. Việc quyết định thứ tự này chính là một trong những trách nhiệm cốt lõi của Product Owner.
Thứ hai, nổi lên (emergent). Backlog không bao giờ được "viết xong một lần rồi đóng băng". Nó sống động, thay đổi liên tục khi team học được nhiều hơn về sản phẩm, về khách hàng, về thị trường. Đây là điểm khác biệt cốt tử so với tư duy lập kế hoạch kiểu thác nước (waterfall), nơi người ta cố viết hết requirement ngay từ đầu.
Thứ ba, living artifact, never complete — một tài liệu sống, không bao giờ hoàn thiện. Chừng nào sản phẩm còn tồn tại và còn tạo ra giá trị, chừng đó Product Backlog vẫn còn tồn tại. Một Product Backlog "rỗng và đóng lại" thường đồng nghĩa với việc sản phẩm đã chết hoặc bị khai tử.
Ai sở hữu Product Backlog
Product Owner là người sở hữu duy nhất Product Backlog. PO chịu trách nhiệm về nội dung, thứ tự ưu tiên, và tính minh bạch của nó. Điều này không có nghĩa là PO phải tự tay viết tất cả mọi item. Trong thực tế, Developer thường đóng góp item kỹ thuật (tech debt, refactoring), khách hàng và stakeholder đóng góp ý tưởng, Scrum Master hỗ trợ về mặt quy trình. Nhưng quyết định cuối cùng — item nào nằm trong backlog, nằm ở đâu, ưu tiên ra sao — luôn thuộc về PO.
Tôi hay nói với học viên: nếu bạn là PO mà ai cũng có thể tự ý chen item vào đỉnh backlog của bạn, thì bạn không thực sự sở hữu nó. Một PO mạnh phải là "người gác cổng" của backlog. Mọi yêu cầu đều được lắng nghe, nhưng không phải mọi yêu cầu đều được đưa vào, và càng không phải cái nào cũng được ưu tiên cao.
Commitment của Product Backlog: Product Goal
Một điểm quan trọng cần nhớ: trong Scrum, mỗi artifact đều có một "commitment" gắn liền để tăng tính minh bạch và tập trung. Với Product Backlog, commitment đó là Product Goal — mục tiêu sản phẩm. Product Goal mô tả trạng thái tương lai của sản phẩm, là cái đích dài hạn mà mọi item trong backlog đang hướng tới. (Chúng ta sẽ đào sâu Product Goal ở bài riêng; ở đây bạn chỉ cần nắm rằng backlog luôn phục vụ cho một mục tiêu sản phẩm rõ ràng, chứ không phải là danh sách việc rời rạc.)
Đặc tính DEEP — thước đo một backlog khỏe mạnh
Mike Cohn — một trong những tên tuổi lớn của cộng đồng Agile — đưa ra mô hình DEEP để mô tả một Product Backlog tốt. DEEP là viết tắt của bốn đặc tính. Đây là khung tư duy tôi dùng để "khám sức khỏe" bất kỳ backlog nào.
D — Detailed appropriately (chi tiết một cách phù hợp). Item ở đỉnh backlog (sắp được làm) phải chi tiết, rõ ràng, đủ nhỏ để team hiểu và bắt tay làm ngay. Item ở đáy backlog (còn xa) thì chỉ cần phác thảo sơ bộ, thậm chí chỉ là một dòng tiêu đề. Sai lầm phổ biến là cố viết chi tiết tất cả mọi item ngay từ đầu — đó là lãng phí, vì những item xa rất có thể sẽ thay đổi hoặc bị loại bỏ trước khi đến lượt. Hình dung backlog như một cái phễu: càng gần miệng phễu càng rõ nét, càng xa càng mờ.
E — Estimated (đã được ước lượng). Mỗi item nên có một ước lượng về độ lớn (thường là Story Points). Ước lượng giúp PO hiểu được "chi phí" tương đối của từng item để cân nhắc khi ưu tiên, và giúp dự báo (forecasting) khi nào một nhóm tính năng có thể hoàn thành. Tương tự nguyên tắc DEEP về độ chi tiết, item càng gần đỉnh thì ước lượng càng đáng tin; item xa có thể chỉ ước lượng thô theo size T-shirt (S, M, L, XL).
E — Emergent (nổi lên, tiến hóa). Backlog liên tục thay đổi. Item mới được thêm vào, item cũ bị xóa, thứ tự ưu tiên đảo lộn khi có thông tin mới. Một backlog không bao giờ thay đổi trong nhiều tháng là dấu hiệu của một backlog chết — hoặc team không học hỏi gì từ thị trường, hoặc PO không thực sự chăm sóc nó.
P — Prioritized (đã được ưu tiên). Item được sắp xếp theo thứ tự giá trị, từ cao xuống thấp. Đây là phần "linh hồn" mà PO thể hiện chiến lược của mình. Một backlog mà mọi thứ đều "ưu tiên cao như nhau" thực chất là một backlog không có ưu tiên gì cả.
Khi cả bốn đặc tính DEEP cùng hiện diện, bạn có một backlog mà bất kỳ ai nhìn vào cũng hiểu: team sẽ làm gì tiếp theo, vì sao, và mất khoảng bao nhiêu công sức.
Một item trong Product Backlog gồm những gì
Mỗi Product Backlog Item (PBI) thường có: một mô tả (description), một thứ tự (order), một ước lượng (estimate), và giá trị (value). Item phổ biến nhất là User Story, nhưng backlog không chỉ chứa story — nó còn chứa bug, tech debt, công việc nghiên cứu (spike), cải tiến hạ tầng. Tất cả những gì cần làm để cải thiện sản phẩm đều có chỗ trong Product Backlog.
Tình huống thực tế
Tình huống 1 — Tiki và backlog "ngập trong rác"
Hãy tưởng tượng một team tại một sàn thương mại điện tử lớn ở Việt Nam, gọi là team Checkout. Sau hai năm phát triển, Product Backlog của họ phình lên hơn 600 item trong Jira. Có những item được tạo từ 18 tháng trước, mô tả những tính năng mà giờ chẳng còn ai nhớ vì sao lại cần. PO mới tiếp nhận và choáng váng: không thể nào sắp ưu tiên nổi giữa một biển 600 item.
Vấn đề ở đây là backlog đã vi phạm gần như toàn bộ DEEP. Nó không Emergent đúng nghĩa (chỉ thêm vào, không bao giờ dọn ra), không Prioritized (item rải rác không thứ tự), và Detailed sai chỗ (nhiều item cũ viết rất chi tiết nhưng vô dụng, trong khi item sắp làm lại mơ hồ).
PO mới quyết định một việc dũng cảm: dành hẳn một buổi để archive (lưu trữ) mọi item cũ hơn 6 tháng chưa được động đến. Backlog từ 600 item rút xuống còn khoảng 80. Có người lo "lỡ bỏ sót ý tưởng quan trọng thì sao?". Câu trả lời thực tế là: nếu một ý tưởng thực sự quan trọng, nó sẽ quay lại — khách hàng sẽ lại yêu cầu, stakeholder sẽ lại nhắc. Bài học: một backlog dài không phải là backlog giàu có; nó thường là backlog bị bỏ bê. Mạnh dạn dọn dẹp là một hành động quản trị, không phải mất mát.
Tình huống 2 — Startup SaaS với backlog "phẳng lì"
Một startup SaaS quản lý nhân sự tại TP.HCM, khoảng 25 người, có một PO trẻ rất chăm chỉ. Backlog của anh sạch sẽ, item nào cũng viết chi tiết, đầy đủ acceptance criteria. Nghe có vẻ lý tưởng phải không? Nhưng có một vấn đề chí mạng: tất cả 90 item đều được gắn nhãn "Priority: High". Khi Developer hỏi "Sprint tới làm gì trước?", PO lúng túng vì với anh, cái gì cũng quan trọng.
Đây là backlog vi phạm chữ P (Prioritized) một cách điển hình. Khi mọi thứ đều ưu tiên cao, thực chất không có ưu tiên nào cả, và gánh nặng quyết định bị đẩy ngược cho Developer — những người không có đủ ngữ cảnh kinh doanh để quyết.
Tôi gợi ý cho PO một nguyên tắc đơn giản: backlog là một danh sách xếp hàng dọc, không phải các nhóm ngang. Mỗi item phải có một vị trí duy nhất so với mọi item khác — không có hai item "cùng hạng". Khi buộc phải trả lời "giữa A và B, cái nào làm trước?", PO mới thực sự đưa ra quyết định chiến lược. Sau khi áp dụng, velocity của team không đổi, nhưng giá trị giao cho khách hàng trong mỗi Sprint tăng rõ rệt, vì những thứ quan trọng nhất luôn được làm trước. Bài học: ưu tiên thực sự nghĩa là dám nói "cái này trước, cái kia sau" — kể cả khi cả hai đều đáng làm.
Tình huống 3 — Detailed appropriately giúp team đỡ lãng phí
Một công ty fintech ở Singapore phục vụ thị trường Đông Nam Á có thói quen viết spec cực kỳ chi tiết cho mọi item trong roadmap 6 tháng — mỗi item dài 4-5 trang. Trong một đợt thay đổi quy định pháp lý đột ngột (rất thường gặp trong fintech), một nửa roadmap bị đảo lộn. Hơn 30 item đã được viết chi tiết tỉ mỉ giờ phải vứt bỏ. Hàng trăm giờ phân tích nghiệp vụ đổ sông đổ biển.
Sau bài học đau đớn đó, PO áp dụng đúng nguyên tắc Detailed appropriately: chỉ những item dự kiến làm trong 2-3 Sprint tới mới được viết chi tiết; item xa hơn chỉ giữ ở mức một đoạn ngắn mô tả ý tưởng và giá trị. Kết quả là khi quy định thay đổi lần sau, họ chỉ mất vài item đã refine, phần còn lại vẫn ở dạng phác thảo nên điều chỉnh rất nhẹ nhàng. Bài học: chi tiết quá sớm là một dạng lãng phí trá hình. Hãy đầu tư công sức làm rõ đúng lúc item sắp được làm, không phải sớm hơn.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên các PO mới áp dụng để xây dựng và duy trì một Product Backlog khỏe mạnh.
Bước 1 — Neo backlog vào Product Goal. Trước khi thêm bất kỳ item nào, hãy tự hỏi: "Mục tiêu sản phẩm của chúng ta lúc này là gì?". Mọi item nên trả lời được câu hỏi "nó đóng góp gì cho mục tiêu đó?". Item nào không liên quan thì xếp xuống đáy hoặc loại bỏ.
Bước 2 — Thu thập và ghi nhận item từ mọi nguồn. Ý tưởng đến từ stakeholder, phản hồi khách hàng, dữ liệu phân tích, đề xuất kỹ thuật của Developer. Hãy có một "cửa vào" rõ ràng để mọi người biết đưa ý tưởng cho bạn ở đâu, thay vì gửi rải rác qua chat, email, hành lang.
Bước 3 — Sắp xếp ưu tiên theo trục dọc. Đặt mỗi item vào một vị trí duy nhất. Tự buộc mình so sánh từng cặp item: cái nào tạo giá trị cao hơn, cái nào rủi ro hơn nếu trì hoãn? Tránh tuyệt đối việc gắn nhãn ưu tiên trùng nhau cho hàng loạt item.
Bước 4 — Áp dụng nguyên tắc Detailed appropriately. Dồn công sức làm rõ những item ở đỉnh: thêm mô tả, acceptance criteria, ví dụ. Để item ở đáy ở dạng tiêu đề hoặc đoạn ngắn. Coi đỉnh backlog là vùng "sẵn sàng cho Sprint tới".
Bước 5 — Đảm bảo mọi item đỉnh đã được ước lượng. Phối hợp với Developer để gắn Story Points cho các item sắp làm. Đừng tự PO ước lượng thay — ước lượng là việc của những người sẽ làm.
Bước 6 — Giữ backlog luôn nổi lên (emergent). Định kỳ dọn dẹp: xóa item lỗi thời, gộp item trùng, archive item quá cũ. Một backlog khỏe mạnh nên co lại thường xuyên chứ không chỉ phình ra.
Bước 7 — Đảm bảo minh bạch. Backlog phải nơi cả team và stakeholder có thể nhìn thấy. Khi mọi người tin vào những gì backlog thể hiện, các sự kiện Scrum mới chạy hiệu quả.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi backlog là kho lưu trữ ý tưởng. Nhiều PO ném mọi ý tưởng vào backlog "cho khỏi quên". Sau vài tháng, backlog thành bãi rác. Mẹo: phân biệt rõ "ý tưởng đang cân nhắc" với "công việc đã cam kết theo đuổi". Một backlog chỉ nên chứa thứ bạn thực sự có ý định làm.
Lỗi 2 — Để backlog đóng băng. Backlog không thay đổi trong nhiều tháng là dấu hiệu nguy hiểm. Mẹo: coi việc cập nhật backlog là việc làm mỗi tuần, không phải mỗi quý.
Lỗi 3 — Ưu tiên theo cảm tính hoặc theo ai la to nhất. PO yếu thường ưu tiên theo stakeholder nào gây áp lực mạnh nhất. Mẹo: dùng một khung ưu tiên nhất quán (giá trị so với công sức, mức độ rủi ro, sự phù hợp với Product Goal) để bảo vệ quyết định của mình.
Lỗi 4 — Viết chi tiết quá sâu cho item còn xa. Như tình huống fintech ở trên, đây là lãng phí trá hình. Mẹo: chỉ refine sâu những gì sắp làm trong 2-3 Sprint tới.
Lỗi 5 — Nhầm Product Backlog với Sprint Backlog. Product Backlog là toàn bộ công việc cho cả sản phẩm và do PO sở hữu; Sprint Backlog là tập con được team chọn cho một Sprint và do Developer sở hữu. Đừng lẫn lộn hai artifact này.
Mẹo vàng: mỗi sáng, hãy nhìn vào 10 item ở đỉnh backlog của bạn và tự hỏi: "Nếu hôm nay team bắt đầu làm 10 cái này, họ có hiểu rõ phải làm gì không, và đây có đúng là 10 thứ giá trị nhất không?". Nếu câu trả lời cho cả hai là "có", backlog của bạn đang khỏe mạnh.
Bài tập thực hành
- Khám sức khỏe DEEP. Lấy Product Backlog hiện tại của bạn (hoặc của một dự án giả định). Chấm điểm từng đặc tính DEEP trên thang 1-5: Detailed appropriately, Estimated, Emergent, Prioritized. Ghi ra đặc tính yếu nhất và một hành động cụ thể để cải thiện nó trong tuần này.
- Bài tập ưu tiên dọc. Lấy 10 item bất kỳ trong backlog đang gắn cùng một mức ưu tiên. Buộc mình xếp chúng thành một danh sách dọc từ 1 đến 10, không có hai item cùng hạng. Ghi lại lý do tại sao item số 1 đứng trên item số 2.
- Dọn dẹp emergent. Tìm tất cả item trong backlog cũ hơn 6 tháng chưa được động đến. Với mỗi item, quyết định: giữ và refine, gộp với item khác, hay archive. Đếm xem backlog của bạn co lại bao nhiêu phần trăm sau khi dọn.
- Viết lại Detailed appropriately. Chọn 3 item ở đỉnh và 3 item ở đáy. Viết item đỉnh thật chi tiết (có acceptance criteria), và rút gọn item đáy về đúng một dòng tiêu đề. Cảm nhận sự khác biệt về "độ phân giải" này.
Tóm tắt
Product Backlog là artifact quan trọng nhất với một Product Owner vì nó là nguồn công việc duy nhất cho cả Scrum Team — mọi thứ team làm đều bắt nguồn từ đây. Nó là một tài liệu sống, được sắp xếp có thứ tự, liên tục nổi lên và không bao giờ hoàn thiện chừng nào sản phẩm còn tồn tại. PO là người sở hữu duy nhất, chịu trách nhiệm về nội dung, thứ tự ưu tiên và tính minh bạch, với Product Goal làm cam kết định hướng.
Thước đo một backlog khỏe mạnh là mô hình DEEP của Mike Cohn: Detailed appropriately (chi tiết đúng chỗ — đỉnh rõ, đáy mờ), Estimated (đã ước lượng), Emergent (liên tục tiến hóa và được dọn dẹp), Prioritized (xếp hàng dọc theo giá trị). Các tình huống thực tế cho thấy backlog hỏng thường vì phình to không kiểm soát, ưu tiên phẳng lì, hoặc chi tiết quá sớm gây lãng phí. Hãy chăm sóc backlog mỗi tuần, neo nó vào mục tiêu sản phẩm, và nhớ rằng: một backlog gọn gàng, có ưu tiên rõ ràng chính là cách bạn lãnh đạo cả team mà không cần một lời ra lệnh.