Mở đầu — vì sao bài này quan trọng
Nếu bạn đã đi qua bốn bộ câu hỏi luyện tập trước (Scrum Theory, Accountabilities, Events, Artifacts), bạn hẳn đã thuộc khá nhiều định nghĩa "by the book". Nhưng có một sự thật khó chịu mà rất nhiều người trượt PSM I mới nhận ra: bài thi không chỉ kiểm tra bạn có thuộc Scrum Guide hay không, mà kiểm tra bạn có áp dụng được nó vào tình huống thực tế hay không.
Đây chính là lý do bộ câu hỏi thứ năm này — Scenarios — là bộ khó nhất và quan trọng nhất. Khoảng 40–50% câu hỏi trong kỳ thi PSM I thật được viết dưới dạng tình huống: "Một stakeholder làm X, Scrum Master nên làm gì?", "Team gặp vấn đề Y giữa Sprint, ai chịu trách nhiệm?", "Product Owner muốn Z, điều này có phù hợp với Scrum không?". Những câu này không có dòng nào trong Scrum Guide trả lời thẳng. Bạn phải suy luận từ nguyên tắc.
Trong bài này, tôi sẽ cùng bạn đi qua một bộ câu hỏi tình huống được thiết kế mô phỏng sát đề thi thật, kèm phân tích từng phương án — vì sao đúng, vì sao sai. Quan trọng hơn cả đáp án, tôi muốn bạn nắm được cách tư duy để tự giải bất kỳ câu scenario nào, kể cả những câu bạn chưa từng gặp.
Khái niệm cốt lõi
Câu hỏi scenario khác gì câu hỏi định nghĩa?
Câu hỏi định nghĩa hỏi: "Sprint Retrospective dài tối đa bao lâu cho Sprint một tháng?" — bạn nhớ là 3 giờ, chọn xong. Câu hỏi scenario hỏi: "Trong Sprint Retrospective, một Developer im lặng suốt buổi, Scrum Master nên làm gì?" — không có con số nào cứu bạn ở đây.
Để giải scenario, bạn cần ba lớp tư duy:
Lớp 1 — Ai chịu trách nhiệm cho việc này (accountability)? Phần lớn câu sai vì người thi để Scrum Master "ôm" hết mọi việc. Hãy luôn hỏi: việc này thuộc về Product Owner, Developers, hay Scrum Master? Ví dụ: ưu tiên Product Backlog là của PO, không phải SM. Quyết định bao nhiêu việc đưa vào Sprint là của Developers.
Lớp 2 — Self-management có bị vi phạm không? Scrum Team tự quản lý. Một Scrum Master tốt không ra lệnh, không gán việc, không thay team ra quyết định. Nếu một phương án có dạng "Scrum Master quyết định thay cho team" thì 90% là sai.
Lớp 3 — Empiricism có được tôn trọng không? Mọi vấn đề nên được đưa ra ánh sáng (Transparency), được kiểm tra (Inspection) và điều chỉnh (Adaptation) tại đúng event của nó. Phương án nào "che giấu vấn đề", "bỏ qua minh bạch", hoặc "giải quyết bên ngoài event phù hợp" thường sai.
Bốn cái bẫy kinh điển trong câu scenario
Hiểu các bẫy này giúp bạn loại nhanh phương án sai:
- Bẫy "anh hùng Scrum Master": Phương án để SM tự đứng ra giải quyết, ra quyết định, hoặc "bảo vệ" team bằng cách chặn người khác. Scrum Master là người phục vụ (servant leader), không phải sếp.
- Bẫy "command-and-control": Phương án có "assign task", "tell the Developer to...", "decide who does what". Vi phạm self-management.
- Bẫy "bỏ qua đúng người": Phương án xử lý một việc thuộc accountability của người khác. Ví dụ stakeholder muốn thêm tính năng — đó là việc của Product Owner, không phải Developer hay SM tự ý.
- Bẫy "phá vỡ event/timebox": Phương án kéo dài Sprint, hủy Daily Scrum để "tiết kiệm thời gian", hoặc thêm một event không có trong Scrum.
Cách đọc một câu scenario hiệu quả
Đọc câu hỏi hai lần. Lần một nắm tình huống. Lần hai gạch chân từ khóa: ai đang hành động, ai bị ảnh hưởng, điều gì sai so với Scrum. Sau đó, trước khi nhìn đáp án, tự nghĩ ra câu trả lời "đúng theo Scrum" của riêng bạn. Rồi mới so với bốn phương án. Cách này tránh việc bạn bị các phương án "nghe hợp lý nhưng sai" dẫn dắt.
Tình huống thực tế
Tôi sẽ dùng ba bối cảnh công ty thực tế ở Việt Nam và Đông Nam Á để bạn thấy scenario không phải lý thuyết suông.
Ví dụ 1 — Stakeholder "đi cửa sau" tại một fintech ở TP.HCM
Bối cảnh: Tại MoMo-style fintech (gọi là công ty PayViet cho dễ hình dung), team Scrum gồm 6 Developers, 1 PO tên Linh, 1 SM tên Hùng. Trong giờ nghỉ trưa, ông Trưởng phòng Marketing — một stakeholder quyền lực — đi thẳng tới bàn của Developer tên Quang và nói: "Em ơi, làm gấp cho anh cái banner khuyến mãi Tết vào app trong Sprint này nhé, sếp tổng yêu cầu rồi." Quang lúng túng vì việc này không có trong Sprint Backlog.
Câu hỏi mô phỏng đề thi: Stakeholder bỏ qua Product Owner, yêu cầu trực tiếp Developer thêm một tính năng. Cách phản ứng tốt nhất là gì?
- A. Developer nhận làm vì đây là yêu cầu từ sếp tổng.
- B. Scrum Master ra mặt chặn stakeholder, cấm ông ấy tiếp xúc với team.
- C. Developer (và/hoặc Scrum Master) hướng stakeholder đến làm việc với Product Owner, vì PO là người chịu trách nhiệm về Product Backlog và thứ tự ưu tiên công việc.
- D. Đưa luôn yêu cầu vào Sprint hiện tại, đẩy một việc khác ra để bù.
Trong Scrum, Product Owner là một và duy nhất chịu trách nhiệm về giá trị sản phẩm và Product Backlog. Mọi thay đổi về cái gì cần làm, ưu tiên ra sao, đều phải đi qua PO. Việc dẫn stakeholder về với Linh không phải là "đá quả bóng", mà là tôn trọng đúng cấu trúc trách nhiệm của Scrum.
- A sai vì rơi vào bẫy "command từ trên xuống" — Developer làm việc theo Sprint Backlog mà họ đã cùng cam kết, không theo lệnh ngẫu hứng.
- B sai vì rơi vào bẫy "anh hùng SM" — Hùng không phải vệ sĩ chặn cửa. Scrum khuyến khích minh bạch và cộng tác, không phải xây tường. SM có thể coach stakeholder về cách làm việc đúng, nhưng không "cấm".
- D sai vì phá vỡ Sprint Backlog — chỉ Developers mới quyết định nội dung Sprint Backlog, và bất kỳ thay đổi nào cũng phải thương lượng với PO trên cơ sở Sprint Goal, không phải đổi đại.
Ví dụ 2 — Developer im lặng trong Retrospective tại một startup Singapore
Bối cảnh: Tại một startup SaaS ở Singapore (gọi là DataFlow), team có một Developer mới người Việt tên Mai, kỹ thuật giỏi nhưng tiếng Anh chưa tự tin. Suốt ba buổi Sprint Retrospective liền, Mai gần như không phát biểu gì. Scrum Master tên Daniel nhận thấy team đang bỏ lỡ góc nhìn của Mai về các vấn đề kỹ thuật.
Câu hỏi mô phỏng: Một thành viên liên tục im lặng trong Retrospective. Scrum Master nên làm gì?
- A. Yêu cầu thành viên đó phải phát biểu ít nhất ba ý trong mỗi buổi.
- B. Báo cáo với quản lý cấp trên rằng thành viên này không đóng góp.
- C. Cải thiện kỹ thuật facilitation: tạo không gian an toàn, dùng các kỹ thuật như viết ý kiến ra giấy/sticky note trước rồi mới chia sẻ, hoặc chia nhóm nhỏ, để mọi tiếng nói đều được lắng nghe.
- D. Bỏ qua, vì im lặng là lựa chọn cá nhân, không phải việc của Scrum Master.
Scrum Master là người chịu trách nhiệm cho hiệu quả của Scrum Team và cho việc các Scrum event diễn ra tích cực, hữu ích. Facilitation — tạo điều kiện để cuộc họp đạt mục tiêu — là một trong những kỹ năng cốt lõi của SM. Vấn đề ở đây không phải Mai "lười", mà là môi trường chưa đủ an toàn/phù hợp để cô ấy đóng góp.
- A sai vì ép buộc, vi phạm tinh thần tự nguyện và an toàn tâm lý. Ép phát biểu không tạo ra openness thật.
- B sai vì rơi vào bẫy "báo cáo cấp trên" — SM không phải quản lý nhân sự đánh giá hiệu suất cá nhân; làm vậy phá vỡ niềm tin.
- D sai vì SM có trách nhiệm với hiệu quả của Retrospective. Bỏ mặc là từ bỏ accountability.
Ví dụ 3 — Sprint Goal lâm nguy giữa chừng tại một công ty e-commerce Hà Nội
Bối cảnh: Team tại một sàn TMĐT ở Hà Nội (gọi là ChợViet) đang ở ngày thứ 7 của Sprint hai tuần. Trong Daily Scrum, các Developers nhận ra một thư viện thanh toán bên thứ ba bị thay đổi API đột ngột, khiến khối lượng công việc còn lại lớn hơn dự kiến nhiều. Sprint Goal — "ra mắt luồng thanh toán qua ví điện tử" — có nguy cơ không đạt được.
Câu hỏi mô phỏng: Giữa Sprint, Developers phát hiện không thể hoàn thành toàn bộ công việc đã dự báo. Họ nên làm gì?
- A. Lập tức báo PO hủy Sprint.
- B. Tự âm thầm bỏ bớt một số tính năng để kịp deadline, không nói với ai.
- C. Thương lượng lại phạm vi Sprint Backlog với Product Owner, giữ Sprint Goal làm kim chỉ nam; nếu cần, điều chỉnh các hạng mục công việc miễn vẫn hướng tới Sprint Goal.
- D. Xin gia hạn Sprint thêm vài ngày để làm cho xong.
Scrum Guide nói rõ: phạm vi (scope) có thể được làm rõ và thương lượng lại với Product Owner khi có hiểu biết mới. Sprint Backlog không phải hợp đồng đóng băng; nó là một dự báo (forecast) có thể điều chỉnh — miễn không làm hỏng Sprint Goal. Developers chủ động đưa vấn đề ra Daily Scrum (Transparency), kiểm tra tiến độ so với Sprint Goal (Inspection), rồi cùng PO điều chỉnh (Adaptation). Đây là empiricism vận hành đúng sách.
- A sai vì hủy Sprint là biện pháp cực đoan, chỉ Product Owner mới có quyền hủy, và chỉ khi Sprint Goal trở nên lỗi thời. Ở đây Goal vẫn còn giá trị, chỉ là khó hơn.
- B sai vì vi phạm Transparency — âm thầm bỏ việc che giấu thực trạng khỏi PO và stakeholders.
- D sai vì Sprint có timebox cố định, không bao giờ được kéo dài. Đây là một trong những quy tắc tuyệt đối của Scrum.
Hướng dẫn từng bước
Đây là quy trình bốn bước để giải bất kỳ câu scenario nào trong phòng thi:
Bước 1 — Xác định "ai" và "việc gì". Đọc và gạch chân: nhân vật đang hành động là ai (PO/SM/Developer/Stakeholder)? Việc đang xảy ra thuộc accountability của ai? Ví dụ: thấy "ưu tiên backlog" → nghĩ ngay PO; thấy "bao nhiêu việc vào Sprint" → Developers; thấy "event không hiệu quả" → SM facilitation.
Bước 2 — Loại phương án vi phạm nguyên tắc. Quét bốn phương án, gạch bỏ ngay những cái:
- để SM ra lệnh / quyết định thay team (vi phạm self-management);
- kéo dài hoặc rút ngắn Sprint một cách tùy tiện;
- che giấu thông tin (vi phạm Transparency);
- xử lý việc thuộc người khác (sai accountability);
- thêm vai trò/event/quy tắc không có trong Scrum.
Bước 3 — Chọn phương án "trao quyền và minh bạch". Trong các phương án còn lại, chọn cái thúc đẩy Scrum Team tự giải quyết, đưa vấn đề ra ánh sáng, và xử lý tại đúng event. Đáp án đúng PSM I gần như luôn mang tinh thần: trao quyền cho team, tôn trọng accountability, minh bạch hóa vấn đề.
Bước 4 — Kiểm tra lại bằng câu hỏi "by the book". Tự hỏi: "Nếu Scrum Guide có mặt ở đây, nó có gật đầu với phương án này không?" Tránh các phương án dựa trên "thực tế ở công ty tôi người ta làm thế" — đề thi chấm theo Scrum Guide, không theo kinh nghiệm cá nhân.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến Scrum Master thành sếp. Nhiều người Việt quen môi trường có cấp bậc rõ ràng nên vô thức chọn phương án "SM quyết định", "SM giao việc". Hãy nhớ: SM lãnh đạo bằng cách phục vụ, không bằng quyền lực. Mỗi khi thấy phương án để SM ra lệnh, hãy cảnh giác.
Lỗi 2 — Để stakeholder hoặc manager "lái" team. Trong scenario có sếp lớn, deadline gấp, áp lực doanh số — bản năng là "chiều theo". Nhưng Scrum không thay đổi vì chức danh người yêu cầu. Mọi yêu cầu công việc vẫn phải qua Product Owner và Product Backlog.
Lỗi 3 — Nhầm "thương lượng scope" với "kéo dài Sprint". Khi công việc trễ, đáp án đúng là điều chỉnh phạm vi với PO, không phải gia hạn Sprint. Sprint là chiếc hộp thời gian bất biến.
Lỗi 4 — Chọn phương án "tốt bụng nhưng sai vai". Ví dụ "SM giúp Developer viết code cho kịp" nghe có vẻ tận tâm, nhưng SM không phải Developer dự phòng; làm vậy che giấu vấn đề năng lực thật của team.
Mẹo vàng: Khi phân vân giữa hai phương án còn lại, chọn cái giúp team tự giải quyết và minh bạch hóa vấn đề thay vì cái giải quyết hộ. Scrum tin vào sự tự tổ chức — và đề thi cũng vậy.
Mẹo về ngôn ngữ: Cảnh giác với các từ tuyệt đối như "always", "must", "never" trong phương án. Đôi khi chúng đúng (Sprint timebox "never" kéo dài), nhưng thường là dấu hiệu của bẫy. Đọc kỹ.
Bài tập thực hành
Hãy tự giải bốn câu sau trước khi xem gợi ý. Áp dụng quy trình bốn bước ở trên.
Câu 1: Product Owner đi công tác hai tuần và muốn ủy quyền việc sắp xếp ưu tiên Product Backlog cho Scrum Master trong thời gian vắng mặt. Điều này phù hợp với Scrum không? (Gợi ý: PO chịu trách nhiệm cuối cùng về Product Backlog. PO có thể nhờ người khác làm hộ một phần, nhưng accountability vẫn thuộc về PO. SM nhận quyền ưu tiên thay PO thì có gây xung đột vai trò không?)
Câu 2: Trong Sprint Review, một stakeholder lớn tiếng chê Increment "vô dụng" và yêu cầu đổi hướng sản phẩm hoàn toàn. Scrum Master nên làm gì? (Gợi ý: Sprint Review là buổi cộng tác để inspect Increment và điều chỉnh Product Backlog. Phản hồi của stakeholder là đầu vào quý giá. Ai sẽ tiếp nhận và quyết định điều chỉnh Product Backlog?)
Câu 3: Một Developer hoàn thành phần việc của mình sớm, các đồng đội khác đang quá tải. Developer này nên làm gì? (Gợi ý: Developers cùng chịu trách nhiệm cho Sprint Goal. Họ tự quản lý cách phân bổ công việc. Cross-functional và self-managing nghĩa là gì ở đây?)
Câu 4: Tổ chức yêu cầu mọi team phải nộp báo cáo tiến độ chi tiết hàng tuần cho PMO, ngoài các Scrum event. Scrum Master nên phản ứng thế nào? (Gợi ý: SM phục vụ cả tổ chức, giúp họ hiểu và áp dụng Scrum. Transparency trong Scrum đến từ artifacts và events. Liệu có cách giúp PMO lấy thông tin cần thiết từ chính những gì Scrum đã tạo ra không?)
Gợi ý đáp án để bạn tự đối chiếu:
- Câu 1: PO có thể nhờ hỗ trợ, nhưng vẫn là người chịu trách nhiệm; tốt nhất PO vẫn giữ accountability và truyền đạt rõ định hướng. Đáp án "by the book" nhấn mạnh: dù ai làm hộ, PO vẫn là người chịu trách nhiệm cuối cùng — và việc ưu tiên nên phục vụ mục tiêu sản phẩm, không phải giao đứt cho SM.
- Câu 2: SM facilitate buổi review; Product Owner lắng nghe và quyết định cách phản ánh phản hồi vào Product Backlog. Không ai phải "đổi hướng ngay tại chỗ".
- Câu 3: Developer chủ động hỗ trợ đồng đội để cả team cùng đạt Sprint Goal — đó là tinh thần self-managing và cùng chịu trách nhiệm.
- Câu 4: SM coach tổ chức rằng Transparency đã sẵn có qua Increment, Product Backlog và các event; giúp PMO lấy thông tin từ đó thay vì tạo gánh nặng báo cáo song song.
Tóm tắt
Câu hỏi scenario là phần phân loại thí sinh trong PSM I, vì chúng đòi hỏi bạn áp dụng nguyên tắc chứ không chỉ nhớ định nghĩa. Ba trụ tư duy để giải mọi scenario: (1) xác định đúng accountability — ai chịu trách nhiệm cho việc này; (2) bảo vệ self-management — không để SM hay manager ra lệnh thay team; (3) tôn trọng empiricism — minh bạch hóa vấn đề và xử lý tại đúng event.
Quy trình bốn bước — xác định ai/việc gì, loại phương án vi phạm, chọn phương án trao quyền và minh bạch, kiểm tra "by the book" — sẽ giúp bạn giải nhanh và chính xác kể cả những câu chưa từng gặp. Hãy nhớ các phản xạ then chốt: yêu cầu công việc luôn qua Product Owner; Sprint timebox không bao giờ kéo dài; chỉ PO mới được hủy Sprint và chỉ khi Sprint Goal hết giá trị; Scrum Master phục vụ chứ không ra lệnh.
Khi bạn đã quen "ngửi" được bẫy anh-hùng-SM, bẫy command-and-control, và bẫy phá vỡ event, phần lớn câu scenario sẽ trở nên dễ thở. Ở các bài tiếp theo, chúng ta sẽ đào sâu thêm vào những vùng dễ nhầm lẫn cụ thể và chiến lược làm bài tổng thể. Còn bây giờ, hãy quay lại bốn câu bài tập và tự giải đến khi bạn diễn đạt trôi chảy lý do cho từng lựa chọn.