Mở đầu — vì sao bài này quan trọng
Nếu bạn đã đi làm Scrum vài năm, có một sự thật khó chịu mà bạn cần nghe ngay từ đầu: kinh nghiệm thực chiến của bạn có thể khiến bạn trượt PSM I. Nghe ngược đời phải không? Nhưng đó là lý do hàng nghìn người làm Scrum Master nhiều năm vẫn thi rớt bài thi tưởng chừng "cơ bản" này.
Lý do nằm ở bản chất của kỳ thi. PSM I của Scrum.org không kiểm tra "Scrum hoạt động thế nào ở công ty bạn", mà kiểm tra "Scrum được định nghĩa thế nào trong Scrum Guide 2020". Hai thứ này nghe giống nhau nhưng khác nhau một trời một vực. Ở công ty, bạn có sếp gọi là Project Manager kiêm Scrum Master, có người gán story point cho Developer, có Daily Scrum kéo dài 30 phút vì "team đông". Tất cả những "biến tấu" đó là thực tế đời sống — nhưng trong phòng thi, chúng đều là đáp án sai.
Bài học này dạy bạn một tư duy cực kỳ quan trọng để vượt qua PSM I: tư duy "by the book" — trả lời theo đúng sách. Đây không phải mẹo gian lận, mà là cách bạn tách bạch giữa "kiến thức Scrum chuẩn" và "thói quen của tổ chức nơi bạn làm". Khi nắm vững tư duy này, bạn sẽ thấy nhiều câu hỏi tưởng đánh đố thật ra rất rõ ràng — chỉ cần bạn biết "cuốn sách" muốn nghe câu trả lời nào.
Đây là bài về chiến lược trả lời, không phải bài học lại lý thuyết Scrum. Bạn đã học toàn bộ framework ở các bài trước. Giờ là lúc học cách dùng kiến thức đó đúng cách trong phòng thi.
Khái niệm cốt lõi
"By the book" nghĩa là gì?
"By the book" — theo đúng sách — nghĩa là khi gặp một câu hỏi, bạn trả lời dựa trên đúng câu chữ trong Scrum Guide 2020, chứ không dựa trên:
- Kinh nghiệm cá nhân ("ở công ty tôi thì...")
- Các framework mở rộng (SAFe, LeSS, Nexus — trừ khi bài hỏi rõ)
- Sách của tác giả khác (Mike Cohn, Jeff Sutherland's books — vốn hay hơn cả Guide ở nhiều điểm nhưng KHÔNG phải nguồn thi)
- "Common sense" của ngành phần mềm
Vì sao kinh nghiệm thực tế lại "phản chủ"?
Scrum trong thực tế gần như luôn bị "tùy biến". Đó không hẳn là điều xấu — Scrum có chủ đích để mỗi tổ chức thích nghi. Nhưng vấn đề là: những tùy biến phổ biến nhất lại chính là những thứ Scrum Guide không hề nói, hoặc nói ngược lại. Một số ví dụ kinh điển:
- Thực tế: "Scrum Master facilitate Daily Scrum và là người chủ trì." → Sách: Daily Scrum là của Developers, Scrum Master không bắt buộc tham gia, càng không chủ trì.
- Thực tế: "Product Owner giao việc cho team trong Sprint Planning." → Sách: Không ai giao việc. Developers tự chọn lượng việc; Sprint Backlog do Developers sở hữu.
- Thực tế: "Sprint phải kết thúc khi hết việc." → Sách: Sprint có timebox cố định, không bao giờ kéo dài thêm.
- Thực tế: "Nếu không đạt Sprint Goal thì Sprint thất bại." → Sách: Không có khái niệm "Sprint thất bại"; mỗi Sprint đều tạo ra giá trị và bài học.
"Should" vs "Must" — và sự tuyệt đối của ngôn ngữ Scrum Guide
Một đặc điểm quan trọng: Scrum Guide rất ít dùng từ tuyệt đối kiểu "always/never" một cách lỏng lẻo. Khi nó nói một điều gì là quy định, thì đó là quy định cứng. Ví dụ:
- "The Sprint Retrospective concludes the Sprint." → Luôn luôn là sự kiện cuối cùng.
- "Sprints are limited to one calendar month." → Sprint không bao giờ dài hơn 1 tháng.
Khi nào KHÔNG áp dụng "by the book" một cách máy móc
Có một nhóm câu hỏi tình huống (scenario) hỏi "Scrum Master nên làm gì?". Ở đây, "by the book" được hiểu rộng hơn — là chọn hành động phù hợp nhất với giá trị Scrum và vai trò servant-leader, thay vì hành động kiểu command-and-control. Ta sẽ phân tích kỹ ở phần tình huống.
Tình huống thực tế
Tình huống 1 — Anh Hùng, Scrum Master 6 năm kinh nghiệm tại một fintech ở Hà Nội
Anh Hùng làm Scrum Master tại MoMoPay (giả định), một công ty fintech khoảng 200 nhân sự. Anh tự tin đăng ký thi PSM I mà gần như không ôn, nghĩ rằng "6 năm làm rồi, sách có gì lạ". Kết quả: anh được 79% — trượt sát nút (ngưỡng đậu là 85%).
Khi rà lại, anh phát hiện mình sai ở những câu sau:
- Câu hỏi "Ai chịu trách nhiệm quản lý tiến độ công việc còn lại trong Sprint?" — anh chọn "Scrum Master", vì ở MoMoPay anh là người cập nhật burndown chart mỗi sáng. Đáp án đúng: Developers. Trong Scrum Guide, chính Developers quản lý Sprint Backlog và tiến độ hằng ngày của họ.
- Câu hỏi "Trong Sprint Planning, ai quyết định bao nhiêu việc được đưa vào Sprint?" — anh chọn "Product Owner và Developers cùng quyết". Đáp án đúng: chỉ Developers mới chọn được lượng việc họ có thể hoàn thành; PO cung cấp thông tin và ưu tiên, nhưng không định lượng thay Developers.
Tình huống 2 — Chị Lan và cái bẫy "tối ưu hóa quy trình"
Chị Lan là một Agile Coach giỏi tại một công ty outsourcing ở TP.HCM, từng cải tiến quy trình cho nhiều team. Chị gặp câu hỏi:
> "Một team thấy Daily Scrum 15 phút là lãng phí vì công việc của họ ít thay đổi. Họ đề xuất chuyển Daily Scrum sang 2 ngày/lần. Scrum Master nên làm gì?"
Theo bản năng tối ưu hóa, chị Lan chọn: "Đồng ý, vì Scrum đề cao việc team tự quản và thích nghi quy trình cho phù hợp." Nghe rất "agile" đúng không? Nhưng đáp án này sai.
"By the book": Daily Scrum diễn ra mỗi ngày làm việc của Sprint — đây là một quy định cố định, không phải thứ team được tùy ý bỏ. Self-management cho phép team quyết định cách họ làm việc trong khuôn khổ Scrum, chứ không cho phép họ xóa bỏ các sự kiện mà Scrum quy định. Scrum Master nên giúp team hiểu mục đích thật của Daily Scrum (inspect tiến độ hướng tới Sprint Goal và adapt kế hoạch), chứ không phải bỏ nó.
Bài học rút ra: Có một cái bẫy tinh vi tên là "ngụy biện self-management" — đáp án nghe có vẻ tôn trọng team, nhưng thực ra vi phạm khung Scrum. Trong phòng thi, hãy phân biệt rõ: team tự quản về cách thực thi, không tự quản về việc có tuân thủ framework hay không.
Tình huống 3 — Bạn Minh và đáp án "đúng thực tế nhưng sai sách"
Minh là junior developer mới chuyển sang vai trò Scrum Master, ôn thi rất chăm. Cậu gặp câu:
> "Definition of Done là gì?" > A. Một checklist do QA team định nghĩa. > B. Một tài liệu mô tả tiêu chí nghiệm thu cho từng user story. > C. Một cam kết (commitment) cho Increment, mô tả trạng thái khi công việc đạt chất lượng cần thiết cho sản phẩm. > D. Một bản hợp đồng giữa Product Owner và Developers.
Ở công ty cũ của Minh, DoD đúng là một checklist do QA dựng lên (đáp án A), và acceptance criteria thì gắn theo từng story (đáp án B nghe rất quen). Minh suýt chọn A. Nhưng cậu kịp tự hỏi: "Scrum Guide định nghĩa thế nào?". Đáp án đúng là C — DoD là một commitment gắn với Increment, mô tả trạng thái chất lượng. Acceptance criteria của từng story là chuyện khác (và không nằm trong Scrum Guide).
Bài học rút ra: Khi thấy một đáp án "y hệt công ty mình", hãy cảnh giác — đó thường là mồi nhử (distractor) được thiết kế đúng để bẫy người có kinh nghiệm. Luôn quay về định nghĩa gốc.
Hướng dẫn từng bước
Đây là quy trình tư duy bạn nên áp dụng cho mỗi câu hỏi trong phòng thi:
Bước 1 — Đọc câu hỏi và tự hỏi: "Câu này hỏi về định nghĩa hay về tình huống?" Câu định nghĩa (ai chịu trách nhiệm gì, timebox bao lâu, artifact là gì) → trả lời chính xác theo câu chữ Scrum Guide. Câu tình huống ("Scrum Master nên làm gì khi...") → chọn hành động phù hợp giá trị Scrum và vai trò servant-leader.
Bước 2 — Tách "công ty tôi" ra khỏi đầu. Mỗi khi một đáp án khiến bạn nghĩ "ờ đúng rồi, bên mình làm vậy", hãy bật đèn cảnh báo. Hỏi lại: "Scrum Guide có nói chính xác như vậy không?". Nếu không chắc, đó có thể là bẫy.
Bước 3 — Với câu định nghĩa, ưu tiên đáp án dùng đúng thuật ngữ Scrum Guide. Đáp án đúng thường dùng đúng từ khóa: "accountability" (không phải "role/job"), "commitment", "transparency", "Developers" (không phải "the team" chung chung), "Product Goal", "Sprint Goal". Đáp án sai hay dùng từ ngoài Scrum: "manager", "resource", "task assignment", "phase", "sign-off".
Bước 4 — Với câu tình huống, loại bỏ ngay các hành động command-and-control. Bất cứ đáp án nào kiểu "Scrum Master ra lệnh", "Scrum Master quyết định thay team", "báo cáo lên sếp để xử lý" thường sai. Ưu tiên đáp án giúp team tự nhận ra và tự giải quyết — coach, facilitate, làm cho vấn đề minh bạch (transparent).
Bước 5 — Đừng sợ đáp án tuyệt đối với câu định nghĩa. "Daily Scrum diễn ra mỗi ngày" — đúng. "Sprint không bao giờ vượt 1 tháng" — đúng. Scrum Guide có nhiều khẳng định cứng; đừng loại chúng chỉ vì chúng nghe "quá tuyệt đối".
Bước 6 — Khi phân vân giữa hai đáp án, chọn cái gần câu chữ Scrum Guide hơn, không phải cái "thực tế hơn". Đây là nguyên tắc quyết định cuối cùng. Thực tế thua sách. Luôn luôn, trong phòng thi PSM I.
Bước 7 — Đánh dấu câu phân vân, làm tiếp, quay lại sau. Bạn có 60 phút cho 80 câu (45 giây/câu). "By the book" giúp bạn quyết nhanh các câu định nghĩa, dành thời gian cho câu tình huống khó.
Lỗi thường gặp & mẹo
Lỗi 1: Đọc Scrum Guide một lần rồi nghĩ đã đủ. Guide chỉ 13 trang nhưng từng câu đều có trọng lượng. Hãy đọc tối thiểu 3 lần, lần cuối đọc chậm và gạch chân từng động từ ("decides", "owns", "is accountable for").
Lỗi 2: Lẫn lộn nguồn kiến thức. Bạn đọc blog, xem YouTube, học SAFe... rồi mang vào phòng thi. PSM I chỉ thi Scrum Guide 2020. Mẹo: trong tuần cuối, chỉ ôn từ Scrum Guide chính thức, gạt mọi nguồn phụ.
Lỗi 3: Trả lời theo "điều nên làm" thay vì "điều Scrum định nghĩa". Câu "Story point bao nhiêu là chuẩn cho một Sprint?" — bẫy, vì Scrum Guide không nói gì về story point. Nếu đề có đáp án "Scrum không quy định điều này", nó thường đúng.
Lỗi 4: Bỏ qua từ khóa định nghĩa vai trò. Nhớ kỹ: Developers own Sprint Backlog; Product Owner owns Product Backlog; cả Scrum Team owns Increment và chịu trách nhiệm về Product Goal. Nhiều câu chỉ xoay quanh chữ "ai sở hữu cái gì".
Mẹo vàng: Mỗi lần làm đề luyện sai một câu, đừng chỉ ghi nhớ đáp án đúng — hãy tìm đúng câu trong Scrum Guide chứng minh đáp án đó. Khi bạn map được mọi sai sót về một dòng cụ thể trong Guide, bạn đã "by the book" thật sự.
Mẹo về tâm lý: Khi gặp câu mà cả phần thực tế lẫn trực giác đều "cãi" lại sách, hãy tin sách. Hãy tự nhủ một câu thần chú đơn giản trước khi vào phòng thi: "Tôi không thi công ty tôi. Tôi thi Scrum Guide."
Bài tập thực hành
- Tự kiểm "công ty tôi" vs "sách": Liệt kê 5 điều mà công ty/dự án bạn đang làm khác với Scrum Guide (ví dụ: ai chạy Daily Scrum, ai estimate, Sprint dài bao lâu, có Definition of Ready không...). Với mỗi điều, viết ra câu chữ Scrum Guide tương ứng. Đây là 5 cái bẫy cá nhân của bạn.
- Săn distractor: Lấy một bộ đề luyện 20 câu (ví dụ Scrum Open trên scrum.org). Với mỗi câu, sau khi chọn, hãy đánh dấu đáp án nào là "bẫy thực tế" — tức nghe rất giống đời thật nhưng sai sách. Mục tiêu: nhận diện được pattern của distractor.
- Map về Guide: Chọn 10 câu bạn từng làm sai. Với mỗi câu, mở Scrum Guide và tìm đúng câu/đoạn chứng minh đáp án đúng. Ghi lại số trang/đoạn. Nếu không tìm được, có thể câu hỏi thuộc nhóm "Scrum Guide không quy định" — cũng là một bài học.
- Phân loại câu hỏi: Lấy 30 câu luyện, phân thành hai cột: "câu định nghĩa" và "câu tình huống". Tập phản xạ nhận diện loại câu trong vòng 5 giây — vì hai loại này đòi hai chiến lược trả lời khác nhau.
- Tự đặt câu thần chú: Viết ra một câu nhắc nhở của riêng bạn (ví dụ: "Bên mình làm vậy ≠ Scrum quy định vậy") và đọc nó trước mỗi buổi luyện đề, để biến tư duy "by the book" thành phản xạ.
Tóm tắt
- PSM I kiểm tra Scrum Guide 2020 như được viết, không phải Scrum như công ty bạn thực hành. Đây là khác biệt cốt lõi quyết định đậu/trượt.
- Kinh nghiệm thực tế có thể phản chủ vì những tùy biến phổ biến nhất lại chính là các đáp án bẫy (distractor) được thiết kế đúng để gài người có kinh nghiệm.
- Với câu định nghĩa: trả lời chính xác theo câu chữ, dùng đúng thuật ngữ Scrum (accountability, commitment, owns, transparency), đừng sợ đáp án tuyệt đối.
- Với câu tình huống: chọn hành động servant-leader (coach, facilitate, làm minh bạch), loại bỏ command-and-control.
- Quy tắc quyết định cuối cùng khi phân vân: chọn đáp án gần Scrum Guide hơn, không phải đáp án "thực tế hơn".
- Mẹo luyện tập mạnh nhất: map mọi câu sai về đúng một dòng trong Scrum Guide, và tự tách bạch "công ty tôi" khỏi "sách".