Mở đầu — vì sao bài này quan trọng
Nếu bạn đang ôn thi PSPO I, đây là một trong những bài "ăn điểm" chắc chắn nhất — nhưng cũng là nơi nhiều người mất điểm oan. Lý do là vì trong thực tế công việc tại Việt Nam, ranh giới giữa ba accountabilities (trách nhiệm giải trình) của Scrum Team thường bị xóa nhòa. Một Product Owner ở công ty outsourcing có thể đang kiêm luôn việc estimate, phân công task cho dev, viết test case. Một Scrum Master có khi lại ngồi quyết định feature nào làm trước. Khi đi thi, những thói quen "lai tạp" này khiến bạn chọn đáp án sai vì bạn trả lời theo thực tế công ty mình, chứ không theo Scrum Guide.
PSPO I không kiểm tra xem công ty bạn vận hành thế nào. Nó kiểm tra xem bạn có hiểu Scrum đúng bản chất hay không. Và bản chất đó nằm ở một câu rất gọn trong Scrum Guide 2020: Scrum Team gồm ba accountabilities riêng biệt — Product Owner, Scrum Master, và Developers — không có sub-team, không có hierarchy (cấp bậc). Mỗi accountability sở hữu một thứ khác nhau, và không ai được lấn sân của ai.
Bài này sẽ giúp bạn phân biệt rạch ròi ba vai trò: ai sở hữu cái gì, ai quyết định cái gì, và quan trọng nhất — ranh giới ở đâu. Khi đã nắm vững, bạn không chỉ trả lời đúng câu hỏi thi mà còn tránh được những anti-pattern phá nát một Scrum Team thật.
Khái niệm cốt lõi
Scrum Guide 2020 định nghĩa Scrum Team là một đơn vị gắn kết gồm các chuyên gia, tập trung vào một mục tiêu duy nhất tại một thời điểm: Product Goal. Trong đơn vị đó có ba accountabilities. Lưu ý từ "accountability" — đây là trách nhiệm giải trình cuối cùng, nghĩa là người chịu trách nhiệm khi mọi thứ đúng hoặc sai, dù họ có tự tay làm hết hay không.
Product Owner — người chịu trách nhiệm về giá trị
Product Owner (PO) chịu trách nhiệm tối đa hóa value (giá trị) của sản phẩm sinh ra từ công việc của Scrum Team. Cách họ làm điều đó có thể khác nhau giữa các tổ chức, nhưng những thứ PO sở hữu thì cố định:
- Product Backlog: PO sở hữu Product Backlog. Họ phát triển và truyền đạt Product Goal một cách tường minh, tạo và sắp xếp (order) các Product Backlog Item, đảm bảo backlog minh bạch và dễ hiểu.
- Product Goal: PO là người chịu trách nhiệm về Product Goal — đích đến dài hạn của sản phẩm.
- Ordering: PO quyết định thứ tự công việc trong Product Backlog. Đây là quyền của PO, không phải Scrum Master hay stakeholder.
- Quyết định release: PO quyết định khi nào Increment được phát hành (mặc dù Increment có thể được release bất kỳ lúc nào trong Sprint).
Scrum Master — người chịu trách nhiệm về tính hiệu quả của Scrum
Scrum Master (SM) chịu trách nhiệm thiết lập Scrum như định nghĩa trong Scrum Guide, bằng cách giúp mọi người hiểu lý thuyết và thực hành Scrum. SM chịu trách nhiệm về tính hiệu quả (effectiveness) của Scrum Team.
Điểm cực kỳ quan trọng mà Scrum Guide 2020 nhấn mạnh: Scrum Master là một leader thực thụ phục vụ (true leader who serves) — không còn dùng cụm "servant leader" mơ hồ nữa. SM phục vụ ba đối tượng:
- Phục vụ Scrum Team: huấn luyện team tự quản lý và cross-functional, giúp team tập trung tạo Increment giá trị cao đạt Definition of Done, gỡ bỏ trở ngại (impediments).
- Phục vụ Product Owner: giúp PO tìm kỹ thuật quản lý Product Goal và Product Backlog hiệu quả, giúp team hiểu cần Product Backlog Item rõ ràng và súc tích, hỗ trợ empirical product planning.
- Phục vụ tổ chức: dẫn dắt, đào tạo, coaching tổ chức trong việc áp dụng Scrum, loại bỏ rào cản giữa stakeholder và Scrum Team.
Developers — người chịu trách nhiệm tạo ra Increment
Developers là những người trong Scrum Team cam kết tạo ra bất kỳ khía cạnh nào của một Increment có thể sử dụng được trong mỗi Sprint. "Developers" ở đây không chỉ là lập trình viên — mà là bất kỳ ai làm công việc xây dựng sản phẩm: tester, designer, business analyst, data engineer...
Developers luôn chịu trách nhiệm:
- Tạo Sprint Plan — tức Sprint Backlog.
- Đảm bảo chất lượng bằng cách tuân thủ Definition of Done.
- Tự điều chỉnh kế hoạch mỗi ngày hướng tới Sprint Goal.
- Estimate: Developers là người ước lượng công việc. PO không estimate hộ, không áp con số.
- Quyết định cách làm: Developers tự tổ chức cách biến Product Backlog Item thành Increment. Họ chịu trách nhiệm với nhau như những chuyên gia.
Bảng phân định nhanh — ai sở hữu cái gì
| Hạng mục | Product Owner | Scrum Master | Developers |
|---|---|---|---|
| Product Backlog (nội dung & thứ tự) | Sở hữu | Hỗ trợ | Refine cùng PO |
| Product Goal | Chịu trách nhiệm | Coaching | Góp ý |
| Sprint Backlog | Góp ý "what" | Hỗ trợ | Sở hữu |
| Estimate | Không | Không | Sở hữu |
| Cách triển khai kỹ thuật | Không | Không | Sở hữu |
| Definition of Done (tuân thủ) | — | Coaching | Sở hữu việc tuân thủ |
| Hiệu quả của Scrum | — | Chịu trách nhiệm | — |
| Quyết định release | Sở hữu | — | — |
| Tối đa hóa giá trị | Chịu trách nhiệm | — | — |
Tình huống thực tế
Tình huống 1 — PO "lấn sân" tại một fintech ở TP.HCM
Anh Tuấn là Product Owner cho một ứng dụng ví điện tử tại một fintech khoảng 40 người ở Quận 1. Anh xuất thân từ kỹ thuật, nên trong Sprint Planning, anh thường nói thẳng: "Cái API này dùng Redis cache, mỗi item tôi tính 3 ngày, chia cho 4 bạn dev là xong trong Sprint." Anh còn tự gán task cho từng dev trên Jira.
Kết quả sau ba Sprint: velocity tụt, hai dev giỏi xin nghỉ, và các estimate của anh Tuấn luôn lệch vì anh không còn code hằng ngày nên không nắm hết độ phức tạp thực tế của codebase.
Diễn giải: Anh Tuấn đã xâm phạm vùng trách nhiệm của Developers ở ba điểm — estimate, quyết định cách triển khai kỹ thuật, và phân công công việc. Theo Scrum, Developers tự estimate và tự tổ chức cách làm. PO chỉ chịu trách nhiệm về cái gì và thứ tự ưu tiên, không phải làm thế nào và ai làm việc gì. Khi PO lấn sân, Developers mất quyền tự quản (self-management), mất động lực, và chất lượng estimate cũng tệ đi vì người estimate không phải người trực tiếp làm.
Bài học: PO định nghĩa vấn đề cần giải quyết và mức ưu tiên; Developers quyết định giải pháp kỹ thuật và công sức bỏ ra. Trong đề thi PSPO I, bất kỳ đáp án nào để PO ấn định estimate hoặc phân công task gần như chắc chắn là đáp án sai.
Tình huống 2 — Scrum Master "kiêm" Product Owner ở một startup edtech
Tại một startup edtech ở Hà Nội, vì thiếu người, chị Lan giữ vai trò Scrum Master nhưng đồng thời quyết định feature nào ưu tiên vì "chị hiểu thị trường nhất". Mỗi Sprint Planning, chị tự sắp xếp backlog rồi mới mời team vào. PO trên danh nghĩa là anh Hùng — nhưng anh chỉ ngồi ghi chép.
Sáu tháng sau, sản phẩm đi lệch hướng kinh doanh. Khi nhà đầu tư hỏi "ai chịu trách nhiệm về định hướng sản phẩm", không ai trả lời rõ — vì accountability bị chia đôi mơ hồ.
Diễn giải: Đây là anti-pattern kinh điển. Scrum Master tạo điều kiện cho quá trình; Product Owner quyết định nội dung và thứ tự sản phẩm. Khi một người cố gánh cả hai một cách lẫn lộn, không ai thực sự chịu trách nhiệm về giá trị sản phẩm, và cũng không ai thực sự bảo vệ tính hiệu quả của Scrum một cách khách quan. Scrum Guide không cấm tuyệt đối một người kiêm nhiều vai, nhưng các accountabilities phải tách bạch rõ ràng — và thực tế việc kiêm SM + PO gây xung đột lợi ích nghiêm trọng: SM lẽ ra phải coaching PO làm tốt hơn, nhưng làm sao tự coaching chính mình?
Bài học: Accountability phải có chủ rõ ràng. Nếu một người kiêm hai vai, hãy tự hỏi: khi cần đưa ra quyết định ưu tiên gây tranh cãi, "chiếc mũ" nào đang được đội? Trong đề thi, hãy nhớ: SM không sở hữu backlog và không quyết định thứ tự ưu tiên — đó là việc của PO.
Tình huống 3 — Stakeholder muốn ra lệnh cho Developers tại Shopee/Grab kiểu môi trường
Hãy hình dung một team thuộc một công ty thương mại điện tử lớn ở Đông Nam Á (kiểu Shopee, Grab). Một giám đốc kinh doanh (stakeholder) bực vì tính năng khuyến mãi chậm, nên anh ta đi thẳng xuống chỗ Developers giữa Sprint, yêu cầu họ "bỏ task hiện tại, làm ngay tính năng flash sale cho kịp 12.12".
Developers bối rối: nghe stakeholder thì phá vỡ Sprint Goal, không nghe thì sợ mất lòng sếp lớn.
Diễn giải: Trong Sprint, chỉ có Scrum Team mới được điều chỉnh Sprint Backlog, và phạm vi (scope) có thể được làm rõ và đàm phán lại với PO khi hiểu biết tăng lên — chứ không phải stakeholder nhảy vào ra lệnh trực tiếp cho Developers. Mọi yêu cầu về cái gì cần làm và ưu tiên ra sao phải đi qua Product Owner. Vai trò của Scrum Master ở đây là loại bỏ rào cản và bảo vệ team: giải thích cho stakeholder rằng kênh đúng là làm việc với PO để đưa yêu cầu vào backlog và bàn ưu tiên. Quyền hủy Sprint, nếu Sprint Goal trở nên lỗi thời, cũng thuộc về PO — không phải stakeholder, không phải Developers.
Bài học: Ba accountabilities của Scrum Team là một "lá chắn" có cấu trúc. Stakeholder tác động đến sản phẩm thông qua PO. Developers bảo vệ Sprint Goal. Scrum Master bảo vệ tính toàn vẹn của quá trình. Khi mỗi người đứng đúng vị trí, áp lực bên ngoài không phá vỡ được nhịp làm việc của team.
Hướng dẫn từng bước
Khi bạn gặp một câu hỏi (trong thi hoặc trong công việc) kiểu "Ai nên làm việc X?", hãy đi qua các bước sau:
- Xác định bản chất của việc X. Nó liên quan đến giá trị/sản phẩm/ưu tiên/khách hàng? → nghiêng về PO. Liên quan đến cách xây dựng/chất lượng kỹ thuật/estimate? → Developers. Liên quan đến quá trình Scrum/coaching/gỡ trở ngại? → Scrum Master.
- Hỏi: đây là "what" hay "how"? "What cần làm và theo thứ tự nào" là của PO. "How để làm ra nó" là của Developers. Đây là ranh giới phân định mạnh nhất giữa PO và Developers.
- Kiểm tra có ai đang ra lệnh không. Scrum không có hierarchy. Nếu đáp án mô tả ai đó "ra lệnh", "phân công task", "ép buộc" — gần như chắc chắn sai. Self-managing team tự quyết cách làm.
- Kiểm tra quyền sở hữu (single accountable). Product Backlog có một chủ duy nhất là PO. Sprint Backlog thuộc Developers. Nếu đáp án để "cả team vote" cho việc thuộc quyền PO (ví dụ thứ tự backlog), hãy cảnh giác.
- Hỏi: mục tiêu cuối cùng là gì? Tối đa hóa giá trị → PO chịu trách nhiệm. Tăng tính hiệu quả của team/tổ chức → SM. Tạo Increment đạt DoD → Developers.
- Loại trừ phương án "lai vai". Bất kỳ đáp án nào trộn lẫn trách nhiệm (PO estimate, SM order backlog, stakeholder điều khiển Sprint) thường là bẫy.
Lỗi thường gặp & mẹo
- Nhầm PO là "sếp" của Developers. Sai. Trong Scrum không có cấp bậc. PO không quản lý nhân sự, không đánh giá hiệu suất theo nghĩa quản lý dòng. PO ngang hàng với Developers, chỉ khác accountability.
- Cho rằng Scrum Master "chạy" các sự kiện và quyết định mọi thứ về quá trình. SM đảm bảo các sự kiện diễn ra và hiệu quả, nhưng không "sở hữu" chúng theo kiểu độc đoán. Daily Scrum là của Developers; Sprint Review là buổi làm việc cộng tác. SM tạo điều kiện chứ không kiểm soát.
- Để PO estimate. Trong rất nhiều công ty Việt Nam, PO/PM tự áp deadline và effort. Theo Scrum, chỉ Developers mới estimate. Mẹo thi: thấy "PO estimate" → loại.
- Nghĩ Developers chỉ là coder. Developers gồm mọi vai trò xây dựng sản phẩm: QA, designer, BA, DevOps. Không có chức danh con (sub-role) chính thức bên trong Developers theo Scrum.
- Tin rằng stakeholder có thể đổi Sprint Backlog. Chỉ Scrum Team điều chỉnh trong Sprint. Yêu cầu mới đi qua PO và Product Backlog.
- Mẹo "ba câu hỏi vàng": Với mọi tình huống, tự hỏi (1) Đây là việc về giá trị, quá trình, hay xây dựng? (2) Là "what" hay "how"? (3) Có vi phạm nguyên tắc không-hierarchy không? Ba câu này giải quyết phần lớn câu hỏi phân vai trong PSPO I.
- Cảnh giác từ khóa tuyệt đối. Đáp án chứa "luôn luôn", "phải xin phép Scrum Master", "PO ra lệnh cho dev" thường sai. Scrum đề cao tự quản và cộng tác, không phải mệnh lệnh.
Bài tập thực hành
- Phân loại trách nhiệm: Với mỗi việc sau, ghi PO / SM / Developers: (a) Sắp xếp thứ tự Product Backlog; (b) Ước lượng độ phức tạp của một item; (c) Gỡ một trở ngại tổ chức cản team; (d) Quyết định release Increment; (e) Tạo Sprint Backlog; (f) Coaching tổ chức về Scrum; (g) Đảm bảo tuân thủ Definition of Done; (h) Truyền đạt Product Goal.
- Sửa anti-pattern: Quay lại Tình huống 1 (anh Tuấn). Viết 4-5 câu mô tả anh Tuấn nên hành xử thế nào trong Sprint Planning để tôn trọng accountability của Developers, mà vẫn đảm bảo team hiểu rõ ưu tiên kinh doanh.
- Câu hỏi tình huống: Một stakeholder yêu cầu Developers thêm tính năng giữa Sprint. Hãy mô tả phản ứng đúng của (a) Developers, (b) Scrum Master, (c) Product Owner — mỗi vai một hành động phù hợp với accountability của họ.
- Tự kiểm tra ranh giới: Liệt kê 3 việc mà ở công ty hiện tại của bạn (hoặc một công ty bạn biết) đang bị "lai vai", và chỉ ra theo Scrum thì ai mới đúng là người chịu trách nhiệm.
Tóm tắt
Scrum Team có ba accountabilities ngang hàng, không có cấp bậc, cùng hướng về một Product Goal:
- Product Owner chịu trách nhiệm tối đa hóa giá trị. Sở hữu Product Backlog, chịu trách nhiệm Product Goal, quyết định thứ tự (ordering) và quyết định release. PO là một con người, không phải ủy ban; cả tổ chức phải tôn trọng quyết định của PO.
- Scrum Master chịu trách nhiệm về tính hiệu quả của Scrum. Là leader thực thụ phục vụ Team, PO và tổ chức. Tạo điều kiện, coaching, gỡ trở ngại — không sở hữu sản phẩm, không quyết ưu tiên.
- Developers chịu trách nhiệm tạo ra Increment đạt Definition of Done. Sở hữu Sprint Backlog, tự estimate, tự quyết cách triển khai, tự điều chỉnh kế hoạch mỗi ngày.