Mở đầu — vì sao bài này quan trọng
Nếu bạn đã đi qua 45 bài trước của khóa học này, bạn đã tích lũy gần như đầy đủ kiến thức và tư duy để hành nghề Scrum Master ở cấp độ nâng cao. Nhưng kiến thức và khả năng thi đậu PSM II là hai chuyện khác nhau. Rất nhiều người giàu kinh nghiệm thực chiến vẫn trượt PSM II, không phải vì họ thiếu hiểu biết, mà vì họ chưa hiểu cách bài thi hỏi.
PSM II là một bài thi đặc biệt: nó hiếm khi hỏi bạn "Định nghĩa của Sprint là gì?". Thay vào đó, nó ném bạn vào một tình huống — thường là một bối cảnh tổ chức rối ren, một cái bẫy cảm xúc, hoặc một xung đột giữa các vai trò — rồi hỏi: "Là một Scrum Master chuyên nghiệp, bạn nên LÀM GÌ?". Câu trả lời "đúng theo sách giáo khoa" thường không phải là câu trả lời đúng theo bài thi. Đây chính là lý do bài học này tồn tại.
Bài 46 không dạy lại lý thuyết. Bài này dạy bạn cách đọc một câu hỏi scenario, nhận diện cái bẫy mà Scrum.org đang giăng ra, và chọn được câu trả lời thể hiện đúng "tư duy Scrum Master trưởng thành". Đây là kỹ năng làm bài — và nó đáng giá khoảng 250 USD, bởi vì bạn chỉ muốn đóng khoản phí đó một lần duy nhất.
Khái niệm cốt lõi
Cấu trúc bài thi PSM II — biết để không bất ngờ
Trước khi nói về scenario, hãy nắm chắc khung của bài thi để bạn phân bổ thời gian hợp lý:
- Số câu hỏi: khoảng 30 câu.
- Thời gian: 90 phút — tức trung bình 3 phút mỗi câu, khá rộng rãi.
- Điểm đậu: 85% (tức bạn được sai tối đa khoảng 4–5 câu trong 30 câu).
- Lệ phí: 250 USD, thi online, một mình trước máy tính.
- Open book: bạn được phép mở Scrum Guide trong lúc thi. Nhưng đừng vui mừng quá sớm — phần lớn câu hỏi là scenario, không tra cứu được. Mở Scrum Guide chỉ giúp bạn với vài câu định nghĩa và làm bạn mất thời gian nếu lạm dụng.
- Định dạng: đa số là trắc nghiệm một đáp án hoặc nhiều đáp án (multiple choice / multiple answer), dựa trên tình huống.
Năm "họ" tình huống thường gặp trong PSM II
Qua hàng nghìn câu hỏi của Scrum.org, các scenario thường rơi vào năm nhóm lớn. Nhận diện được câu hỏi thuộc nhóm nào, bạn đã đi được nửa đường tới đáp án đúng.
Nhóm 1 — Lằn ranh trách nhiệm (accountability boundaries). Tình huống mô tả ai đó (PO, manager, một developer) đang làm sai vai, và hỏi Scrum Master nên phản ứng thế nào. Cái bẫy ở đây thường là đáp án "Scrum Master tự mình làm thay" hoặc "Scrum Master ra lệnh". Tư duy đúng: Scrum Master không sở hữu kết quả công việc, không quản lý con người; vai trò của bạn là giúp người khác hiểu và tự đảm nhận trách nhiệm của họ.
Nhóm 2 — Servant leadership vs command-and-control. Một sếp yêu cầu bạn ép team commit một deadline, hoặc một stakeholder muốn bạn báo cáo "ai làm chậm". Cái bẫy: các đáp án nghe có vẻ "hiệu quả" và "quyết đoán" nhưng thực chất là mệnh lệnh hành chính. Tư duy đúng: tạo sự minh bạch, để dữ liệu nói chuyện, trao quyền cho team tự quyết.
Nhóm 3 — Self-management (đội tự quản). Tình huống: team đang vướng mắc, và câu hỏi cám dỗ bạn "đưa giải pháp" hoặc "phân công công việc". Tư duy đúng: Scrum Master tạo điều kiện để team tự tìm ra giải pháp, chứ không giải hộ. Một đội tự quản được xây dựng, không phải được ban phát mệnh lệnh.
Nhóm 4 — Tính toàn vẹn của Scrum (Scrum integrity). Tình huống: ai đó đề xuất bỏ một sự kiện ("Sprint này gấp quá, bỏ Retrospective nhé"), hoặc cắt một artifact. Tư duy đúng: Scrum Master bảo vệ tính toàn vẹn của khung Scrum, nhưng bảo vệ bằng cách giúp mọi người hiểu giá trị, không phải bằng cách trích dẫn luật lệ cứng nhắc.
Nhóm 5 — Scaling và đa đội (multi-team). Tình huống liên quan nhiều team, một Product Backlog chung, integration. Tư duy đúng: dù scale lên, các nguyên tắc nền tảng không đổi — vẫn một PO chịu trách nhiệm cho Product Backlog, vẫn một Product Goal.
Ba nguyên tắc lọc đáp án
Khi đứng giữa các phương án na ná nhau, hãy lọc bằng ba câu hỏi:
- Đáp án này có khiến Scrum Master làm thay việc của người khác không? Nếu có — gần như chắc chắn sai.
- Đáp án này có tạo ra minh bạch và trao quyền, hay nó che giấu vấn đề / áp đặt mệnh lệnh? Chọn cái tạo minh bạch.
- Đáp án này có giải quyết gốc rễ hay chỉ chữa triệu chứng? Scrum Master trưởng thành luôn hướng tới gốc rễ (root cause), nhưng theo cách bền vững chứ không "anh hùng cá nhân".
Tình huống thực tế
Tình huống 1 — Cái bẫy "Scrum Master làm anh hùng" (FPT Software)
Bối cảnh: Bạn là Scrum Master cho một team 8 người tại một công ty phần mềm lớn kiểu FPT Software ở Hà Nội. Giữa Sprint, một developer chủ chốt nghỉ ốm đột xuất. Sprint Backlog có 13 hạng mục, và nhìn vào tiến độ, gần như chắc chắn team sẽ không hoàn thành Sprint Goal. Product Owner đang đi công tác nước ngoài, không liên lạc được trong 2 ngày.
Câu hỏi kiểu PSM II sẽ là: "Là Scrum Master, bạn nên làm gì?" với các đáp án như:
- (A) Tự mình code phần việc của developer nghỉ ốm để kịp tiến độ.
- (B) Phân công lại công việc cho các developer còn lại và yêu cầu họ làm overtime.
- (C) Tạo điều kiện để các Developers tự thảo luận, đánh giá lại Sprint Backlog và quyết định cách điều chỉnh phạm vi nhằm hướng tới Sprint Goal.
- (D) Liên hệ sếp của PO để xin gia hạn Sprint.
Bài học rút ra: Bất cứ khi nào một đáp án biến Scrum Master thành người "trực tiếp gánh việc" hay "trực tiếp ra lệnh", hãy nghi ngờ nó ngay.
Tình huống 2 — Sếp muốn bạn làm "cảnh sát tiến độ" (một fintech tại TP.HCM)
Bối cảnh: Bạn làm Scrum Master tại một công ty fintech khoảng 200 người ở Quận 1, TP.HCM. Một Engineering Manager — người trước đây quản lý team theo kiểu truyền thống — kéo bạn ra nói riêng: "Daily Scrum mỗi sáng, em note lại xem ai báo cáo trễ deadline, cuối tuần gửi anh report để anh đánh giá hiệu suất từng người. Velocity của team đang thấp, anh cần biết ai là người kéo team xuống."
Câu hỏi kiểu PSM II sẽ kiểm tra xem bạn xử lý áp lực từ cấp trên như thế nào. Các đáp án cám dỗ:
- (A) Đồng ý, vì manager là cấp trên và việc minh bạch hiệu suất là tốt.
- (B) Từ chối thẳng thừng: "Đó không phải việc của Scrum Master" rồi bỏ đi.
- (C) Giải thích cho manager hiểu mục đích thật của Daily Scrum, rủi ro của việc dùng nó để đánh giá cá nhân, và đề xuất các thước đo cấp team (như metric về dòng chảy công việc, EBM) hữu ích hơn cho mục tiêu thật sự của anh ấy.
Bài học rút ra: Trong PSM II, khi hai đáp án đều "đúng về nguyên tắc", hãy chọn đáp án nào vừa giữ nguyên tắc vừa thể hiện kỹ năng tác động và coaching. Scrum Master không chỉ biết điều đúng, mà còn biết cách giúp người khác nhìn ra điều đúng.
Tình huống 3 — "Bỏ Retrospective cho gọn" tại một startup
Bối cảnh: Bạn là Scrum Master tại một startup edtech khoảng 25 người ở Đà Nẵng. Đội đang chạy Sprint 2 tuần. Sau vài Sprint, một developer kỳ cựu phát biểu trong nhóm chat: "Retrospective tuần nào cũng nói mấy chuyện giống nhau, chẳng giải quyết được gì. Sprint tới mình bỏ Retro đi, dành 1 tiếng đó để code cho kịp release demo nhà đầu tư." Vài người khác gật gù đồng ý.
Câu hỏi kiểu PSM II:
- (A) Đồng ý bỏ Retrospective Sprint này, vì team tự quản và họ đã quyết.
- (B) Khẳng định Scrum Guide bắt buộc phải có Retrospective nên không được bỏ, chấm hết.
- (C) Tạo điều kiện để team khám phá vì sao Retrospective đang trở nên vô ích, và cùng thiết kế lại nó để thật sự tạo ra cải tiến.
Bài học rút ra: Khi một câu hỏi đặt "tuân thủ Scrum" đối đầu với "team muốn bỏ một sự kiện", đáp án đúng gần như luôn là giải quyết nguyên nhân khiến sự kiện mất giá trị, chứ không phải bỏ nó, cũng không phải áp đặt nó.
Hướng dẫn từng bước
Đây là quy trình bạn nên áp dụng cho từng câu hỏi scenario trong phòng thi:
- Đọc câu hỏi cuối cùng trước. Trong các scenario dài, câu hỏi thật sự nằm ở cuối ("Nên làm gì?", "Điều gì đúng nhất?", "Chọn 2 đáp án..."). Đọc nó trước rồi mới đọc bối cảnh, bạn sẽ biết mình đang tìm gì.
- Xác định nhóm tình huống. Hỏi: đây là vấn đề về lằn ranh trách nhiệm, servant leadership, self-management, Scrum integrity, hay scaling? Việc gán nhãn này thu hẹp đáng kể không gian đáp án đúng.
- Loại bỏ các bẫy hiển nhiên trước. Gạch ngay các đáp án có dạng: Scrum Master tự làm thay; Scrum Master ra lệnh / phân công; Scrum Master báo cáo hiệu suất cá nhân cho sếp; bỏ một sự kiện hay artifact của Scrum; PO áp đặt kỹ thuật; manager can thiệp vào cách team làm việc. Thường loại được 2 trong 4 đáp án ngay lập tức.
- Áp ba bộ lọc. Với các đáp án còn lại, chạy qua ba câu hỏi đã nêu ở phần Khái niệm cốt lõi: làm thay? tạo minh bạch hay áp đặt? gốc rễ hay triệu chứng?
- Chú ý số lượng đáp án cần chọn. Nếu đề yêu cầu "chọn 2", "chọn 3" — đếm cho đúng. Đây là lỗi mất điểm oan phổ biến nhất. Một câu multiple-answer chỉ tính đúng khi bạn chọn đủ và đúng tất cả.
- Đánh dấu câu phân vân, đừng sa lầy. Với 3 phút/câu bạn có dư thời gian, nhưng đừng để một câu khó ngốn 10 phút. Đánh dấu, đi tiếp, quay lại sau.
- Chỉ mở Scrum Guide khi thực sự cần. Dành nó cho các câu hỏi về định nghĩa cứng (thời lượng tối đa của sự kiện, ai chịu trách nhiệm cho artifact nào). Đừng tra cứu cho câu scenario — câu trả lời không nằm trong sách.
Lỗi thường gặp & mẹo
Lỗi 1 — Trả lời theo "thực tế công ty mình" thay vì theo Scrum chuẩn. Nhiều người có kinh nghiệm thực chiến trượt PSM II vì họ chọn đáp án "ở công ty tôi vẫn làm thế". PSM II hỏi về Scrum đúng chuẩn theo Scrum Guide, không phải biến thể "Scrum-but" của công ty bạn. Mẹo: tạm gác kinh nghiệm cá nhân, trả lời như một Scrum lý tưởng.
Lỗi 2 — Chọn đáp án "quyết đoán" nhất. Bài thi cố tình cài những đáp án nghe rất "lãnh đạo mạnh mẽ" (ra deadline, phân công, ép commit). Trong PSM II, sự quyết đoán kiểu mệnh lệnh gần như luôn sai. Mẹo: nếu một đáp án khiến bạn thấy "ngầu" và "kiểm soát", hãy nghi ngờ nó.
Lỗi 3 — Nhầm "facilitate" với "quyết định thay". Đáp án đúng thường chứa các động từ như tạo điều kiện (facilitate), giúp team nhận ra, coaching, tạo minh bạch. Đáp án sai thường chứa quyết định, phân công, yêu cầu, báo cáo. Mẹo: học cách nhận diện ngôn ngữ servant-leadership trong các phương án.
Lỗi 4 — Bỏ qua từ khóa định lượng trong đề. "Chọn đáp án ĐÚNG NHẤT", "chọn HAI", "điều nào KHÔNG đúng". Các từ in hoa này quyết định câu trả lời. Mẹo: gạch chân chúng (về mặt tư duy) khi đọc.
Lỗi 5 — Học tủ qua dump đáp án. Nhiều bạn tải "exam dump" trên mạng. Cách này nguy hiểm: Scrum.org đảo câu hỏi liên tục, và dump thường có đáp án sai. Quan trọng hơn, nó không xây tư duy. Mẹo tốt hơn: làm Scrum Open miễn phí trên trang Scrum.org nhiều lần đến khi đạt 100% ổn định, rồi mới đăng ký thi PSM II.
Mẹo vàng: Trước khi thi, đọc lại Scrum Guide ít nhất 3 lần đến mức bạn có thể tự vẽ lại sơ đồ Scrum từ trí nhớ. Open book chỉ cứu được bạn nếu bạn đã thuộc cấu trúc và chỉ cần tra cứu chi tiết.
Bài tập thực hành
- Tự phân loại 20 câu. Vào trang Scrum.org, làm bài Scrum Open. Với mỗi câu, trước khi xem đáp án, hãy tự gán nó vào một trong năm nhóm tình huống (lằn ranh trách nhiệm / servant leadership / self-management / Scrum integrity / scaling). Ghi lại tỷ lệ bạn gán đúng nhóm.
- Viết lại scenario của chính bạn. Lấy một tình huống có thật ở công ty bạn trong 3 tháng qua (ví dụ: sếp đòi report cá nhân, team muốn bỏ một sự kiện). Viết nó thành một câu hỏi PSM II với 4 đáp án, trong đó có 1 bẫy "làm anh hùng", 1 bẫy "command-and-control", 1 đáp án "đúng luật nhưng cứng nhắc", và 1 đáp án "facilitate đúng chuẩn". Bài tập này buộc bạn tư duy như người ra đề.
- Luyện bộ lọc 3 câu hỏi. Tự ra cho mình 10 câu scenario (hoặc nhờ bạn học cùng). Với mỗi câu, viết ra cách bạn loại từng đáp án sai bằng 3 bộ lọc (làm thay? / minh bạch hay áp đặt? / gốc rễ hay triệu chứng?). Mục tiêu: biến quy trình lọc thành phản xạ.
- Mô phỏng điều kiện thi. Đặt đồng hồ 90 phút, làm 30 câu liên tục không gián đoạn, có mở Scrum Guide bên cạnh. Sau đó chấm và phân tích vì sao mỗi câu sai — sai vì thiếu kiến thức hay vì rơi vào bẫy tư duy? Đây là bài tập quan trọng nhất.
Tóm tắt
PSM II là bài thi của tư duy, không phải của trí nhớ. Với 30 câu trong 90 phút và ngưỡng đậu 85%, bạn không có chỗ cho sự mơ hồ. Phần lớn câu hỏi là scenario, và Scrum.org cố tình giăng bẫy bằng những đáp án nghe "tận tụy" hoặc "quyết đoán" nhưng thực chất vi phạm vai trò Scrum Master.
Hãy nhớ năm nhóm tình huống: lằn ranh trách nhiệm, servant leadership, self-management, Scrum integrity, và scaling. Hãy nhớ ba bộ lọc: Scrum Master có đang làm thay không? Đáp án tạo minh bạch hay áp đặt? Nó chạm tới gốc rễ hay chỉ chữa triệu chứng? Và hãy nhớ ba bài học từ các tình huống thực tế: đừng làm anh hùng (FPT), đừng biến sự kiện thành công cụ báo cáo cho sếp (fintech), và khi team muốn bỏ một sự kiện thì hãy sửa nguyên nhân chứ đừng bỏ hay áp đặt (startup).
Khi bạn đọc một câu hỏi PSM II và cảm thấy đáp án "đúng theo sách" nghe có vẻ thụ động, hãy tin vào nó. Một Scrum Master trưởng thành dẫn dắt bằng cách tạo điều kiện và trao quyền, chứ không bằng mệnh lệnh. Đó chính là điều bài thi đang kiểm tra — và cũng chính là con người nghề nghiệp mà cả khóa học này đang giúp bạn trở thành.