Bài 38 — Multiple Scrum Teams trên cùng Product

Mở đầu — vì sao bài này quan trọng

Trong các lớp luyện thi PSM I mà tôi đứng giảng, có một dạng câu hỏi gần như chắc chắn xuất hiện và khiến rất nhiều học viên mất điểm oan: "Khi có nhiều Scrum Team cùng làm việc trên một sản phẩm, họ chia sẻ những gì?". Học viên thường trả lời theo trực giác — mỗi team một Product Backlog riêng, mỗi team một Product Owner riêng cho gọn — và đó chính là cái bẫy.

Scrum Guide 2020 đưa ra một thông điệp rất rõ ràng nhưng lại dễ bị bỏ qua: dù bạn có 1 team hay 10 team cùng phát triển một sản phẩm, thì vẫn chỉ có một Product Backlog, một Product Goal, và một Product Owner. Đây không phải chi tiết kỹ thuật vụn vặt — nó là hệ quả trực tiếp của cách Scrum định nghĩa "sản phẩm" và cách empiricism (thực nghiệm) vận hành.

Bài này tập trung đúng vào tình huống "multiple Scrum Teams trên cùng một product". Tôi sẽ không lan sang chủ đề scaling framework (như Nexus, LeSS — đó là bài 25 và bài 38 chỉ chạm rất nhẹ), không đi sâu vào Definition of Done (bài 20) hay phân biệt Product Backlog vs Sprint Backlog (bài 45). Mục tiêu của chúng ta hôm nay rất gọn: hiểu thật chắc Scrum Guide 2020 nói gì về việc nhiều team chia sẻ một sản phẩm, và vì sao nó phải như vậy. Nắm vững phần này, bạn sẽ trả lời đúng cả một nhóm câu hỏi trong đề thi mà người khác đoán mò.

Khái niệm cốt lõi

Điểm tựa: định nghĩa "Product" trong Scrum Guide

Scrum Guide 2020 định nghĩa: "A Product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers." Tức là một sản phẩm được xác định bởi giá trị nó mang lại và ranh giới của nó, chứ không phải bởi số lượng team đang làm.

Khi nhiều team cùng làm một sản phẩm, bản chất vẫn là một sản phẩm duy nhất. Vì vậy mọi thứ gắn với "sản phẩm" cũng phải là số ít. Đây là cách dễ nhớ nhất để suy ra mọi quy tắc còn lại.

Quy tắc 1 — Một Product Backlog

Scrum Guide ghi rõ trong phần Product Backlog: "If multiple Scrum Teams work together on a Product, one Product Backlog is used to describe the upcoming work on the Product."

Nghĩa là: dù 5 team cùng làm, vẫn chỉ có một Product Backlog chứa toàn bộ công việc sắp tới của sản phẩm. Không có chuyện "Backlog của team A" và "Backlog của team B" tồn tại như hai artifact độc lập, ngang hàng. Khi đến mỗi Sprint, các team lấy việc từ Product Backlog chung này để kéo vào Sprint Backlog riêng của họ. Sprint Backlog thì mỗi team có một cái — đó mới là artifact thuộc về team.

Hãy phân biệt rạch ròi: một Product Backlog (chung) → nhiều Sprint Backlog (mỗi team một cái). Đây là điểm thi rất hay xoáy.

Quy tắc 2 — Một Product Goal

Product Goal là commitment (cam kết) của Product Backlog. Vì Product Backlog là số ít, nên Product Goal cũng là số ít. Scrum Guide: "A Product Backlog... has a single Product Goal."

Tất cả các team — dù làm những phần khác nhau của sản phẩm — đều hướng về cùng một Product Goal. Product Goal mô tả trạng thái tương lai của sản phẩm, đóng vai trò mục tiêu dài hạn để mọi team định hướng. Nếu mỗi team đặt một Product Goal riêng, bạn không còn một sản phẩm thống nhất nữa — bạn có nhiều sản phẩm rời rạc đang vô tình dùng chung tên gọi.

Quy tắc 3 — Một Product Owner

Đây là điểm gây nhiều tranh cãi nhất trong thực tế nhưng lại dứt khoát nhất trong Scrum Guide. Phần Product Owner ghi: "The Product Owner is one person, not a committee." Và vì sản phẩm là số ít, Product Backlog là số ít, thì người chịu trách nhiệm tối đa hóa giá trị và quản trị Product Backlog cũng là một người duy nhất.

Nhiều người hỏi tôi: "5 team thì 1 PO sao kham nổi?". Câu trả lời của Scrum: PO chịu trách nhiệm (accountable) cho việc quản trị Product Backlog, nhưng PO có thể ủy quyền (delegate) phần việc thực thi — ví dụ nhờ Developers, Business Analyst, hoặc đại diện từ các team giúp soạn thảo, refine từng mục backlog. Tuy nhiên dù ủy quyền cho ai, PO vẫn là người chịu trách nhiệm cuối cùng (remains accountable). Ủy quyền công việc không có nghĩa là chia nhỏ trách nhiệm thành nhiều PO.

Quy tắc 4 — Mutually-defined Definition of Done

Phần dàn ý gốc ghi chữ "Mutually-define" còn dang dở, đây chính là quy tắc thứ tư. Scrum Guide nói: "If there are multiple Scrum Teams working together on a Product, they must mutually define and comply with the same Definition of Done."

Nghĩa là khi nhiều team cùng làm một sản phẩm, họ phải cùng nhau định nghĩa và cùng tuân thủ một Definition of Done chung. Lý do rất logic: tất cả các team đều góp phần tạo ra Increment cho cùng một sản phẩm. Nếu team A coi "done" là đã test, còn team B coi "done" chỉ là code xong chưa test, thì Increment ghép lại sẽ không có chất lượng đồng nhất — transparency (tính minh bạch) bị phá vỡ, và stakeholder không thể tin vào trạng thái thực của sản phẩm. (Chi tiết về DoD nằm ở bài 20; ở đây ta chỉ cần nhớ: nhiều team → một DoD chung, định nghĩa cùng nhau.)

Tóm lại bằng một bảng tư duy

Tình huống thực tế

Ví dụ 1 — Ví Tikop và bài học "một PO duy nhất"

Hình dung một công ty fintech giả định ở TP.HCM, gọi là TikPay, đang xây dựng ứng dụng ví điện tử. Sản phẩm lớn dần, họ tách thành 3 Scrum Team: team Payments (thanh toán), team KYC (định danh khách hàng), và team Rewards (tích điểm, khuyến mãi). Ban đầu, mỗi team được giao một "PO" riêng để chạy cho nhanh.

Sau 4 Sprint, vấn đề lộ ra. Team Payments ưu tiên tính năng quét QR, team KYC ưu tiên xác thực khuôn mặt, team Rewards ưu tiên vòng quay may mắn. Mỗi "PO" tối ưu cho phần của mình, nhưng không ai chịu trách nhiệm cho giá trị tổng thể của sản phẩm. Kết quả: app ra mắt với vòng quay may mắn hào nhoáng nhưng luồng nạp tiền cốt lõi vẫn lỗi, vì không có ai cầm trịch ưu tiên trên toàn cục.

Họ sửa lại đúng theo Scrum Guide: chỉ định một Product Owner duy nhất cho toàn ứng dụng, quản trị một Product Backlog chung với một Product Goal: "Trở thành ví điện tử nạp – chuyển – thanh toán nhanh và an toàn nhất cho người dùng phổ thông tại Việt Nam". Ba người từng làm "PO" được chuyển thành các đại diện hỗ trợ refine backlog (được PO ủy quyền), nhưng quyền quyết định thứ tự ưu tiên cuối cùng nằm ở một người.

Bài học rút ra: Nhiều team không sinh ra nhiều PO. PO là một người, accountable cho giá trị toàn sản phẩm; phần việc nặng có thể delegate, nhưng accountability thì không chia nhỏ.

Ví dụ 2 — Sàn TMĐT khu vực và "một Product Backlog"

Một sàn thương mại điện tử giả định ở Đông Nam Á, gọi là ShopSEA, có 6 Scrum Team cùng làm trên nền tảng mua sắm: Search, Checkout, Seller Tools, Logistics, Mobile App, Payments. Vì sợ "rối", trước đây mỗi team tự duy trì một file backlog riêng trên công cụ của mình.

Hệ quả: khi giám đốc sản phẩm hỏi "ưu tiên cao nhất của nền tảng quý này là gì?", không ai trả lời được — có 6 danh sách ưu tiên song song, mâu thuẫn nhau. Team Checkout làm tính năng "mua trước trả sau" mà team Payments chưa hề đưa vào kế hoạch backend, dẫn đến tính năng treo nửa chừng giữa hai Sprint.

Họ hợp nhất về một Product Backlog duy nhất cho cả nền tảng. Mọi hạng mục — dù thuộc Search hay Logistics — đều nằm trong danh sách ấy, được sắp xếp theo một thứ tự ưu tiên chung dưới quyền một PO. Đến mỗi Sprint, từng team kéo các mục phù hợp năng lực của mình vào Sprint Backlog riêng. Giờ đây, một tính năng cần cả Checkout lẫn Payments sẽ được nhìn thấy như một dependency rõ ràng trên cùng một Backlog, và hai team cùng kéo vào trong một Sprint.

Bài học rút ra: Một Product Backlog chung tạo ra transparency — ai cũng thấy bức tranh toàn cảnh và thứ tự ưu tiên thật. "Backlog của riêng team" thực chất chính là Sprint Backlog, không phải Product Backlog thứ hai.

Ví dụ 3 — Ngân hàng số và "một Definition of Done chung"

Một dự án ngân hàng số giả định, NeoBank, có 2 Scrum Team cùng xây tính năng mở tài khoản online. Mỗi team tự định nghĩa "Done". Team Frontend coi "Done" là giao diện chạy được trên trình duyệt. Team Backend coi "Done" là API trả về đúng dữ liệu — nhưng chưa bao gồm kiểm thử bảo mật.

Cuối Sprint, hai phần ghép lại. Trong Sprint Review, stakeholder dùng thử và mọi thứ trông "xong". Nhưng một tuần sau, đội kiểm thử độc lập phát hiện API mở tài khoản chưa rà soát lỗ hổng. Increment tưởng đã "Done" hóa ra không thật sự Done — niềm tin của stakeholder vào trạng thái sản phẩm bị lung lay.

Đúng theo Scrum Guide, hai team ngồi lại mutually define một Definition of Done chung cho sản phẩm: bao gồm code review, unit test, kiểm thử bảo mật cơ bản, và tài liệu API. Từ đó, mọi Increment do bất kỳ team nào tạo ra đều đạt cùng một mức chất lượng. Increment ghép lại trở nên đáng tin.

Bài học rút ra: Nhiều team trên cùng sản phẩm thì DoD không thể "mỗi team một kiểu". Họ phải cùng định nghĩa và cùng tuân thủ một DoD để Increment hợp nhất luôn ở trạng thái có thể tin được.

Hướng dẫn từng bước

Nếu bạn gặp một câu hỏi PSM I (hoặc một tình huống thật) về nhiều team trên cùng sản phẩm, hãy suy luận theo các bước sau:

• Xác nhận đây có thật sự là MỘT sản phẩm không. Nếu các team làm những sản phẩm thật sự riêng biệt (ranh giới, người dùng, giá trị khác nhau), thì chúng là các sản phẩm khác nhau và mỗi cái có Backlog/PO riêng. Quy tắc "số ít" chỉ áp dụng khi đó là một sản phẩm.

• Quy mọi thứ gắn với "sản phẩm" về số ít. Một sản phẩm → một Product Backlog → một Product Goal → một Product Owner. Đây là phản xạ cốt lõi cần luyện.

• Quy mọi thứ gắn với "team/Sprint" về số nhiều. Mỗi team có Sprint Backlog riêng, Sprint Goal riêng, Daily Scrum riêng. Việc nhiều team không xóa bỏ tính tự quản của từng team.

• Áp quy tắc DoD chung. Nhiều team → một Definition of Done được định nghĩa cùng nhau (mutually-defined) và mọi team tuân thủ.

• Phân biệt accountability và delegation cho PO. PO accountable cho Product Backlog và giá trị; PO có thể ủy quyền việc refine/soạn thảo, nhưng vẫn là người chịu trách nhiệm. Đừng để bị bẫy bởi phương án "có nhiều PO" hay "một hội đồng PO".

• Kiểm tra tính minh bạch của Increment chung. Các team đóng góp vào Increment của cùng một sản phẩm; Increment đó phải đạt DoD chung mới được coi là hoàn thành.

Lỗi thường gặp & mẹo

Lỗi 1 — Nghĩ mỗi team có Product Backlog riêng. Sai. Một sản phẩm chỉ có một Product Backlog. Cái mà mỗi team sở hữu riêng là Sprint Backlog. Nhầm hai khái niệm này là lỗi kinh điển trong đề thi.

Lỗi 2 — Nghĩ mỗi team có một Product Owner. Sai. Một sản phẩm = một PO (một người, không phải hội đồng). Nếu thấy phương án "mỗi team một PO" hoặc "một nhóm PO cùng quản lý Backlog", hãy cảnh giác — gần như chắc chắn đó là đáp án sai.

Lỗi 3 — Nghĩ mỗi team đặt Product Goal riêng. Sai. Product Goal là số ít, gắn với Product Backlog số ít. Mỗi team có Sprint Goal riêng cho Sprint của mình, nhưng tất cả vẫn hướng về một Product Goal chung.

Lỗi 4 — Để mỗi team có Definition of Done riêng. Sai. Nhiều team phải mutually define một DoD chung. Hãy nhớ từ khóa "mutually define and comply with the same Definition of Done".

Lỗi 5 — Nghĩ rằng PO không được ủy quyền gì cả. Cũng sai theo hướng ngược lại. PO được phép delegate công việc refine backlog; điều bất biến là PO vẫn remains accountable. Phân biệt "làm việc" (có thể giao) và "chịu trách nhiệm" (không chia nhỏ).

Mẹo ghi nhớ nhanh: Hãy thuộc lòng công thức "1 sản phẩm → 1 Backlog, 1 Goal, 1 PO, 1 DoD chung; còn lại theo team thì nhân nhiều lên". Khi đọc câu hỏi, chỉ cần tách đối tượng là "thuộc về sản phẩm" hay "thuộc về team", bạn sẽ chọn đúng gần như mọi lần.

Mẹo phản xạ trong phòng thi: Bất cứ khi nào thấy cụm "multiple Scrum Teams on the same product", lập tức nghĩ tới ba con số 1-1-1 (Backlog, Goal, PO) cộng với DoD chung. Đó là khung trả lời "by the book" mà PSM I mong đợi.

Bài tập thực hành

• Tự kiểm tra khái niệm: Không nhìn lại bài, hãy viết ra: khi có 4 Scrum Team cùng làm một sản phẩm, mỗi yếu tố sau có bao nhiêu — Product Backlog, Product Goal, Product Owner, Definition of Done, Sprint Backlog, Sprint Goal? Sau đó đối chiếu với bảng trong phần "Khái niệm cốt lõi".

• Phân tích tình huống: Một công ty có 3 team cùng làm app giao đồ ăn, nhưng mỗi team báo cáo cho một PO khác nhau và mỗi PO giữ một danh sách ưu tiên riêng. Hãy chỉ ra ít nhất 2 vấn đề điều này gây ra, và mô tả cấu trúc đúng theo Scrum Guide.

• Bẫy đề thi: Tự soạn 2 câu hỏi trắc nghiệm 4 phương án về chủ đề này, trong đó cố tình cài một phương án "mỗi team có Product Backlog riêng" và một phương án "có một hội đồng PO". Giải thích vì sao chúng sai. Bài tập này giúp bạn "miễn nhiễm" với bẫy khi vào phòng thi.

• Vận dụng DoD: Mô tả một kịch bản trong đó hai team trên cùng sản phẩm dùng DoD khác nhau, và giải thích bằng ngôn ngữ empiricism (transparency) vì sao điều đó phá vỡ niềm tin vào Increment.

Tóm tắt

• Khi nhiều Scrum Team cùng làm trên một sản phẩm, mọi thứ gắn với sản phẩm đều là số ít: một Product Backlog, một Product Goal, một Product Owner (một người, có thể delegate nhưng vẫn accountable).
• Các team phải cùng nhau định nghĩa và tuân thủ một Definition of Done chung (mutually-defined), để Increment hợp nhất luôn ở trạng thái đáng tin cậy.
• Cái mà mỗi team sở hữu riêng là Sprint Backlog và Sprint Goal, không phải Product Backlog hay Product Goal.
• Lý do nền tảng: một sản phẩm có một ranh giới giá trị; sự thống nhất về Backlog, Goal, PO và DoD chính là điều bảo vệ transparency của empiricism khi nhiều team cùng đóng góp.
• Phản xạ trong phòng thi: thấy "multiple teams, one product" → nhớ ngay 1 Backlog, 1 Goal, 1 PO, 1 DoD chung, còn các yếu tố cấp team thì nhân theo số team.