Mở đầu — vì sao bài này quan trọng
Bạn đã đi qua 58 bài lý thuyết về Scrum, về Product Owner, về cách maximize value. Nhưng khi ngồi vào phòng thi PSPO I — 80 câu hỏi, 60 phút, pass mark 85% (tức chỉ được sai tối đa 12 câu) — bạn sẽ nhận ra một sự thật phũ phàng: biết Scrum Guide không đồng nghĩa với việc trả lời đúng câu hỏi PSPO I.
Lý do là các câu hỏi của Scrum.org được thiết kế cực kỳ tinh vi. Chúng không hỏi "Sprint dài bao nhiêu?" theo kiểu học thuộc lòng. Chúng đặt bạn vào một tình huống thực tế, cho bạn 3–4 phương án đều "nghe có vẻ đúng", và buộc bạn phải chọn phương án phản ánh đúng tư duy Scrum, đúng accountability của từng vai trò, và đúng tinh thần empiricism. Một câu trả lời có thể đúng trong đời thực ở công ty bạn, nhưng SAI theo Scrum Guide — và Scrum.org chỉ chấm theo Scrum Guide.
Bài này không dạy thêm lý thuyết mới. Nhiệm vụ của nó là dạy bạn cách ĐỌC và GIẢI một câu hỏi PSPO I — quy trình suy luận từng bước, cách loại trừ phương án sai, cách nhận diện "bẫy ngôn ngữ". Chúng ta sẽ mổ xẻ chi tiết một câu hỏi mẫu kinh điển (câu về Sprint Goal bị lỗi thời giữa Sprint), rồi áp dụng cùng phương pháp cho 2 câu nữa. Sau bài này, bạn sẽ có một "khung tư duy giải đề" để mang vào phòng thi — và cả vào công việc thật.
Khái niệm cốt lõi
Cấu trúc một câu hỏi PSPO I
Mỗi câu hỏi thường có ba thành phần:
- Stem (phần thân) — mô tả bối cảnh, đôi khi rất dài để gài thông tin nhiễu.
- Lead-in (câu hỏi chính) — "What should the PO do?", "Who is responsible for...?", "Which of the following is true?".
- Options (phương án) — single choice (1 đúng), multiple choice (chọn nhiều), hoặc True/False.
Bốn loại "bẫy" phổ biến
- Bẫy đời thực vs Scrum Guide: phương án mô tả điều mà nhiều công ty thực sự làm (PO ra lệnh cho Developers, Scrum Master "phê duyệt" backlog) nhưng trái Scrum Guide.
- Bẫy tuyệt đối hóa: phương án chứa từ "always", "never", "must immediately" — Scrum hiếm khi tuyệt đối, nên các từ này thường là dấu hiệu sai (trừ vài accountability cứng như "chỉ PO mới cancel Sprint").
- Bẫy vai trò sai: gán việc của Developers cho Scrum Master, gán việc của PO cho cả team, v.v.
- Bẫy "nghe hợp lý nhưng không phải Scrum": ví dụ "viết tài liệu chi tiết để bàn giao", "lập kế hoạch toàn bộ release trước khi bắt đầu" — hợp lý ở waterfall, không thuộc tinh thần Scrum.
Nguyên tắc vàng khi phân vân
Khi bị kẹt giữa hai phương án, hãy hỏi bản thân ba câu:
- Phương án nào tôn trọng empiricism (inspect & adapt, minh bạch) hơn?
- Phương án nào tôn trọng self-management của Scrum Team hơn (thay vì áp đặt từ trên xuống)?
- Phương án nào maximize value và đặt người dùng/khách hàng làm trọng tâm hơn?
Tình huống thực tế
Ví dụ 1 — Câu hỏi mẫu trung tâm: Sprint Goal bị lỗi thời
> Q1. Trong một Sprint, Product Owner nhận ra một yêu cầu mới từ thị trường khiến Sprint Goal trở nên lỗi thời (obsolete). PO nên làm gì? > > A. Yêu cầu Developers dừng công việc hiện tại ngay lập tức và bắt đầu làm theo yêu cầu mới. > B. Đợi đến Sprint Review để trình bày yêu cầu mới với stakeholders. > C. Cân nhắc hủy Sprint (cancel the Sprint), vì Sprint Goal đã trở nên lỗi thời. > D. Thêm yêu cầu mới vào Sprint Backlog hiện tại và mở rộng Sprint thêm vài ngày.
Bối cảnh giả định hợp lý: Hình dung bạn là PO của Tiki, đang ở giữa Sprint hai tuần với Sprint Goal "Cho phép khách thanh toán qua ví MoMo trong luồng checkout". Đến ngày thứ 5, Ngân hàng Nhà nước ra quy định mới buộc mọi ví điện tử phải bổ sung bước xác thực sinh trắc học, khiến tích hợp MoMo hiện tại không còn hợp lệ. Sprint Goal coi như vô nghĩa.
Diễn giải cách giải:
Đọc lead-in trước: "PO nên làm gì?" — đây là câu hỏi về accountability và quy trình đúng của Scrum.
Loại trừ từng phương án:
- A sai vì nó vi phạm self-management. PO không ra lệnh cho Developers phải làm gì trong Sprint; PO cũng không tự ý phá ngang công việc đang chạy. Quan trọng hơn, "ngay lập tức chuyển hướng" không phải cơ chế của Scrum — Scrum có một cơ chế chính thức cho tình huống Sprint Goal lỗi thời, đó là cancel Sprint.
- B sai vì nếu Sprint Goal đã thực sự obsolete, việc để team tiếp tục làm việc vô ích đến hết Sprint là lãng phí — trái với maximize value. Chờ đợi không phải phản ứng đúng khi giá trị đã bằng không.
- D sai ở hai điểm: (1) bạn không bao giờ kéo dài thời lượng một Sprint — timebox là bất khả xâm phạm; (2) nhồi yêu cầu mới làm phình scope giữa Sprint là anti-pattern.
- C đúng. Scrum Guide 2020 ghi rõ: "A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint." Đây gần như là một trích dẫn nguyên văn — và đáp án bám sát chính câu chữ đó.
Ví dụ 2 — Câu hỏi về thứ tự Product Backlog
> Q2. Ai chịu trách nhiệm sắp xếp thứ tự (ordering) các mục trong Product Backlog? > > A. Developers, vì họ hiểu rõ độ phức tạp kỹ thuật. > B. Scrum Master, để đảm bảo quy trình được tuân thủ. > C. Product Owner. > D. Cả Scrum Team cùng thống nhất bằng biểu quyết.
Bối cảnh giả định: Tại một startup fintech ở TP.HCM, có 30 nhân sự, vị Engineering Manager quen "chốt" thứ tự backlog trong mỗi cuộc họp vì anh ấy là người am hiểu hệ thống nhất. Nghe rất hợp lý trong đời thực — và đó chính là cái bẫy.
Diễn giải cách giải:
Lead-in hỏi accountability rõ ràng: "Ai chịu trách nhiệm ordering?".
- A là bẫy đời thực vs Scrum Guide. Developers cung cấp đầu vào (input) về độ phức tạp, dependency kỹ thuật — nhưng họ không phải người chịu trách nhiệm về thứ tự. Đây là phân biệt tinh tế: input ≠ accountability.
- B là bẫy vai trò sai. Scrum Master không sở hữu Product Backlog. Scrum Master phục vụ, huấn luyện — không sắp xếp backlog.
- D là bẫy "nghe dân chủ nên có vẻ đúng". Scrum không vận hành bằng biểu quyết để quyết thứ tự backlog. Accountability về backlog là một người duy nhất chịu trách nhiệm — chính là PO. Điều này giữ cho việc maximize value có một điểm chịu trách nhiệm rõ ràng.
- C đúng. Scrum Guide: PO chịu trách nhiệm "Ordering Product Backlog items". PO có thể ủy quyền việc thực thi (delegate) cho người khác, nhưng accountability vẫn thuộc về PO.
Ví dụ 3 — Câu hỏi True/False về Definition of Done
> Q3. Đúng hay Sai: Nếu một Product Backlog Item không đạt Definition of Done vào cuối Sprint, nó vẫn có thể được trình bày cho stakeholders trong Sprint Review và tính là một phần của Increment.
Bối cảnh giả định: Tại VNG, đội game đang làm tính năng "đăng nhập bằng Apple ID". Đến cuối Sprint, code đã chạy được trên máy dev nhưng chưa qua security review — một mục bắt buộc trong DoD của team. Trưởng nhóm muốn vẫn demo "cho stakeholder thấy tiến độ".
Diễn giải cách giải:
Đây là câu True/False, nên đừng vội. Tách câu thành hai mệnh đề: (1) item chưa đạt DoD; (2) vậy nó có được tính là phần của Increment không?
Scrum Guide rất rõ: "If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration."
Vậy nên đáp án là SAI (False). Một item chưa đạt DoD thì không phải là một phần của Increment, và không được present tại Sprint Review như một việc đã hoàn thành. Nó quay về Product Backlog.
Lưu ý sắc thái: Sprint Review là một working session — team vẫn có thể thảo luận về công việc đang dang dở, về điều đã học được. Nhưng "present như một phần của Increment đã Done" thì không. Câu hỏi cố tình ghép cụm "tính là một phần của Increment" để biến nó thành SAI dứt khoát.
Bài học rút ra: DoD là ranh giới của minh bạch (transparency). Một item không Done mà bị đem khoe như đã xong sẽ phá hủy empiricism — vì stakeholders sẽ inspect dựa trên dữ liệu sai. Khi gặp câu hỏi liên quan DoD, hãy luôn kiểm tra xem nó có đụng tới nguyên tắc "chưa Done thì không thuộc Increment" hay không.
Hướng dẫn từng bước
Đây là quy trình 6 bước bạn nên áp dụng cho MỌI câu hỏi PSPO I:
Bước 1 — Đọc lead-in trước. Xác định câu hỏi thực sự hỏi gì: accountability? quy trình? định nghĩa? đúng/sai? Việc này định hướng toàn bộ phần đọc còn lại.
Bước 2 — Đọc stem, gạch chân từ khóa, bỏ qua nhiễu. Tìm các từ tín hiệu: "obsolete", "Sprint Goal", "Done", "only", "responsible for". Bỏ qua những chi tiết về tên công ty, con số doanh thu nếu chúng không thay đổi bản chất câu hỏi.
Bước 3 — Tự trả lời TRƯỚC khi nhìn options. Che các phương án lại, tự nghĩ ra câu trả lời đúng theo Scrum Guide. Cách này giúp bạn miễn nhiễm với các phương án gài bẫy.
Bước 4 — So khớp và loại trừ. Đọc từng option, gạch bỏ ngay những phương án dính bẫy: tuyệt đối hóa sai chỗ, gán nhầm vai trò, mô tả thực hành waterfall.
Bước 5 — Áp ba câu hỏi vàng (empiricism? self-management? value?) cho hai phương án còn lại nếu vẫn phân vân.
Bước 6 — Với câu nhiều đáp án, đếm số lượng được yêu cầu. Câu "Select two" mà bạn chọn một sẽ bị tính sai. Đọc kỹ lead-in xem cần chọn mấy.
Một mẹo quản lý thời gian: 80 câu / 60 phút = 45 giây/câu. Câu nào quá 90 giây, đánh dấu (flag), chọn tạm phương án khả dĩ nhất rồi đi tiếp — quay lại sau. Đừng để một câu khó nuốt mất thời gian của mười câu dễ.
Lỗi thường gặp & mẹo
- Đọc đáp án bằng kinh nghiệm công ty mình. Đây là lỗi chí mạng. Ở công ty bạn, Scrum Master có thể đang viết backlog, PO có thể đang chỉ đạo task — nhưng PSPO I chấm theo Scrum Guide, không theo công ty bạn. Hãy "reset" về Scrum Guide thuần khiết.
- Bị nhiễu bởi stem dài. Nhiều câu cố tình viết một đoạn dài về bối cảnh thị trường để bạn rối. Hãy nhớ: phần lớn thông tin đó là nhiễu. Quay về lead-in và từ khóa.
- Quên rằng "ủy quyền không xóa accountability". PO có thể nhờ business analyst viết User Story, nhưng PO vẫn chịu trách nhiệm về Product Backlog. Câu hỏi thích khai thác sự lẫn lộn giữa "ai làm" và "ai chịu trách nhiệm".
- Chọn phương án dài nhất / chi tiết nhất vì nghĩ nó "đúng hơn". Độ dài không tương quan với độ đúng. Đôi khi đáp án ngắn gọn "Product Owner." mới là chuẩn.
- Sa vào bẫy timebox. Bất kỳ phương án nào nói "kéo dài Sprint", "rút ngắn Sprint giữa chừng để kịp", "gộp hai Sprint" đều gần như chắc chắn sai. Timebox là bất biến.
- Mẹo cuối: Hãy làm Scrum Open Assessment (miễn phí trên Scrum.org) ít nhất 5–7 lần đạt 100% liên tiếp trước khi thi thật. Nhiều câu trong đề thật có cấu trúc tư duy tương tự. Đây là bài tập sát thực tế nhất bạn có.
Bài tập thực hành
Bài 1. Tự giải câu hỏi sau bằng quy trình 6 bước, viết ra lý do loại trừ từng phương án:
> Developers phát hiện một số mục trong Sprint Backlog không thể hoàn thành trong Sprint này. Họ nên làm gì? > A. PO quyết định bỏ bớt mục nào. B. Developers trao đổi với PO để điều chỉnh scope của Sprint, giữ nguyên Sprint Goal. C. Hủy Sprint. D. Kéo dài Sprint.
(Gợi ý: đáp án đúng là B — Developers và PO renegotiate scope, miễn không phá Sprint Goal. Hãy tự viết lý do A, C, D sai.)
Bài 2. Viết lại bằng lời của bạn câu trích Scrum Guide về điều kiện cancel Sprint, rồi tự đặt thêm một phương án "bẫy tuyệt đối hóa" cho chính câu Q1 ở trên. Mục tiêu là bạn tự tạo được bẫy — khi đó bạn sẽ nhận ra bẫy của người khác.
Bài 3. Làm Scrum Open Assessment một lượt, ghi lại MỌI câu bạn sai hoặc đoán. Với mỗi câu đó, tra đúng đoạn nào trong Scrum Guide giải thích. Lập một "sổ tay sai lầm" — đây là tài liệu ôn thi giá trị nhất của riêng bạn.
Tóm tắt
Giải câu hỏi PSPO I là một kỹ năng riêng, tách biệt với việc thuộc lý thuyết. Ba điều cốt lõi cần mang theo:
- Quy trình giải đề 6 bước: đọc lead-in trước → gạch từ khóa, bỏ nhiễu → tự trả lời trước khi xem options → loại trừ phương án bẫy → áp ba câu hỏi vàng (empiricism, self-management, value) → đếm đúng số đáp án cần chọn.
- Nhận diện bốn loại bẫy: đời-thực-vs-Scrum-Guide, tuyệt-đối-hóa, vai-trò-sai, và nghe-hợp-lý-nhưng-không-phải-Scrum.
- Những phản xạ cứng cần thuộc nằm lòng: "Sprint Goal obsolete → cân nhắc cancel Sprint, chỉ PO có quyền"; "ordering backlog → PO chịu trách nhiệm"; "chưa Done → không thuộc Increment, không present ở Review"; "không bao giờ kéo dài timebox"; "ủy quyền không xóa accountability".