Mở đầu — vì sao bài này quan trọng
Nếu bạn đã đi qua các bài trước về từng sự kiện (event) riêng lẻ — Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective — thì bài này chính là nơi bạn lùi lại một bước để nhìn toàn cảnh. Bạn sẽ thấy 5 sự kiện này không phải là 5 cuộc họp rời rạc mọc lên một cách ngẫu nhiên trên lịch làm việc, mà là một hệ thống được thiết kế chặt chẽ, gắn kết với nhau bằng một sợi chỉ chung: inspect & adapt (kiểm tra và thích nghi).
Trong kỳ thi PSM I, đây là một trong những chủ đề mà bạn buộc phải nắm chắc đến mức "nhắm mắt cũng trả lời được". Câu hỏi về timebox (khung thời gian tối đa) xuất hiện rất nhiều, và đề thi rất thích "đánh lừa" bạn bằng cách đảo con số, đổi đơn vị, hoặc hỏi cùng một timebox nhưng với độ dài Sprint khác nhau. Một lỗi rất phổ biến là nhớ nhầm Daily Scrum 15 phút thành 15 phút "cho mỗi người", hoặc nhầm timebox của Sprint Planning từ 8 giờ thành 4 giờ. Chỉ cần lệch một con số, bạn mất điểm.
Quan trọng hơn cả việc học thuộc con số, bài này giúp bạn hiểu logic phía sau: tại sao Scrum lại có đúng 5 sự kiện này, tại sao mỗi sự kiện lại có timebox, và mỗi sự kiện đang "kiểm tra cái gì" và "thích nghi cái gì". Khi bạn hiểu logic, bạn sẽ không cần học vẹt — và đề thi PSM I được thiết kế chính xác để thưởng cho người hiểu, phạt người học vẹt.
Khái niệm cốt lõi
5 sự kiện — không hơn, không kém
Scrum Guide 2020 định nghĩa rõ ràng có 5 sự kiện (events). Một điểm tinh tế nhưng cực kỳ hay bị hỏi: bản thân Sprint là một sự kiện, và nó là "vật chứa" (container) cho 4 sự kiện còn lại. Nói cách khác:
- The Sprint — sự kiện bao trùm, chứa tất cả công việc và 4 sự kiện kia.
- Bên trong mỗi Sprint diễn ra 4 sự kiện: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
Tất cả sự kiện đều là cơ hội inspect & adapt
Đây là tư tưởng trung tâm bạn phải khắc cốt ghi tâm. Scrum được xây trên nền chủ nghĩa thực nghiệm (empiricism): bạn không thể lập kế hoạch hoàn hảo từ đầu, nên bạn phải làm từng phần nhỏ, kiểm tra kết quả thực tế, rồi điều chỉnh. Mỗi sự kiện được thiết kế đúng để tạo ra một điểm dừng có chủ đích — nơi nhóm dừng lại, nhìn vào một thứ cụ thể (inspect), và điều chỉnh hướng đi (adapt).
Bảng tổng hợp dưới đây là "trái tim" của bài này. Hãy ghi nhớ nó như một bản đồ:
| Sự kiện | Timebox (Sprint 1 tháng) | Inspect (kiểm tra gì) | Adapt (điều chỉnh gì) |
|---|---|---|---|
| Sprint | Tối đa 1 tháng (≤ 30 ngày / 4 tuần) | Tiến độ hướng tới Product Goal | Product Backlog, hướng đi sản phẩm |
| Sprint Planning | Tối đa 8 giờ | Product Backlog, năng lực nhóm | Tạo ra Sprint Backlog & Sprint Goal |
| Daily Scrum | Tối đa 15 phút, mỗi ngày | Tiến độ hướng tới Sprint Goal | Kế hoạch làm việc cho ngày tiếp theo |
| Sprint Review | Tối đa 4 giờ | Increment & tình hình thị trường/sản phẩm | Product Backlog |
| Sprint Retrospective | Tối đa 3 giờ | Quy trình, con người, công cụ, Definition of Done | Cách làm việc của nhóm (action items) |
Quy tắc timebox — chìa khóa của bài
Có vài nguyên tắc về timebox mà PSM I cực kỳ thích kiểm tra:
1. Timebox là tối đa (maximum), không phải cố định (fixed). Sprint Planning tối đa 8 giờ, không có nghĩa là phải họp đúng 8 giờ. Nếu nhóm chốt xong kế hoạch trong 3 giờ, họ kết thúc sớm — hoàn toàn ổn. Đề thi hay viết "the Sprint Planning must last 8 hours" — đây là SAI.
2. Daily Scrum luôn là 15 phút bất kể Sprint dài hay ngắn. Đây là sự kiện duy nhất có timebox cố định không co giãn theo độ dài Sprint. Sprint 1 tuần hay 1 tháng, Daily Scrum vẫn 15 phút.
3. Các timebox còn lại co giãn theo độ dài Sprint. Các con số 8 giờ / 4 giờ / 3 giờ trong bảng trên là cho Sprint 1 tháng. Với Sprint ngắn hơn, các timebox này thường ngắn hơn một cách tương ứng. Ví dụ Sprint 2 tuần thì Sprint Planning thường ≤ 4 giờ, Sprint Review ≤ 2 giờ, Retrospective thường ngắn hơn.
4. Sprint Retrospective khép lại Sprint. Nó là sự kiện cuối cùng, diễn ra sau Sprint Review và trước khi Sprint kế tiếp bắt đầu.
Trật tự thời gian của 5 sự kiện
Trong vòng đời một Sprint, trật tự là cố định:
- Sprint bắt đầu (container mở ra).
- Sprint Planning — sự kiện mở màn, kéo cả nhóm vào để định ra "Sprint này làm gì và tại sao".
- Daily Scrum — lặp lại mỗi ngày trong suốt Sprint.
- Sprint Review — gần cuối Sprint, kiểm tra Increment cùng các bên liên quan.
- Sprint Retrospective — sự kiện cuối, nhìn lại cách làm việc.
- Sprint kết thúc, và Sprint kế tiếp bắt đầu ngay lập tức.
Tình huống thực tế
Tình huống 1 — Tiki và cái bẫy "họp cho đủ giờ"
Một nhóm phát triển tại một công ty thương mại điện tử lớn ở TP.HCM (gọi là nhóm "Checkout" thuộc Tiki) chạy Sprint 2 tuần. Scrum Master mới — anh Hùng — đọc Scrum Guide thấy ghi "Sprint Planning tối đa 8 giờ cho Sprint 1 tháng", nên anh áp dụng nguyên xi: mỗi đầu Sprint, anh đặt lịch họp Planning 4 giờ liền (vì Sprint 2 tuần thì lấy một nửa), và yêu cầu cả nhóm ngồi đủ 4 giờ kể cả khi đã chốt xong kế hoạch.
Kết quả: sau 3 Sprint, nhóm 6 người than phiền mệt mỏi. Có buổi họ chốt xong Sprint Goal và Sprint Backlog trong 90 phút, nhưng vẫn phải "ngồi cho hết giờ", dẫn đến những cuộc tranh luận lan man về chi tiết kỹ thuật mà lẽ ra để dành cho Refinement.
Diễn giải: Hùng đã hiểu sai bản chất timebox. 4 giờ là trần, không phải sàn. Khi nhóm đã đạt mục đích của Sprint Planning — có Sprint Goal, có Sprint Backlog, mọi người hiểu phải làm gì — thì sự kiện kết thúc, dù mới hết 90 phút.
Bài học rút ra: Timebox bảo vệ nhóm khỏi họp quá lâu, nó không ép nhóm họp đủ lâu. Trong đề PSM I, hãy luôn dịch "timebox" thành "tối đa", và cảnh giác với mọi đáp án dùng từ "must", "exactly", hay "always lasts".
Tình huống 2 — Startup fintech Singapore và Daily Scrum 15 phút
Một startup fintech ở Singapore (đội ngũ phân tán giữa Singapore và Đà Nẵng) chạy Sprint 3 tuần. Nhóm 9 Developer, Product Owner ở Singapore, Scrum Master ở Đà Nẵng. Daily Scrum diễn ra qua video lúc 9h30 sáng.
Vấn đề: vì nhóm đông và phân tán, Daily Scrum thường kéo dài 35–40 phút, biến thành buổi báo cáo trạng thái cho Scrum Master, rồi sa đà vào giải quyết vấn đề kỹ thuật ngay tại chỗ. Một Developer hỏi: "Nhóm mình đông nên Daily Scrum được phép 30 phút đúng không?"
Diễn giải: Không. Daily Scrum luôn là tối đa 15 phút, bất kể nhóm bao nhiêu người hay Sprint dài bao nhiêu. Mục đích của nó là để Developer kiểm tra tiến độ hướng tới Sprint Goal và điều chỉnh kế hoạch cho ngày tới — không phải để báo cáo, không phải để giải bài toán kỹ thuật. Khi một vấn đề cần thảo luận sâu xuất hiện, nhóm ghi nhận và hẹn nhau lại sau Daily Scrum (một số người gọi là "after-party"), để 15 phút giữ đúng nhịp.
Bài học rút ra: 15 phút là con số "thép" của Daily Scrum. Đề thi rất hay đưa bẫy "nhóm lớn nên cần thêm thời gian" — đáp án by-the-book vẫn là 15 phút; nếu Daily Scrum thường xuyên vượt giờ, đó là dấu hiệu nhóm đang dùng sai mục đích sự kiện.
Tình huống 3 — Agency phần mềm Hà Nội và "khoảng nghỉ giữa Sprint"
Một agency phần mềm ở Hà Nội làm outsourcing cho khách Nhật, chạy Sprint 2 tuần. Trưởng nhóm quyết định: sau mỗi Sprint, dành 2 ngày "đệm" để nhóm nghỉ ngơi, dọn dẹp kỹ thuật, và "chuẩn bị cho Sprint sau" trước khi Sprint mới bắt đầu.
Trong một buổi đánh giá nội bộ chuẩn bị thi PSM I, một thành viên đặt câu hỏi: "Việc chèn 2 ngày đệm giữa các Sprint có đúng Scrum không?"
Diễn giải: Theo Scrum Guide, một Sprint mới bắt đầu ngay sau khi Sprint trước kết thúc — không có khoảng nghỉ chính thức nào trong khung Scrum. Nếu nhóm cần thời gian dọn dẹp kỹ thuật hay chuẩn bị, công việc đó nên nằm bên trong Sprint (ví dụ là một phần của Sprint Backlog), chứ không phải một khoảng trống nằm ngoài framework. Việc tạo "ngày đệm" là một anti-pattern: nó phá vỡ nhịp đều đặn (cadence) và làm mờ trách nhiệm về Increment.
Bài học rút ra: Hãy nhớ hình ảnh các Sprint nối tiếp nhau liền mạch như các toa tàu — không có khoảng hở. Đây là một câu hỏi kinh điển trong PSM I.
Hướng dẫn từng bước
Để hệ thống hóa 5 sự kiện theo cách dễ nhớ và dễ áp dụng, hãy đi theo các bước sau:
Bước 1 — Vẽ "vật chứa" trước. Trên giấy, vẽ một hình chữ nhật lớn và ghi "Sprint (≤ 1 tháng)". Đây là container. Mọi sự kiện khác nằm bên trong.
Bước 2 — Đặt 4 sự kiện vào đúng vị trí thời gian. Bên trong hình chữ nhật, từ trái sang phải: Sprint Planning (đầu), Daily Scrum (lặp lại mỗi ngày, vẽ thành chuỗi dấu chấm), Sprint Review (gần cuối), Sprint Retrospective (cuối cùng).
Bước 3 — Gắn timebox cho Sprint 1 tháng. Ghi cạnh mỗi sự kiện: Planning 8h, Daily 15 phút, Review 4h, Retro 3h. Mẹo nhớ: dãy 8 – 4 – 3 giảm dần, và Daily luôn 15 phút tách riêng.
Bước 4 — Gắn cặp Inspect/Adapt cho từng sự kiện. Tự hỏi với mỗi sự kiện: "Mình đang nhìn vào cái gì?" (inspect) và "Mình điều chỉnh cái gì?" (adapt). Ví dụ Daily Scrum: nhìn vào tiến độ tới Sprint Goal → điều chỉnh kế hoạch ngày mai.
Bước 5 — Quy đổi timebox cho Sprint ngắn hơn. Tập phản xạ: nếu đề nói "Sprint 2 tuần", thì Planning ≤ 4h, Review ≤ 2h, Retro ngắn hơn tương ứng — nhưng Daily vẫn 15 phút. Đừng học cứng con số, hãy hiểu nguyên tắc "co giãn theo độ dài Sprint, trừ Daily".
Bước 6 — Kiểm tra tính liền mạch. Tự nhắc: Sprint kế tiếp bắt đầu ngay khi Sprint này kết thúc. Không khoảng nghỉ.
Lỗi thường gặp & mẹo
Lỗi 1 — Quên rằng Sprint cũng là một sự kiện. Nhiều người đếm "4 events" vì chỉ tính 4 cuộc họp. Đáp án đúng là 5 sự kiện, trong đó Sprint là container.
Lỗi 2 — Hiểu timebox là thời lượng cố định. Timebox luôn là tối đa. Cảnh giác với các đáp án chứa "must last", "exactly", "always takes the full".
Lỗi 3 — Cho rằng Daily Scrum co giãn theo độ dài Sprint. Sai. Daily Scrum luôn 15 phút, không phụ thuộc độ dài Sprint hay số người.
Lỗi 4 — Đảo thứ tự Review và Retrospective. Review (kiểm tra sản phẩm) đứng trước Retrospective (kiểm tra quy trình). Đừng đảo.
Lỗi 5 — Tin rằng có khoảng nghỉ giữa các Sprint. Không. Sprint mới bắt đầu ngay khi Sprint cũ kết thúc.
Lỗi 6 — Lẫn lộn "đối tượng inspect" của Daily Scrum và Sprint Review. Daily Scrum inspect tiến độ tới Sprint Goal (do Developer thực hiện, nội bộ). Sprint Review inspect Increment và bối cảnh sản phẩm (có sự tham gia của stakeholders). Đây là điểm dễ nhầm và bài 57 sẽ đào sâu hơn về sự khác biệt giữa các điểm inspect.
Mẹo nhớ con số: "1 – 8 – 15 – 4 – 3". Đọc là: Sprint 1 tháng, Planning 8 giờ, Daily 15 phút, Review 4 giờ, Retro 3 giờ. Đây là bộ số cho Sprint dài nhất (1 tháng); mọi con số khác nhỏ hơn đều hợp lệ.
Mẹo làm bài: Khi gặp câu hỏi về timebox, bước đầu tiên luôn là xác định "đề đang nói Sprint dài bao nhiêu?". Nếu đề không nói rõ, thường ngầm hiểu là Sprint 1 tháng — dùng bộ số chuẩn 8/15/4/3.
Bài tập thực hành
- Vẽ lại bảng tổng hợp từ trí nhớ. Không nhìn tài liệu, hãy tự vẽ bảng 5 sự kiện với 4 cột: Sự kiện — Timebox (Sprint 1 tháng) — Inspect — Adapt. Sau đó đối chiếu với bảng trong bài. Lặp lại đến khi điền đúng 100% mà không cần nhìn.
- Quy đổi timebox. Một nhóm chạy Sprint 2 tuần. Hãy ước lượng timebox tối đa hợp lý cho Sprint Planning, Sprint Review, Sprint Retrospective, và Daily Scrum. (Gợi ý: con nào co giãn, con nào cố định?)
- Tìm lỗi trong phát biểu. Với mỗi câu sau, xác định Đúng/Sai và giải thích:
- Tình huống ứng dụng. Nhóm của bạn liên tục để Daily Scrum kéo dài 30 phút vì hay sa vào giải quyết vấn đề kỹ thuật. Với vai Scrum Master, bạn sẽ làm gì để giữ đúng timebox mà không bỏ qua các vấn đề đó? (Gợi ý: nghĩ về mục đích thật sự của Daily Scrum và khái niệm "after-party".)
- Tự kiểm tra logic inspect & adapt. Với từng sự kiện, viết một câu theo mẫu: "Trong [sự kiện], chúng tôi kiểm tra [X] để điều chỉnh [Y]." Năm câu, năm sự kiện.
Tóm tắt
- Scrum có đúng 5 sự kiện: Sprint (container) chứa Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
- Tất cả sự kiện đều là cơ hội inspect & adapt — đây là biểu hiện cụ thể của chủ nghĩa thực nghiệm trong Scrum.
- Timebox cho Sprint 1 tháng: Sprint ≤ 1 tháng, Planning ≤ 8h, Daily Scrum 15 phút (cố định), Review ≤ 4h, Retrospective ≤ 3h. Bộ số nhớ nhanh: 1 – 8 – 15 – 4 – 3.
- Timebox là tối đa, không phải cố định. Với Sprint ngắn hơn, các timebox (trừ Daily Scrum) co giãn nhỏ lại tương ứng.
- Thứ tự: Planning → (Daily Scrum lặp lại) → Review → Retrospective. Review luôn trước Retrospective.
- Không có khoảng nghỉ giữa các Sprint: Sprint mới bắt đầu ngay khi Sprint trước kết thúc.
- Mỗi sự kiện có cặp inspect/adapt riêng — hiểu được cặp này là chìa khóa để trả lời đúng các câu hỏi "by the book" trong PSM I.