Mở đầu — vì sao bài này quan trọng
Khi một sản phẩm còn nhỏ, mọi thứ rất rõ ràng: một Product Owner, một team, một danh sách công việc. Nhưng đến lúc sản phẩm thành công và doanh nghiệp muốn đi nhanh hơn, câu trả lời "bản năng" thường là tuyển thêm người và chia thành nhiều team. Và đây chính là khoảnh khắc mà rất nhiều tổ chức mắc một sai lầm âm thầm nhưng cực kỳ tốn kém: họ chia luôn cả Product Backlog ra theo team.
Mỗi team có một backlog riêng. Mỗi backlog có một người "phụ trách" riêng. Nghe rất gọn gàng, rất dễ quản lý. Nhưng vài tháng sau, bạn nhận ra: không ai còn nhìn thấy bức tranh tổng thể của sản phẩm nữa. Các team xây những thứ chồng chéo. Việc quan trọng nhất với khách hàng lại nằm ở team đang "rảnh nhất nhưng không ai dám đụng vào backlog của team kia". Ưu tiên trở thành một cuộc đàm phán chính trị giữa các nhóm thay vì một quyết định về giá trị.
Bài học này tập trung vào một nguyên tắc nền tảng khi scale Scrum cho nhiều team: một sản phẩm thì có một Product Backlog, và một Product Owner chịu accountable cho nó — bất kể có bao nhiêu team đang cùng làm. Đây không phải là quan điểm cá nhân, mà là cách Scrum Guide và các framework scale như LeSS, Nexus định nghĩa. Hiểu sâu nguyên tắc này giúp bạn tránh được cái bẫy "nhiều backlog" mà rất nhiều công ty Việt Nam và Đông Nam Á đang mắc phải khi đội ngũ kỹ thuật phình ra từ 1 lên 3, 5 team.
Khái niệm cốt lõi
Nguyên tắc nền: 1 Product = 1 Product Backlog = 1 PO accountable
Theo Scrum Guide 2020, Product Owner là người accountable (chịu trách nhiệm giải trình cuối cùng) cho việc tối đa hóa giá trị của sản phẩm, và việc đó thể hiện qua một Product Backlog duy nhất. Khi nhiều team cùng làm việc trên một sản phẩm, định nghĩa này không thay đổi:
- Vẫn chỉ có một Product Backlog đại diện cho toàn bộ công việc cần làm để sản phẩm đạt mục tiêu.
- Vẫn chỉ có một Product Owner chịu accountable cho backlog đó và cho thứ tự (ordering) của nó.
- Nhiều team cùng kéo (pull) công việc từ chung một backlog đó.
Vì sao KHÔNG split (chia) backlog theo team?
Lý do sâu xa nằm ở chỗ: Product Backlog là công cụ để tối ưu giá trị toàn cục của sản phẩm, không phải công cụ để phân bổ công việc cho từng team. Khi bạn chia backlog theo team, bạn vô tình biến mục tiêu từ "giá trị sản phẩm" thành "team này có đủ việc làm chưa". Đó là tối ưu cục bộ (local optimization).
Cụ thể, việc split backlog gây ra những hệ quả sau:
1. Mất khả năng ưu tiên toàn cục. Nếu có 5 backlog riêng, mỗi backlog được sắp xếp tốt theo team của nó, không có gì đảm bảo rằng item quan trọng nhất với khách hàng đang nằm ở đầu. Việc P0 (cực kỳ quan trọng) của sản phẩm có thể nằm ở vị trí thứ 12 trong backlog của team A, trong khi team B đang làm việc P3 ở đầu backlog của họ. Không ai có thẩm quyền nhìn xuyên qua tất cả để nói "dừng team B lại, dồn vào việc của team A".
2. Khóa cứng công việc vào team (team silo). Khi mỗi team "sở hữu" một backlog, công việc bị buộc chặt vào team đó. Nếu nhu cầu kinh doanh dồn vào lĩnh vực của team A, team A quá tải còn team B, C ngồi chơi — nhưng vì backlog đã chia, không thể linh hoạt chuyển. Tính linh hoạt (adaptiveness) — vốn là lợi thế lớn nhất của Agile — bị bóp nghẹt.
3. Sinh ra nhiều "PO" giả mạo và xung đột thẩm quyền. Mỗi backlog cần người sắp xếp, nên tổ chức tự nhiên đẻ ra nhiều "Product Owner team-level". Họ ưu tiên cục bộ, và khi cần phối hợp thì phải họp với nhau để mặc cả. Quyết định giá trị biến thành thương lượng chính trị. Accountability bị pha loãng đến mức không còn ai thực sự chịu trách nhiệm cho sản phẩm.
4. Trùng lặp và mâu thuẫn. Hai team không nhìn chung một backlog rất dễ xây cùng một tính năng theo hai cách khác nhau, hoặc tạo ra hai giải pháp đối nghịch cho cùng một vấn đề. Chi phí tích hợp và làm lại tăng vọt.
Vậy nhiều team phối hợp trên một backlog bằng cách nào?
Đây là câu hỏi tiếp theo rất hợp lý. Nếu chỉ có một backlog, làm sao 5 team không giẫm chân nhau? Câu trả lời nằm ở cách các framework scale giải quyết:
- Một PO, có thể thêm vai trò hỗ trợ. PO duy nhất vẫn accountable cho thứ tự backlog và giá trị. Ở quy mô lớn (như LeSS Huge), PO có thể được hỗ trợ bởi các Area Product Owner phụ trách từng "khu vực yêu cầu" (requirement area) — nhưng họ là người ủy quyền, không phải nhiều PO ngang hàng, và vẫn quy về một backlog và một PO chính.
- Team tự chọn việc qua một sự kiện chung. Trong Nexus, có Nexus Sprint Planning, nơi đại diện các team cùng nhìn một backlog và quyết định team nào lấy item nào, đồng thời nhận diện các phụ thuộc (dependencies) giữa các item. Trong LeSS, có Sprint Planning One chung để phân bổ item cho team.
- Phân chia theo "góc nhìn" chứ không "chia đôi backlog". Bạn có thể gắn nhãn (tag/filter) cho từng item theo khu vực hay theo team đang làm, để mọi người dễ lọc và nhìn. Nhưng đó chỉ là một view (góc nhìn lọc) trên cùng một backlog duy nhất — khác hoàn toàn việc tạo ra nhiều backlog vật lý độc lập. Nguồn sự thật (single source of truth) vẫn là một.
Tình huống thực tế
Ví dụ 1: Một fintech ví điện tử ở TP.HCM phình từ 1 lên 4 team
Một công ty fintech làm ví điện tử tại TP.HCM (gọi là "PayMoi") tăng trưởng nóng, từ 1 team Scrum lên 4 team trong vòng 8 tháng. Để "cho gọn", ban lãnh đạo chia sản phẩm thành 4 backlog theo mảng: Thanh toán, Nạp/Rút, Khuyến mãi, và Tài khoản/KYC. Mỗi mảng có một "Product Owner" riêng.
Sáu tháng sau, vấn đề bùng nổ. Bộ phận Tăng trưởng cần một tính năng "cashback theo nhóm bạn bè" để cạnh tranh với đối thủ — tính năng này đụng tới cả 4 mảng: thanh toán, khuyến mãi, tài khoản và cả nạp/rút. Nhưng vì có 4 backlog, 4 PO, mỗi người sắp xếp ưu tiên riêng, tính năng này nằm ở vị trí khác nhau trong từng backlog. PO Khuyến mãi đẩy nó lên đầu, PO Thanh toán xếp nó thứ 9 vì "đang bận việc khác". Kết quả: tính năng bị kẹt 3 sprint chỉ vì không ai có quyền ưu tiên xuyên các mảng. Trong khi đó đối thủ ra mắt trước.
Bài học: PayMoi sau đó hợp nhất về một Product Backlog duy nhất với một Head of Product làm PO chính, còn 4 người cũ trở thành người hỗ trợ theo khu vực. Lần ra tính năng tiếp theo, việc cross-team được ưu tiên ở cấp sản phẩm và hoàn thành trong 2 sprint. Nguyên tắc rút ra: khi việc quan trọng nhất luôn cần nhiều team, chỉ một backlog chung mới ưu tiên được nó.
Ví dụ 2: Sàn thương mại điện tử dùng filter thay vì split
Một sàn TMĐT khu vực Đông Nam Á (giả định tên "ShopGo") có 6 team cùng làm trên ứng dụng mua sắm. Họ học được bài học của người đi trước và quyết định giữ một Product Backlog duy nhất, với một Group Product Owner accountable.
Cách họ làm để không hỗn loạn: mỗi Product Backlog Item được gắn nhãn "requirement area" (ví dụ: Tìm kiếm, Giỏ hàng & Thanh toán, Khuyến mãi, Logistics). Khi cần, mỗi team mở một view đã lọc theo nhãn của họ để tập trung. Nhưng trong buổi planning chung mỗi sprint, đại diện 6 team cùng nhìn toàn bộ backlog đã sắp xếp từ trên xuống, rồi lần lượt nhận item — bắt đầu từ item giá trị cao nhất.
Điểm hay: vì backlog là một, khi mùa cao điểm 11/11 đến gần, Group PO chỉ cần kéo loạt item liên quan đến chịu tải và thanh toán lên đầu. Lập tức nhiều team cùng đổ vào khu vực đó — kể cả team Tìm kiếm tạm gác việc của mình để hỗ trợ Thanh toán. Sự linh hoạt này là bất khả thi nếu mỗi team bị khóa vào một backlog riêng.
Bài học: Filter/tag để dễ nhìn là hợp lệ và rất hữu ích. Cái cần giữ nguyên vẹn là một nguồn sự thật và một người ưu tiên toàn cục. ShopGo có được cái lợi của sự rõ ràng theo mảng mà không mất khả năng ưu tiên xuyên team.
Ví dụ 3: Công ty SaaS B2B nhầm "module" với "sản phẩm"
Một công ty SaaS B2B ở Hà Nội ("CoreHR") làm phần mềm nhân sự với các module: Chấm công, Tính lương, Tuyển dụng. Họ lập 3 team, 3 backlog, gọi mỗi module là một "sản phẩm". Thoạt nhìn có vẻ hợp lý.
Nhưng khách hàng của CoreHR mua cả gói, dùng tích hợp chặt giữa các module (dữ liệu chấm công chảy thẳng vào tính lương). Khi một khách hàng lớn yêu cầu thay đổi quy tắc tính lương theo ca làm việc, việc này đụng cả Chấm công lẫn Tính lương. Hai backlog riêng khiến hai team ưu tiên lệch nhau, bản phát hành bị trễ, và tệ hơn — không ai chịu accountable cho trải nghiệm tổng thể của khách hàng. Mỗi PO chỉ lo module của mình "đẹp".
Bài học: Phép thử quan trọng là: khách hàng coi đây là một sản phẩm hay nhiều sản phẩm? Nếu họ mua, dùng và đánh giá nó như một thể thống nhất, thì đó là một sản phẩm và phải có một backlog, dù bên trong có nhiều module. "Module" là khái niệm kỹ thuật, "sản phẩm" là khái niệm giá trị với khách hàng — đừng để ranh giới kỹ thuật quyết định cấu trúc backlog.
Hướng dẫn từng bước
Nếu bạn đang scale lên nhiều team và muốn làm đúng nguyên tắc một-backlog, đây là lộ trình thực hành:
- Xác định ranh giới sản phẩm trước tiên. Hỏi: khách hàng mua và dùng cái này như một sản phẩm hay nhiều sản phẩm độc lập? Nếu một, thì một backlog. Đừng để số lượng team hay ranh giới kỹ thuật quyết định việc này.
- Chỉ định một PO accountable rõ ràng. Một người duy nhất chịu trách nhiệm cuối cùng cho thứ tự backlog và giá trị sản phẩm. Nếu quy mô lớn, người này có thể được ủy quyền hỗ trợ, nhưng accountability không được chia đôi.
- Hợp nhất tất cả công việc về một backlog duy nhất. Gom mọi item từ các danh sách rời rạc vào một nơi. Đây là single source of truth của sản phẩm.
- Thiết lập nhãn/khu vực (tag, requirement area) — không phải nhiều backlog. Gắn nhãn cho item để dễ lọc theo mảng hoặc theo team. Mọi người dùng view đã lọc, nhưng dữ liệu gốc vẫn là một backlog.
- Sắp xếp toàn cục một lần. PO sắp thứ tự toàn bộ backlog từ trên xuống theo giá trị, bất kể item đó thuộc khu vực nào hay team nào sẽ làm.
- Dùng một sự kiện planning chung để phân bổ. Đại diện các team cùng nhìn backlog đã sắp, lần lượt nhận item từ trên xuống, đồng thời nhận diện dependencies giữa các team. (Đây là Nexus Sprint Planning hoặc Sprint Planning One trong LeSS.)
- Để team tự chọn item phù hợp năng lực. Trong khuôn khổ thứ tự ưu tiên, team chọn item họ làm tốt nhất. Việc không bị "khóa" vào một team cố định.
- Refine xuyên team định kỳ. Tổ chức buổi refinement chung để các team hiểu phụ thuộc và làm rõ item lớn trước khi vào sprint.
Lỗi thường gặp & mẹo
Lỗi: Chia backlog theo team cho "dễ quản lý". Đây là cái bẫy phổ biến nhất. Dễ quản lý cho team trưởng, nhưng phá hủy khả năng ưu tiên giá trị toàn cục. Mẹo: nếu bạn cần "nhìn riêng từng team", hãy dùng filter trên một backlog chung, đừng tạo backlog vật lý riêng.
Lỗi: Đẻ ra nhiều PO ngang hàng, mỗi người một backlog. Accountability bị pha loãng, quyết định biến thành đàm phán. Mẹo: luôn có một người accountable cuối cùng. Người khác có thể hỗ trợ, nhưng không ngang quyền quyết thứ tự.
Lỗi: Nhầm module/component kỹ thuật là sản phẩm. Dẫn đến chia backlog theo kiến trúc thay vì theo giá trị. Mẹo: dùng phép thử "khách hàng coi đây là một hay nhiều sản phẩm".
Lỗi: Coi filter là split, hoặc ngược lại sợ filter nên không gắn nhãn gì cả. Cả hai thái cực đều dở. Mẹo nhớ: một nguồn sự thật, nhiều góc nhìn. Một backlog, nhiều view lọc — đó là điểm cân bằng đúng.
Lỗi: Khóa cứng item vào team. Mất linh hoạt khi nhu cầu kinh doanh dịch chuyển. Mẹo: gắn nhãn gợi ý team phù hợp, nhưng để planning chung quyết định team nào thực sự nhận, dựa trên ưu tiên và năng lực hiện tại.
Mẹo tổng quát: Hãy luôn tự hỏi "ai là người duy nhất có thể nói item nào quan trọng nhất với sản phẩm lúc này?". Nếu câu trả lời là "phải họp các nhóm lại mới biết", bạn đang có vấn đề về cấu trúc backlog.
Bài tập thực hành
- Phép thử ranh giới sản phẩm. Lấy bối cảnh CoreHR ở Ví dụ 3 (Chấm công, Tính lương, Tuyển dụng). Viết một đoạn ngắn lập luận: đây nên là một backlog hay ba backlog? Dùng phép thử "khách hàng mua/dùng như một hay nhiều sản phẩm" để bảo vệ quan điểm của bạn.
- Phát hiện sai lầm split. Giả sử công ty bạn đang có 3 team với 3 backlog riêng. Liệt kê 4 triệu chứng cụ thể bạn dự đoán sẽ thấy trong 3 tháng tới (ví dụ: việc quan trọng bị kẹt, trùng lặp tính năng...). Với mỗi triệu chứng, ghi nó bắt nguồn từ nguyên nhân gốc nào trong bài.
- Thiết kế view thay cho split. Bạn có một sản phẩm, một backlog 80 item, và 4 team. Hãy thiết kế hệ thống nhãn (requirement area) và mô tả mỗi team sẽ dùng view lọc thế nào, đồng thời giải thích vì sao đây vẫn là một backlog chứ không phải bốn.
- Mô phỏng planning chung. Viết kịch bản 5–7 bước cho một buổi Nexus/LeSS Sprint Planning, trong đó 3 team cùng nhìn một backlog đã sắp xếp và lần lượt nhận item, có ít nhất một dependency cross-team cần xử lý.
Tóm tắt
- Khi scale Scrum cho nhiều team trên một sản phẩm: 1 sản phẩm = 1 Product Backlog = 1 PO accountable. Số lượng team không thay đổi nguyên tắc này.
- Không split backlog theo team, vì nó phá vỡ ưu tiên toàn cục, khóa việc vào silo, pha loãng accountability, và sinh trùng lặp/mâu thuẫn.
- Để nhiều team phối hợp: dùng một PO (có thể được hỗ trợ theo khu vực), một sự kiện planning chung để phân bổ item và xử lý dependencies, và filter/view để dễ nhìn — chứ không phải nhiều backlog vật lý.
- Phân biệt sống còn: filter/view ≠ split. Một nguồn sự thật, nhiều góc nhìn.
- Phép thử khi nghi ngờ: khách hàng coi đây là một hay nhiều sản phẩm? Đừng để ranh giới kỹ thuật (module, component, team) quyết định cấu trúc backlog — hãy để giá trị với khách hàng quyết định.