Mở đầu — vì sao bài này quan trọng
Nếu coi Scrum như một cỗ máy tạo ra giá trị, thì Scrum Events (các sự kiện trong Scrum) chính là những nhịp đập điều hòa cả cỗ máy đó. Mọi quyết định quan trọng, mọi lần "dừng lại để nhìn nhận và điều chỉnh" đều xảy ra bên trong các sự kiện này. Không có chúng, đội nhóm sẽ làm việc trong sương mù: không biết khi nào nên kiểm tra tiến độ, khi nào nên thu thập phản hồi, khi nào nên cải tiến cách làm.
Với kỳ thi PSM I, đây là một trong những vùng kiến thức bị hỏi nhiều nhất và cũng dễ bị nhầm nhất. Đề thi rất thích "gài" những câu kiểu: Sprint có thể kéo dài bao lâu?, Ai có quyền hủy Sprint?, Nếu công việc xong sớm thì có được rút ngắn Sprint không?, Giữa hai Sprint có khoảng nghỉ không?. Người học thường trả lời theo "cảm giác thực tế ở công ty mình" — và đó chính xác là cái bẫy, bởi PSM I chấm theo Scrum Guide chứ không theo thói quen doanh nghiệp.
Trong bài này, chúng ta sẽ đi sâu vào 5 sự kiện của Scrum với trọng tâm đặc biệt là The Sprint — sự kiện "vỏ bọc" chứa tất cả những sự kiện còn lại. Tôi sẽ giúp bạn nắm được không chỉ "luật" mà cả "tinh thần" đằng sau từng quy tắc, vì PSM I kiểm tra cả hai. Lưu ý: bài này tập trung vào bản chất và quy tắc chung của các Events; phần đào sâu từng sự kiện riêng lẻ (Sprint Planning, Daily Scrum, Review, Retrospective) sẽ được mổ xẻ chi tiết ở các bài sau.
Khái niệm cốt lõi
Tại sao Scrum dùng "Events" thay vì "meetings"?
Scrum Guide cố tình gọi chúng là events (sự kiện) chứ không phải "meetings" (cuộc họp). Lý do rất tinh tế: từ "meeting" gợi cảm giác một việc làm thêm, một thứ "phải họp cho có". Còn "event" mang nghĩa một cơ hội chính thức, được định trước, để tạo ra sự minh bạch (transparency) và thực hiện inspect & adapt (kiểm tra và thích nghi).
Mỗi Event trong Scrum đều là một cơ hội chính thức để kiểm tra một thứ gì đó và điều chỉnh. Đây chính là biểu hiện cụ thể của thuyết thực nghiệm (empiricism) mà Scrum dựa trên. Nếu bạn tổ chức một sự kiện nhưng không có gì để inspect và cũng không điều chỉnh gì, thì đó là một sự kiện vô nghĩa, lãng phí thời gian.
Năm sự kiện và mối quan hệ "lồng nhau"
Scrum có đúng 5 sự kiện, và điều quan trọng nhất cần khắc vào đầu là: The Sprint là một container — nó chứa bốn sự kiện còn lại bên trong.
- The Sprint — sự kiện bao trùm (container event), độ dài cố định ≤ 1 tháng.
Hãy hình dung Sprint như một chiếc hộp thời gian. Bốn sự kiện kia nằm gọn bên trong chiếc hộp đó. Vì vậy, khi đề thi hỏi "Scrum có bao nhiêu events?", câu trả lời là 5, không phải 4 — vì bản thân Sprint cũng là một event.
Đặc tính chung của mọi Event: time-box
Tất cả các sự kiện đều có time-box — một giới hạn thời gian tối đa. Time-box giúp tránh lãng phí, tạo kỷ luật, và buộc đội nhóm tập trung. Một điểm hay bị nhầm: time-box là tối đa, không phải cố định cứng. Nếu Daily Scrum xong trong 10 phút thay vì 15 phút, hoàn toàn ổn — không cần "ngồi cho đủ giờ".
Ngoại lệ đáng chú ý chính là bản thân Sprint: độ dài Sprint là cố định (fixed) một khi đã chọn, không phải "tối đa". Một Sprint hai tuần thì luôn là hai tuần, không kết thúc sớm dù công việc xong sớm, và cũng không kéo dài thêm dù chưa xong.
The Sprint — trái tim của Scrum
Đây là phần trọng tâm của bài. Scrum Guide gọi Sprint là "the heartbeat of Scrum" — nhịp tim của Scrum. Mọi ý tưởng đều được biến thành giá trị bên trong Sprint. Hãy ghi nhớ các quy tắc cốt lõi sau, vì PSM I hỏi gần như nguyên văn:
1. Độ dài cố định, tối đa một tháng. Sprint kéo dài một tháng hoặc ngắn hơn (one month or less). Phổ biến nhất trong thực tế là 2 tuần. Lý do giới hạn ≤ 1 tháng: nếu Sprint quá dài, Sprint Goal có thể mất giá trị, độ phức tạp tăng, và rủi ro tích lũy lớn — vi phạm tinh thần kiểm soát rủi ro của empiricism.
2. Không có khoảng trống giữa các Sprint. Ngay khi một Sprint kết thúc, Sprint tiếp theo bắt đầu ngay lập tức (a new Sprint starts immediately after the conclusion of the previous Sprint). Không có "tuần nghỉ giữa Sprint", không có "buffer week". Đây là câu bẫy kinh điển trong đề thi.
3. Sprint Goal không thay đổi trong Sprint. Một khi Sprint đã bắt đầu và Sprint Goal đã được thiết lập, mục tiêu này không đổi. Phạm vi (scope) có thể được làm rõ và thương lượng lại giữa Product Owner và Developers khi hiểu biết tăng lên — nhưng Sprint Goal thì giữ nguyên. Đây là điểm phân biệt rất quan trọng: scope linh hoạt, Sprint Goal cố định.
4. Chất lượng không giảm. Trong Sprint, chất lượng (quality) không được phép giảm xuống. Definition of Done bảo vệ chất lượng và không bị nới lỏng để "kịp deadline". (DoD sẽ được mổ xẻ ở Bài 20.)
5. Phạm vi có thể được làm rõ và thương lượng lại. Khi Developers học được nhiều hơn về công việc, họ và Product Owner có thể đàm phán lại scope — thêm bớt, làm rõ các Product Backlog Item — miễn không phá vỡ Sprint Goal.
6. Ai có thể hủy Sprint? Chỉ Product Owner có quyền hủy (cancel) một Sprint, và chỉ khi Sprint Goal trở nên lỗi thời. (Chi tiết về hủy Sprint ở Bài 36.) Đây cũng là một câu hỏi rất hay xuất hiện.
Sprint tạo ra sự đều đặn (regularity)
Vì Sprint có độ dài cố định và nối tiếp nhau không nghỉ, nó tạo ra một nhịp điệu đều đặn. Sự đều đặn này giúp giảm độ phức tạp trong việc lập kế hoạch, và làm cho các sự kiện inspect & adapt trở nên đáng tin cậy. Bạn luôn biết: cứ hai tuần lại có một Review, một Retrospective. Tính dự đoán được này là một giá trị, không phải sự cứng nhắc.
Tình huống thực tế
Tình huống 1 — Tiki và cái bẫy "tuần nghỉ giữa Sprint"
Một đội phát triển tính năng thanh toán tại một sàn thương mại điện tử lớn ở Việt Nam (giả định theo mô hình Tiki) chạy Sprint 2 tuần. Sau mỗi Sprint, quản lý kỹ thuật quyết định thêm một tuần "hardening" để sửa bug và nghỉ ngơi trước khi bắt đầu Sprint mới. Nhịp thực tế trở thành: 2 tuần làm — 1 tuần nghỉ — 2 tuần làm.
Diễn giải: Đây là vi phạm trực tiếp quy tắc "không có khoảng trống giữa các Sprint". Cái "tuần hardening" đó thực chất là dấu hiệu cho thấy Definition of Done của đội chưa đủ chặt — công việc trong Sprint chưa thực sự "Done" nên mới cần một tuần dọn dẹp. Đúng theo Scrum, công việc sửa bug và đảm bảo chất lượng phải nằm bên trong Sprint, được bảo vệ bởi DoD.
Bài học rút ra: Nếu bạn thấy đội mình cần một "buffer week", đừng coi đó là giải pháp — hãy coi đó là triệu chứng. Trong PSM I, mọi đáp án kiểu "thêm tuần nghỉ giữa các Sprint" gần như luôn sai.
Tình huống 2 — Startup fintech Singapore và việc "rút ngắn Sprint vì xong sớm"
Một startup fintech ở Singapore có đội 6 developer chạy Sprint 2 tuần. Đến ngày thứ 7, đội hoàn thành toàn bộ công việc đã forecast và đạt Sprint Goal. Product Owner đề xuất: "Xong rồi thì kết thúc Sprint luôn hôm nay, làm Review và Retro sớm, mai bắt đầu Sprint mới."
Diễn giải: Việc hoàn thành công việc sớm không cho phép kết thúc Sprint sớm, vì độ dài Sprint là cố định. Tuy nhiên, tình huống này hé lộ điều thú vị: nếu đội thường xuyên xong sớm, có lẽ họ đã forecast quá ít công việc, hoặc Sprint đang dài hơn mức cần thiết. Cách xử lý đúng tinh thần Scrum: kéo thêm Product Backlog Item phù hợp với Sprint Goal (thương lượng scope với PO) để tận dụng thời gian còn lại, và đưa quan sát "hay xong sớm" vào Retrospective để cân nhắc điều chỉnh độ dài Sprint cho các chu kỳ sau.
Ngược lại, lưu ý quyền hủy Sprint hoàn toàn khác với "kết thúc sớm vì xong việc": chỉ PO hủy, và chỉ khi Sprint Goal lỗi thời — không phải vì đã hoàn thành.
Bài học rút ra: "Xong sớm" thì thêm việc hợp mục tiêu, không rút ngắn hộp thời gian. Trong đề thi, nếu thấy đáp án "kết thúc Sprint sớm vì đã hoàn thành công việc", hãy cảnh giác — gần như chắc chắn sai.
Tình huống 3 — Đội outsourcing tại Hà Nội và sức ép đổi Sprint Goal giữa chừng
Một đội gia công phần mềm ở Hà Nội đang ở giữa Sprint với Sprint Goal là "ra mắt luồng đăng nhập bằng số điện thoại". Đến ngày thứ 6, khách hàng nước ngoài gọi điện yêu cầu "đổi ưu tiên, làm tính năng quét QR thanh toán ngay trong Sprint này thay vì đăng nhập."
Diễn giải: Sprint Goal không thay đổi trong Sprint. Vậy đội xử lý sao? Có hai con đường đúng: (a) Product Owner đưa yêu cầu mới vào Product Backlog và sắp xếp ưu tiên cho Sprint kế tiếp; hoặc (b) nếu yêu cầu QR khẩn cấp đến mức làm cho Sprint Goal hiện tại trở nên vô nghĩa, thì PO có quyền hủy Sprint và lập kế hoạch lại từ đầu với Sprint Planning mới. Điều không được làm là âm thầm "nhét" tính năng QR vào và vẫn giữ nguyên Sprint Goal đăng nhập — như thế là phá vỡ trọng tâm và sự minh bạch.
Cần phân biệt rõ: làm rõ và thương lượng lại scope (được phép) khác với đổi Sprint Goal (không được phép). Thêm vài chi tiết nhỏ cho luồng đăng nhập thì ổn; thay nguyên mục tiêu sang QR thì không.
Bài học rút ra: Scrum Master ở đây đóng vai trò "lá chắn", giúp cả khách hàng lẫn đội hiểu rằng tính ổn định của Sprint Goal chính là thứ bảo vệ năng suất. Cơ chế đúng để xử lý thay đổi gấp là hủy Sprint (do PO quyết), chứ không phải lén đổi mục tiêu.
Hướng dẫn từng bước
Đây là cách bạn áp dụng kiến thức về Scrum Events vào một chu kỳ Sprint thực tế, theo đúng trình tự:
- Chọn độ dài Sprint và giữ cố định. Quyết định một độ dài (thường 1–4 tuần, phổ biến nhất là 2 tuần), rồi cam kết giữ ổn định qua các Sprint để tạo nhịp điệu đều đặn. Không đổi độ dài liên tục.
- Mở Sprint bằng Sprint Planning. Sprint chính thức bắt đầu khi Sprint Planning diễn ra. Đây là nơi Sprint Goal được hình thành. (Chi tiết ở Bài 13.)
- Duy trì nhịp Daily Scrum mỗi ngày làm việc. Mỗi ngày, Developers inspect tiến độ hướng tới Sprint Goal và điều chỉnh kế hoạch cho ngày tiếp theo. (Chi tiết ở Bài 14.)
- Bảo vệ Sprint Goal và chất lượng suốt Sprint. Khi có yêu cầu thay đổi, hỏi: Điều này có làm hỏng Sprint Goal không? Nếu không — thương lượng scope với PO. Nếu có và yêu cầu là khẩn thiết — đó là vùng cân nhắc hủy Sprint (chỉ PO quyết).
- Tổ chức Sprint Review gần cuối Sprint. Đội và stakeholders inspect Increment và điều chỉnh Product Backlog. (Chi tiết ở Bài 15.)
- Kết thúc bằng Sprint Retrospective. Đây là sự kiện cuối cùng của Sprint — đội inspect chính cách làm việc của mình để cải tiến. (Chi tiết ở Bài 16.)
- Bắt đầu Sprint mới ngay lập tức. Không nghỉ, không buffer. Sprint Planning của chu kỳ mới diễn ra ngay sau Retrospective.
Lỗi thường gặp & mẹo
- Nhầm 4 events thay vì 5. Luôn nhớ: The Sprint cũng là một event (và là container chứa 4 cái còn lại). Đáp án đúng cho "có mấy events" là 5.
- Tưởng có khoảng nghỉ giữa các Sprint. Sai. Sprint mới bắt đầu ngay sau khi Sprint cũ kết thúc. Mọi "tuần nghỉ", "tuần hardening", "buffer" đều vi phạm.
- Tưởng xong sớm thì kết thúc Sprint sớm. Sai. Độ dài Sprint cố định. Xong sớm thì thêm việc hợp Sprint Goal, không rút ngắn hộp thời gian.
- Nhầm "đổi Sprint Goal" với "thương lượng scope". Sprint Goal không đổi; scope thì có thể được làm rõ và đàm phán lại giữa PO và Developers. Đây là điểm cực kỳ hay bị gài.
- Tưởng Scrum Master hoặc cả đội có quyền hủy Sprint. Sai. Chỉ Product Owner có quyền hủy Sprint.
- Hiểu time-box là thời lượng cố định cứng. Với 4 sự kiện con, time-box là tối đa — xong sớm thì kết thúc, không cần ngồi cho đủ giờ. Riêng độ dài Sprint mới là cố định.
- Nghĩ "giảm chất lượng để kịp deadline" là chấp nhận được. Sai. Chất lượng (qua Definition of Done) không được giảm trong Sprint.
Bài tập thực hành
- Liệt kê từ trí nhớ: Viết ra 5 sự kiện của Scrum, đánh dấu sự kiện nào là container và sự kiện nào nằm bên trong. Ghi rõ sự kiện nào mở đầu và sự kiện nào kết thúc một Sprint.
- Phân loại tình huống: Với mỗi tình huống dưới đây, ghi "Được phép" hay "Vi phạm Scrum" và giải thích một câu:
- Tình huống ra quyết định: Đội bạn chạy Sprint 3 tuần nhưng thường xuyên xong việc sau 2 tuần. Hãy đề xuất hai hành động đúng tinh thần Scrum để xử lý, và chỉ rõ sự kiện nào là nơi phù hợp để bàn về việc điều chỉnh độ dài Sprint.
- Tự kiểm tra "by the book": Trả lời nhanh: Ai có quyền hủy Sprint? Độ dài tối đa của một Sprint? Giữa hai Sprint có khoảng nghỉ không? Sprint Goal có thể đổi giữa Sprint không?
Tóm tắt
- Scrum có 5 events: The Sprint (container) chứa Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
- The Sprint là trái tim của Scrum — mọi giá trị được tạo ra bên trong nó.
- Sprint có độ dài cố định, tối đa 1 tháng; phổ biến nhất là 2 tuần.
- Không có khoảng trống giữa các Sprint — Sprint mới bắt đầu ngay khi Sprint cũ kết thúc.
- Sprint Goal không đổi trong Sprint; nhưng scope có thể được làm rõ và thương lượng lại giữa PO và Developers.
- Chất lượng không giảm — Definition of Done không bị nới lỏng.
- Chỉ Product Owner có quyền hủy Sprint, khi Sprint Goal trở nên lỗi thời.
- Mỗi event là một cơ hội chính thức để inspect & adapt — biểu hiện cụ thể của empiricism.