Mở đầu — vì sao bài này quan trọng
Nếu bạn đã đi qua các bài lý thuyết về The Sprint, Sprint Planning, Daily Scrum, Sprint Review và Sprint Retrospective, thì đây là lúc "đem ra sa trận". Bài 53 là bộ câu hỏi luyện tập tập trung hoàn toàn vào Scrum Events — và đây là mảng kiến thức xuất hiện dày đặc nhất trong kỳ thi PSM I.
Lý do rất thực tế: trong 80 câu hỏi của kỳ thi PSM I (làm trong 60 phút, cần đúng ít nhất 85% tức 68 câu), riêng phần Events thường chiếm khoảng 15–20 câu. Đây cũng là phần "dễ ăn điểm" nhất nếu bạn thuộc đúng theo Scrum Guide, nhưng cũng là cái bẫy nguy hiểm nhất nếu bạn trả lời theo "kinh nghiệm công ty" thay vì theo sách. Rất nhiều người làm Scrum 3–5 năm vẫn rớt PSM I chính vì họ trả lời "theo team mình hay làm thế" thay vì "theo Scrum Guide quy định thế nào".
Trong bài này, chúng ta sẽ làm một bộ câu hỏi mô phỏng sát đề thi thật về timebox, mục đích, người tham gia, và quyền sở hữu của từng event. Mỗi câu mình sẽ phân tích đáp án đúng, và quan trọng hơn — giải thích vì sao những đáp án sai lại sai, vì kỳ thi PSM I sống nhờ những lựa chọn nhiễu (distractor) cực kỳ tinh vi.
Khái niệm cốt lõi
Trước khi vào câu hỏi, hãy ghim lại "bộ số" về 5 events mà bạn phải thuộc lòng — vì khoảng một phần ba câu hỏi Events thực chất là kiểm tra trí nhớ của bạn về timebox.
Bộ timebox phải thuộc lòng (cho Sprint 1 tháng)
- The Sprint: tối đa 1 tháng (one month or less). Đây là container chứa 4 event còn lại.
- Sprint Planning: tối đa 8 tiếng cho Sprint 1 tháng.
- Daily Scrum: tối đa 15 phút, mỗi ngày, cùng giờ cùng chỗ.
- Sprint Review: tối đa 4 tiếng cho Sprint 1 tháng.
- Sprint Retrospective: tối đa 3 tiếng cho Sprint 1 tháng.
Bốn ý niệm bị nhầm nhiều nhất
- Timebox là giới hạn TRÊN, không phải thời lượng cố định. "8 tiếng" nghĩa là "tối đa 8 tiếng", không phải "phải họp đủ 8 tiếng".
- Mỗi event là một cơ hội Inspect & Adapt. Nếu một câu hỏi mô tả một event mà không có thanh tra hay thích nghi gì, hãy nghi ngờ.
- Không event nào được bỏ qua. Scrum Guide ghi rõ: các event được thiết kế để tạo sự đều đặn (regularity) và giảm thiểu họp hành ngoài luồng. Bỏ một event = giảm minh bạch.
- Quyền sở hữu vs. người tham gia là hai chuyện khác nhau. Ví dụ Daily Scrum là của Developers, nhưng Scrum Master không "chủ trì".
Q1 — Timebox Sprint Planning
"Đâu là timebox của Sprint Planning cho một Sprint kéo dài 1 tháng?"
- A. 4 tiếng
- B. 8 tiếng tối đa ✓
- C. 16 tiếng
- D. Không có giới hạn
Q2 — Ai chủ trì Daily Scrum?
"Trong Daily Scrum, ai chịu trách nhiệm tổ chức và điều hành sự kiện này?"
- A. Scrum Master
- B. Product Owner
- C. Developers ✓
- D. Người quản lý dự án
Q3 — Sprint Review có phải là buổi nghiệm thu (sign-off)?
"Phát biểu nào đúng nhất về Sprint Review?"
- A. Là buổi để khách hàng phê duyệt và ký nghiệm thu sản phẩm chính thức
- B. Là buổi làm việc cộng tác giữa Scrum Team và stakeholders để thanh tra Increment và điều chỉnh Product Backlog ✓
- C. Là buổi demo một chiều, team trình bày, stakeholders chỉ xem
- D. Là sự kiện nội bộ, không có stakeholders
Q4 — Sprint Retrospective tập trung vào điều gì?
"Mục đích chính của Sprint Retrospective là gì?"
- A. Thanh tra Increment sản phẩm
- B. Lập kế hoạch cải tiến chất lượng và hiệu quả — về con người, quan hệ, quy trình và công cụ ✓
- C. Cập nhật Product Backlog cho Sprint tới
- D. Báo cáo tiến độ cho quản lý cấp cao
Q5 — Sprint có thể bị kéo dài thêm không?
"Sprint Goal có vẻ sẽ không đạt được khi sắp hết Sprint. Đội đề nghị kéo dài Sprint thêm 3 ngày. Điều này có hợp lệ không?"
- A. Có, nếu Product Owner đồng ý
- B. Có, nếu tất cả thành viên đồng thuận
- C. Không, một khi Sprint bắt đầu, độ dài (timebox) được giữ cố định và không được kéo dài ✓
- D. Có, nhưng tối đa 3 ngày
Q6 — Daily Scrum 15 phút áp dụng thế nào?
"Sprint của team kéo dài 1 tuần. Daily Scrum nên được giới hạn bao lâu?"
- A. Tỉ lệ theo độ dài Sprint, nên ngắn hơn 15 phút
- B. 15 phút ✓
- C. 5 phút
- D. Tùy team quyết định, không cố định
Tình huống thực tế
Tình huống 1 — Công ty fintech ở TP.HCM và cái "demo nghiệm thu"
Một công ty fintech tên giả định MoMoPay Labs ở Quận 1, TP.HCM, có team 6 Developers làm app ví điện tử. Cuối mỗi Sprint 2 tuần, họ tổ chức cái mà họ gọi là "Demo Day": team trình chiếu slide 45 phút, giám đốc sản phẩm xem xong gật đầu "ký duyệt", rồi mọi người giải tán. Stakeholders không được hỏi, không được góp ý chiều ngược lại.
Khi một bạn trong team đi thi PSM I, bạn gặp đúng câu Q3 ở trên và theo phản xạ chọn phương án "buổi demo một chiều, stakeholders chỉ xem" — vì đó là điều bạn làm mỗi Sprint. Kết quả: sai.
Diễn giải: Cái "Demo Day" của MoMoPay Labs vi phạm tinh thần Sprint Review. Theo Scrum Guide, Sprint Review là buổi cộng tác hai chiều để thanh tra Increment và điều chỉnh Product Backlog dựa trên thông tin mới. Việc "ký nghiệm thu" cũng không phải mục đích của event — Increment phải đạt Definition of Done từ trước, chứ không chờ tới Review mới được "duyệt".
Bài học rút ra: Trong phòng thi, hãy tách bạch "cách công ty mình làm" và "Scrum Guide nói gì". Câu hỏi PSM I luôn hỏi cái thứ hai.
Tình huống 2 — Startup e-commerce ở Hà Nội và Sprint Planning "không giới hạn"
Một startup e-commerce giả định ChợSố ở Cầu Giấy, Hà Nội, chạy Sprint 1 tháng. Họ có thói quen họp Sprint Planning… cho tới khi nào "xong thì thôi", có hôm kéo từ 9h sáng tới 6h chiều, có hôm sang cả ngày hôm sau — tổng cộng có khi 12–14 tiếng.
Anh Scrum Master mới về, đi thi PSM I, gặp câu Q1 và phân vân giữa "16 tiếng" và "không giới hạn", vì trải nghiệm thực tế của anh là "planning kéo dài bất tận".
Diễn giải: Đáp án đúng vẫn là 8 tiếng tối đa cho Sprint 1 tháng. Việc team ChợSố họp 12–14 tiếng là anti-pattern, không phải chuẩn mực. Một buổi Planning kéo quá dài thường là dấu hiệu Product Backlog chưa được refinement đủ trước đó, hoặc team đang cố lập kế hoạch chi tiết cho cả Sprint thay vì chỉ đủ để bắt đầu.
Bài học rút ra: Khi thấy đáp án "không có giới hạn" (no limit / unlimited) cho bất kỳ event nào, gần như chắc chắn đó là đáp án sai. Mọi event trong Scrum đều có timebox.
Tình huống 3 — Team outsourcing ở Đà Nẵng và Daily Scrum bị "biến tướng"
Một công ty outsourcing giả định ở Đà Nẵng, DaNang Software House, có team làm cho khách Nhật. Mỗi sáng, Scrum Master đứng giữa phòng, lần lượt gọi tên từng Developer hỏi "hôm qua làm gì, hôm nay làm gì, có vướng gì không", ghi chép lại rồi báo cáo cho Project Manager. Buổi họp thường kéo 30–40 phút vì sa đà vào giải quyết vấn đề kỹ thuật ngay tại chỗ.
Một bạn Developer đi thi gặp câu Q2 ("ai chủ trì Daily Scrum") và chọn "Scrum Master" — vì ở team bạn, đúng là Scrum Master gọi tên và điều hành.
Diễn giải: Cách làm của DaNang Software House sai ở ba điểm. Thứ nhất, Daily Scrum là của Developers, do Developers tự lập kế hoạch cho 24 giờ tới hướng Sprint Goal — không phải buổi "báo cáo cho Scrum Master hay PM". Thứ hai, nó phải trong 15 phút; việc sa đà giải quyết vấn đề kỹ thuật nên được tách ra thành cuộc trao đổi riêng sau Daily Scrum. Thứ ba, định dạng "3 câu hỏi" (hôm qua/hôm nay/vướng gì) trong Scrum Guide 2020 không còn bắt buộc — Developers được tự chọn cách thức, miễn tập trung vào tiến độ hướng tới Sprint Goal.
Bài học rút ra: Đáp án đúng là Developers (C). Hãy nhớ: Scrum Master đảm bảo event diễn ra đúng và đủ ngắn, nhưng không sở hữu, không chủ trì Daily Scrum.
Hướng dẫn từng bước
Đây là quy trình mình khuyên bạn áp dụng cho mọi câu hỏi về Events trong phòng thi:
Bước 1 — Nhận diện event đang được hỏi. Đọc câu hỏi và xác định ngay nó đang nói về Sprint, Planning, Daily, Review hay Retrospective. Đôi khi câu hỏi không nêu tên event trực tiếp mà mô tả qua mục đích ("buổi để cải tiến quy trình" → Retrospective).
Bước 2 — Gọi ra "thẻ thông tin" của event đó trong đầu. Mỗi event có 4 thuộc tính bạn nên thuộc: (1) timebox, (2) mục đích/output, (3) ai sở hữu/tham gia, (4) thanh tra cái gì. Ví dụ với Sprint Review: 4 tiếng / điều chỉnh Product Backlog / Scrum Team + stakeholders / thanh tra Increment.
Bước 3 — Loại ngay các đáp án có "tín hiệu chết". Gạch bỏ những phương án chứa: "không giới hạn thời gian", "bỏ qua event nếu không cần", "Scrum Master quyết định thay team", "kéo dài Sprint". Những cụm này gần như luôn sai trong PSM I.
Bước 4 — Phân biệt quyền sở hữu vs. người tham gia. Nếu câu hỏi về "ai chịu trách nhiệm/ai sở hữu", hãy nhớ: Planning, Review, Retrospective có cả Scrum Team tham gia; Daily Scrum thuộc về Developers; Sprint Cancellation chỉ Product Owner mới được quyết.
Bước 5 — Đối chiếu với mục đích Inspect & Adapt. Đáp án đúng thường là đáp án phục vụ tốt nhất cho việc thanh tra và thích nghi, đồng thời tăng minh bạch. Nếu một phương án làm giảm cộng tác hoặc minh bạch, nghi ngờ nó.
Bước 6 — Chọn đáp án "by the book". Nếu hai phương án đều "nghe hợp lý", hãy chọn cái gần với câu chữ Scrum Guide nhất, không phải cái gần với thực tế công ty bạn nhất.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm timebox giữa Review (4h) và Retrospective (3h). Đây là cặp số bị đảo nhiều nhất. Mẹo nhớ: theo thứ tự diễn ra cuối Sprint, Review trước Retrospective, và số giảm dần 4 → 3. "Review xem sản phẩm cần nhiều thời gian hơn (4) so với nhìn lại quy trình (3)".
Lỗi 2 — Tưởng timebox là thời lượng bắt buộc. Timebox luôn là giới hạn tối đa. Một Daily Scrum xong trong 7 phút là hoàn toàn ổn. Câu hỏi nào ngụ ý "phải họp đủ X tiếng" thì sai.
Lỗi 3 — Cho rằng Scrum Master chủ trì mọi event. Scrum Master là người đảm bảo event diễn ra, hữu ích, đúng timebox — nhưng Daily Scrum thuộc Developers, và Scrum Master thậm chí có thể không cần dự nếu Developers tự chạy tốt.
Lỗi 4 — Nghĩ có thể bỏ qua một event. "Sprint ngắn nên bỏ Retrospective cho nhanh" là sai. Các event được thiết kế để tạo sự đều đặn; bỏ event làm giảm cơ hội Inspect & Adapt.
Lỗi 5 — Lẫn lộn Sprint Planning với Refinement. Refinement là hoạt động liên tục (ongoing activity), không phải event chính thức. Sprint Planning là event và có timebox; câu hỏi nào gọi Refinement là "event thứ 6" thì sai.
Mẹo vàng: Khi bí giữa hai đáp án, hãy tự hỏi "đáp án nào trao quyền tự quản cho team và tăng minh bạch hơn?". PSM I gần như luôn thưởng cho lựa chọn đó.
Bài tập thực hành
Hãy tự làm 4 câu sau trước khi xem gợi ý, bấm giờ 4 phút (mô phỏng nhịp độ 45 giây/câu của đề thật):
Câu 1. Một Sprint kéo dài 2 tuần. Timebox tối đa hợp lý cho Sprint Review là? A. 4 tiếng B. 2 tiếng C. 3 tiếng D. Không cố định
Câu 2. Trong Daily Scrum, một Developer phát hiện một việc kỹ thuật phức tạp cần thảo luận sâu 40 phút. Nên làm gì? A. Kéo dài Daily Scrum thêm 40 phút B. Bỏ qua, để Sprint sau C. Ghi nhận và tổ chức thảo luận riêng ngay sau Daily Scrum D. Báo cáo Scrum Master quyết định
Câu 3. Ai có quyền hủy (cancel) một Sprint? A. Scrum Master B. Developers biểu quyết C. Product Owner D. Stakeholders
Câu 4. Phát biểu nào về Sprint Planning là đúng? A. Chỉ Product Owner và Scrum Master tham gia B. Toàn bộ Scrum Team cùng tham gia, có thể mời người khác tư vấn C. Phải lập kế hoạch chi tiết đến từng giờ cho cả Sprint D. Bắt buộc kéo dài đủ 8 tiếng
Gợi ý đáp án:
- Câu 1: A (4 tiếng) — đây là giới hạn trên cho tới Sprint 1 tháng; Sprint 2 tuần "thường ngắn hơn" nhưng 4 tiếng vẫn là mốc trần hợp lệ, và các phương án 2h/3h là timebox của event khác hoặc con số bịa. Nếu đề ghi rõ "cho Sprint 1 tháng" thì chắc chắn 4 tiếng; với 2 tuần, chọn phương án thể hiện "tối đa, thường ngắn hơn".
- Câu 2: C — Daily Scrum giữ trong 15 phút; thảo luận sâu tách ra riêng. Không kéo dài event, không bỏ qua vấn đề.
- Câu 3: C (Product Owner) — chỉ Product Owner mới có quyền hủy Sprint, thường khi Sprint Goal trở nên lỗi thời.
- Câu 4: B — cả Scrum Team tham gia Planning; Developers có thể mời thêm người để xin tư vấn. A loại Developers nên sai; C lập kế hoạch quá chi tiết là anti-pattern; D nhầm timebox thành thời lượng bắt buộc.
Tóm tắt
- Phần Events chiếm tỉ trọng lớn trong PSM I và là phần "ăn điểm chắc" nếu bạn thuộc đúng theo Scrum Guide.
- Bộ timebox cho Sprint 1 tháng phải thuộc lòng: Sprint ≤ 1 tháng, Planning 8h, Daily 15 phút, Review 4h, Retrospective 3h.
- Timebox là giới hạn tối đa, không phải thời lượng bắt buộc. "Không giới hạn" gần như luôn là đáp án sai.
- Phân biệt rạch ròi: Review thanh tra Increment/sản phẩm; Retrospective thanh tra process/cách làm việc.
- Daily Scrum thuộc về Developers; Scrum Master chỉ đảm bảo nó diễn ra đúng, không chủ trì.
- Sprint không bao giờ được kéo dài; chỉ Product Owner mới có quyền hủy Sprint.
- Trong phòng thi, luôn trả lời "by the book" — theo Scrum Guide, không theo cách công ty bạn quen làm. Ba tình huống MoMoPay Labs, ChợSố và DaNang Software House cho thấy chính "thói quen công ty" là cái bẫy khiến nhiều người trả lời sai.