Mở đầu — vì sao bài này quan trọng
Nếu bạn từng làm bài thi thử PSM I và gặp câu hỏi kiểu "Inspection diễn ra khi nào trong Scrum?" hoặc "Bao nhiêu Scrum Event là cơ hội để inspect?", rất có thể bạn đã từng chọn sai. Đây là một trong những vùng gây nhầm lẫn (confusion area) tinh vi nhất của kỳ thi, vì nó nằm ở ranh giới giữa hai khái niệm nghe rất giống nhau: inspection event (sự kiện kiểm tra chính thức) và touchpoint (điểm chạm, tương tác không chính thức).
Nhiều học viên Việt Nam thuộc lòng câu "Daily Scrum là để inspect tiến độ", "Sprint Review là để inspect Increment" — đúng. Nhưng khi đề thi hỏi xoáy: "Một Developer kiểm tra code của đồng nghiệp giữa Sprint có phải là một inspection trong Scrum không?" thì họ lúng túng. Sự lúng túng này đến từ việc không phân biệt được: đâu là cơ hội inspect được Scrum Guide định nghĩa chính thức (formal), và đâu chỉ là sự tương tác/kiểm tra diễn ra liên tục trong công việc hàng ngày.
Scrum Guide 2020 dùng một cụm từ rất quan trọng: "Scrum's four formal events for inspection and adaptation are contained within the Sprint" — nghĩa là Scrum có bốn sự kiện formal dành cho inspect và adapt, và tất cả nằm trong Sprint (bản thân Sprint là container). Cụm từ "formal" này chính là chìa khóa của cả bài học hôm nay. Hiểu đúng nó, bạn sẽ trả lời chính xác một nhóm 4–6 câu hỏi trong đề thi PSM I — một biên độ điểm đủ để quyết định đậu hay rớt khi ngưỡng đậu là 85%.
Khái niệm cốt lõi
Inspection trong Empiricism — nhắc lại nhanh
Trong ba trụ cột của Empiricism (Transparency, Inspection, Adaptation), Inspection nghĩa là thường xuyên kiểm tra các Scrum Artifacts và tiến độ hướng tới mục tiêu đã thỏa thuận, nhằm phát hiện các sai lệch hoặc vấn đề không mong muốn. Inspection phải đủ thường xuyên để hữu ích, nhưng không quá dày khiến cản trở công việc.
Điểm cốt lõi: Inspection được "thể chế hóa" thông qua các formal events. Scrum không yêu cầu bạn inspect ngẫu nhiên hay tùy hứng — nó thiết kế sẵn các điểm dừng có nhịp (cadence) để đảm bảo việc inspect luôn xảy ra.
Bốn formal events for inspection and adaptation
Scrum Guide 2020 liệt kê rõ ràng. Sprint là container chứa tất cả, còn bên trong có bốn sự kiện formal phục vụ inspect & adapt:
| Formal Event | Artifact/đối tượng được inspect | Cái được adapt |
|---|---|---|
| Sprint Planning | Product Backlog, Product Goal, capacity | Tạo ra Sprint Backlog + Sprint Goal |
| Daily Scrum | Tiến độ hướng tới Sprint Goal (qua Sprint Backlog) | Điều chỉnh kế hoạch cho ngày làm việc tiếp theo |
| Sprint Review | Increment, Product Backlog, tình hình thị trường | Điều chỉnh Product Backlog, có thể cập nhật Product Goal |
| Sprint Retrospective | Cách team làm việc (con người, quan hệ, process, tools) | Cam kết cải tiến trong Sprint tới |
Tuy nhiên — và đây là chỗ tinh tế — nếu đề hỏi "Scrum có mấy events tất cả?" thì đáp án là năm (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective). Phải đọc kỹ: câu hỏi đang nói về tổng số events hay số events formal dành cho inspect & adapt?
Touchpoint là gì, và vì sao nó KHÁC formal inspection
Touchpoint không phải là thuật ngữ chính thức trong Scrum Guide. Đó là cách gọi quen thuộc trong thực hành để chỉ những lần tương tác, kiểm tra, trao đổi diễn ra liên tục, không chính thức, bên ngoài các formal events. Ví dụ:
- Một Developer hỏi đồng nghiệp "mày review giúp tao đoạn code này nhé" lúc 2 giờ chiều.
- Product Owner ghé bàn Developer giải thích thêm về một Product Backlog Item.
- Hai Developer pair-programming và liên tục kiểm tra lẫn nhau.
- Scrum Master quan sát thấy một impediment và trao đổi riêng để gỡ.
- Một stakeholder gửi email phản hồi giữa Sprint.
Cách diễn đạt chuẩn để nhớ: Formal inspection xảy ra TẠI các events. Touchpoint/collaboration xảy ra LIÊN TỤC, mọi lúc, để bổ trợ — nhưng không thay thế — cho các formal events.
Vì sao đề thi PSM I thích test vùng này
Người ra đề muốn kiểm tra xem bạn có hiểu rằng:
- Việc inspect liên tục hàng ngày (collaboration) là tốt và cần thiết, nhưng nó không loại bỏ nhu cầu có các formal events. Một số câu hỏi cố ý gợi ý "team chúng tôi đã trao đổi liên tục rồi nên không cần Daily Scrum nữa" — đây là sai. Daily Scrum vẫn cần vì nó là formal inspection point có mục đích cụ thể: inspect tiến độ tới Sprint Goal.
- Ngược lại, không phải mọi tương tác trong ngày đều phải bị gò vào một event. Sprint không "đông cứng" giữa các formal events; team vẫn tự do hợp tác.
- Người mới hay nhầm rằng Increment chỉ được inspect tại Sprint Review. Thực ra Increment được tạo ra liên tục trong Sprint và được kiểm tra qua nhiều touchpoint, nhưng formal inspection của Increment với stakeholders mới chính thức diễn ra tại Sprint Review.
Tình huống thực tế
Tình huống 1 — Tiki và cái bẫy "chúng tôi trao đổi liên tục rồi"
Tại một Scrum Team trong bộ phận thanh toán của một sàn thương mại điện tử lớn ở Việt Nam (giả định lấy bối cảnh Tiki), nhóm 6 Developers ngồi chung một bàn và làm pair-programming gần như cả ngày. Họ liên tục biết ai đang làm gì. Một Developer kỳ cựu đề xuất với Scrum Master: "Bọn em nói chuyện với nhau suốt rồi, Daily Scrum 15 phút mỗi sáng thành ra thừa thãi, bỏ đi cho đỡ mất thời gian."
Scrum Master tên Huy đã không đồng ý ngay, mà giải thích: việc các bạn trao đổi cả ngày là touchpoint — rất tốt, rất đáng quý. Nhưng Daily Scrum là một formal inspection event với mục đích riêng: cả nhóm cùng nhìn vào tiến độ hướng tới Sprint Goal, và cùng điều chỉnh kế hoạch cho 24 giờ tới. Trong các cuộc trao đổi rời rạc suốt ngày, không ai đảm bảo cả nhóm cùng có chung một bức tranh về Sprint Goal. Sau hai Sprint thử bỏ Daily Scrum, nhóm phát hiện hai Developer đã đi lệch hướng và làm một tính năng không nằm trong Sprint Goal — vì không có điểm formal nào để cả nhóm cùng "đồng bộ" lại.
Bài học: Touchpoint liên tục KHÔNG thay thế formal event. Mỗi formal event có một mục đích inspect riêng mà các cuộc trao đổi ngẫu nhiên không tự động đáp ứng. Trong đề thi, nếu thấy đáp án kiểu "vì team đã collaborate liên tục nên có thể bỏ Daily Scrum/Sprint Review" — gần như chắc chắn đó là đáp án SAI.
Tình huống 2 — Một fintech ở Singapore và câu hỏi "Increment được inspect ở đâu?"
Một Scrum Team trong một công ty fintech ở Singapore phát triển ứng dụng ví điện tử. Trong Sprint, mỗi khi một Developer hoàn thành một Product Backlog Item đạt Definition of Done, họ merge vào nhánh chính và Increment lớn dần. QA kiểm tra liên tục, tech lead review code mỗi pull request. Đến cuối Sprint, Product Owner hỏi: "Increment của mình đã được kiểm tra suốt Sprint rồi, vậy Sprint Review có còn cần thiết không?"
Câu trả lời đúng: Có, vẫn cần. Việc QA và tech lead kiểm tra liên tục là touchpoint kỹ thuật — đảm bảo chất lượng nội bộ. Nhưng Sprint Review là formal inspection với một mục đích mà touchpoint nội bộ không thể thay thế: đó là nơi Scrum Team và stakeholders cùng inspect Increment, thảo luận về điều gì đã thay đổi trong môi trường, và cùng nhau điều chỉnh Product Backlog cho hướng đi tiếp theo. Sprint Review không phải là buổi nghiệm thu kỹ thuật — nó là một buổi làm việc cộng tác (working session), nơi sự thay đổi của thị trường được đưa vào và Product Backlog được adapt.
Bài học: Cùng một artifact (Increment) có thể được "chạm" qua nhiều touchpoint nội bộ trong Sprint, nhưng formal inspection cùng stakeholders chỉ diễn ra tại Sprint Review. Hai việc này phục vụ mục đích khác nhau và không loại trừ nhau.
Tình huống 3 — Đề thi đánh lừa: "Sprint là một inspection event?"
Bạn Linh, một học viên đang ôn PSM I, gặp câu hỏi: "Which of the following events provides a formal opportunity to inspect and adapt? (Select all that apply)" với các lựa chọn: The Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
Linh, theo phản xạ, tích cả năm vì nghĩ "event nào chẳng để inspect". Sai. Đáp án đúng chỉ gồm bốn: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective. The Sprint không nằm trong nhóm formal inspection events — nó là container chứa các sự kiện kia. Bản thân Sprint tạo ra nhịp (cadence) để empiricism diễn ra, nhưng nó không phải là một "buổi" để bạn ngồi xuống inspect & adapt.
Bài học: Khi đề dùng cụm "formal opportunity to inspect and adapt" — loại Sprint ra. Khi đề hỏi "tổng số Scrum events" — đáp án là năm. Đọc kỹ từng chữ trong câu hỏi, đặc biệt từ "formal" và "inspection".
Hướng dẫn từng bước
Khi gặp một câu hỏi liên quan đến inspection trong đề thi PSM I, hãy đi theo quy trình tư duy sau:
- Xác định câu hỏi đang nói về "formal events" hay "tổng số events". Nếu có chữ "formal" + "inspection/adaptation" → câu trả lời xoay quanh con số bốn (loại Sprint). Nếu hỏi "how many events in Scrum" → năm.
- Hỏi: đây là một formal event hay một touchpoint? Nếu tình huống mô tả một tương tác ngẫu nhiên, không có trong danh sách 5 events (ví dụ: hai Developer review code, PO ghé bàn giải thích) → đó là touchpoint/collaboration, không phải formal inspection. Scrum chấp nhận và khuyến khích nó, nhưng nó không có timebox, không thuộc 5 events.
- Kiểm tra logic "thay thế". Nếu một đáp án ngụ ý rằng touchpoint có thể thay thế một formal event ("vì đã trao đổi liên tục nên bỏ Daily Scrum/Sprint Review") → loại đáp án đó. Formal events và touchpoint bổ trợ nhau, không thay thế nhau.
- Gắn mỗi event với đúng đối tượng được inspect. Nhớ bảng: Sprint Planning inspect Product Backlog; Daily Scrum inspect tiến độ tới Sprint Goal; Sprint Review inspect Increment + Product Backlog; Sprint Retrospective inspect cách làm việc. Nếu đáp án gán sai cặp (ví dụ "Daily Scrum để inspect Increment với stakeholders") → loại.
- Cảnh giác với từ khóa lừa. "Touchpoint", "ad-hoc inspection", "continuous inspection", "whenever needed" thường gợi ý về tương tác không chính thức — đừng nhầm chúng với 4 formal events.
Lỗi thường gặp & mẹo
Lỗi 1 — Đếm Sprint vào nhóm formal inspection events. Sai phổ biến nhất. Nhớ: Sprint là container, bốn cái còn lại mới là formal inspection events.
Lỗi 2 — Nghĩ rằng inspect chỉ xảy ra tại events. Inspect (theo nghĩa empiricism, hành động kiểm tra) xảy ra liên tục qua touchpoint. Cái được thể chế hóa (formal) thì gói vào 4 events. Đừng nhầm "formal inspection chỉ có 4 điểm" thành "team chỉ được phép kiểm tra 4 lần".
Lỗi 3 — Cho rằng touchpoint có thể thay thế event. Như tình huống Tiki: collaboration liên tục không xóa bỏ nhu cầu formal event.
Lỗi 4 — Gán sai cặp event ↔ artifact được inspect. Học thuộc bảng ở phần Khái niệm cốt lõi.
Lỗi 5 — Lẫn lộn "tổng 5 events" với "4 formal inspection events". Luôn đọc kỹ từ "formal".
Mẹo ghi nhớ nhanh:
- "4 formal, 5 total": Bốn formal inspection events, năm events tổng cộng (vì Sprint là container).
- "Container không inspect": Sprint là cái hộp, không phải buổi inspect.
- "Touchpoint bổ trợ, không thay thế": collaboration liên tục luôn được hoan nghênh nhưng không xóa formal events.
- Một câu thần chú: "Inspect mọi lúc qua touchpoint, nhưng inspect & adapt chính thức thì tại 4 events trong Sprint."
Bài tập thực hành
Bài 1 (chọn đáp án). Có bao nhiêu formal events trong Scrum được dành riêng cho inspection and adaptation? A. 3 B. 4 C. 5 D. 6 (Gợi ý: loại Sprint vì nó là container.)
Bài 2 (đúng/sai). "Vì Developers trao đổi và review code của nhau liên tục trong ngày, team có thể bỏ Daily Scrum." Đúng hay sai? Giải thích bằng khái niệm formal event vs touchpoint.
Bài 3 (ghép cặp). Ghép mỗi event với đối tượng chính được inspect: Sprint Planning / Daily Scrum / Sprint Review / Sprint Retrospective ↔ (a) cách team làm việc, (b) tiến độ tới Sprint Goal, (c) Increment cùng stakeholders, (d) Product Backlog & Product Goal đầu Sprint.
Bài 4 (tình huống). Một PO ghé bàn Developer giữa Sprint để làm rõ một Product Backlog Item. Đây là (a) một formal inspection event, hay (b) một touchpoint? Việc này có vi phạm Scrum không? Vì sao?
Bài 5 (phản biện). Giải thích trong 3–4 câu vì sao "team chúng tôi inspect liên tục nên không cần Sprint Review" là một lập luận sai, dùng tình huống fintech Singapore làm minh họa.
Đáp án gợi ý: Bài 1: B (4). Bài 2: Sai — touchpoint không thay thế formal event; Daily Scrum có mục đích riêng là inspect tiến độ tới Sprint Goal và đồng bộ kế hoạch. Bài 3: Sprint Planning–(d), Daily Scrum–(b), Sprint Review–(c), Sprint Retrospective–(a). Bài 4: (b) touchpoint, hoàn toàn hợp lệ và được khuyến khích, không vi phạm Scrum. Bài 5: Touchpoint nội bộ inspect chất lượng kỹ thuật, nhưng Sprint Review là nơi formal inspect Increment cùng stakeholders và adapt Product Backlog theo thay đổi của môi trường — một mục đích mà touchpoint nội bộ không đáp ứng.
Tóm tắt
- Scrum có năm events tổng cộng, nhưng chỉ bốn formal events for inspection and adaptation: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective. Sprint là container, không nằm trong nhóm bốn này.
- Formal inspection xảy ra TẠI các events, có timebox và mục đích cụ thể. Touchpoint (collaboration, review, trao đổi ad-hoc) xảy ra LIÊN TỤC, không chính thức, được Scrum khuyến khích.
- Touchpoint bổ trợ chứ không thay thế formal events. Đáp án nào ngụ ý "vì đã trao đổi liên tục nên bỏ event" thường là sai.
- Mỗi event inspect một đối tượng riêng — học thuộc bảng cặp event ↔ artifact để không bị gán sai.
- Khi làm bài, đọc kỹ từ "formal" và phân biệt câu hỏi "tổng số events" (5) với "formal inspection events" (4). Đây là chỗ đề PSM I gài bẫy nhiều nhất trong vùng kiến thức này.