Mở đầu — vì sao bài này quan trọng
Nếu bạn chỉ được phép nhớ một thứ duy nhất về cấu trúc Scrum để đi thi PSM I, thì đó nên là Sprint. Vì Sprint không phải là "một event ngang hàng" với những event khác — nó là container event, là chiếc hộp chứa đựng tất cả mọi thứ. Scrum Guide 2020 gọi Sprint là "the heartbeat of Scrum" — nhịp tim của Scrum. Mỗi nhịp đập của Sprint biến ý tưởng thành giá trị (turn ideas into value).
Tại sao mentor lại nhấn mạnh chuyện này ngay từ đầu? Bởi vì rất nhiều câu hỏi trong đề thi PSM I được thiết kế để kiểm tra xem bạn có thực sự hiểu mối quan hệ "lồng nhau" giữa Sprint và bốn event còn lại hay không. Người mới học thường mặc định Scrum có "5 event ngang hàng": Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective. Cách hiểu này khiến bạn trả lời sai một loạt câu hỏi dạng "Khi nào Sprint kết thúc?", "Có khoảng nghỉ giữa hai Sprint không?", hay "Ai có thể hủy Sprint?".
Sự thật là: bốn event kia nằm bên trong Sprint. Sprint là khung thời gian bao trùm, còn các event khác là những điểm inspect-and-adapt diễn ra bên trong khung đó. Hiểu sai điều này, bạn sẽ trượt những câu mà lẽ ra phải lấy điểm dễ. Hiểu đúng, bạn có một "la bàn" để suy luận hàng chục câu hỏi khác về timing và cấu trúc.
Bài này sẽ tập trung chỉ riêng vào Sprint với vai trò container — đặc tính, quy tắc và những hệ quả thực tế của nó. Các event con (Planning, Daily, Review, Retro) sẽ được mổ xẻ chi tiết ở những bài sau, nên ở đây mentor cố ý không đi sâu vào chúng.
Khái niệm cốt lõi
Sprint là gì
Theo Scrum Guide 2020: "Sprints are the heartbeat of Scrum, where ideas are turned into value." Sprint là một sự kiện có độ dài cố định, kéo dài một tháng hoặc ngắn hơn (one month or less), để tạo ra sự nhất quán. Một Sprint mới bắt đầu ngay lập tức sau khi Sprint trước kết thúc — không có khoảng trống, không có "tuần nghỉ giữa hai Sprint".
Điểm mấu chốt cần khắc cốt ghi tâm: mọi công việc cần thiết để đạt được Product Goal — bao gồm Sprint Planning, Daily Scrum, Sprint Review, và Sprint Retrospective — đều diễn ra bên trong Sprint. Đó chính là ý nghĩa của từ "container". Sprint không phải một giai đoạn lập kế hoạch hay một giai đoạn code; nó là chiếc hộp chứa toàn bộ một chu kỳ làm việc trọn vẹn.
Sprint là container — bức tranh lồng nhau
Hãy hình dung như những chiếc hộp Nga (matryoshka). Hộp lớn nhất là Sprint. Bên trong Sprint, theo thứ tự thời gian:
- Sprint Planning mở màn (khởi động Sprint).
- Daily Scrum lặp lại mỗi ngày làm việc.
- Công việc phát triển (development work) diễn ra liên tục suốt Sprint.
- Sprint Review gần cuối Sprint.
- Sprint Retrospective khép lại Sprint (là event cuối cùng).
Đặc tính của Sprint
1. Độ dài cố định (fixed length). Sprint kéo dài tối đa một tháng. Khi đã chọn độ dài (ví dụ 2 tuần), team giữ nguyên độ dài đó qua các Sprint để tạo nhịp điệu và sự nhất quán. Sprint ngắn hơn nghĩa là chu kỳ học hỏi (learning cycle) ngắn hơn, ít rủi ro hơn, vì bạn giới hạn rủi ro chỉ trong một Sprout chi phí. Scrum Guide nói: "Short Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame."
2. Không kéo dài timebox. Đây là quy tắc thép. Sprint một khi đã bắt đầu thì độ dài cố định, không bao giờ được gia hạn. Nếu công việc chưa xong khi hết timebox, Sprint vẫn kết thúc — phần chưa xong quay lại Product Backlog. Bạn không "cộng thêm 3 ngày cho xong".
3. Một Sprint mới bắt đầu ngay sau Sprint trước. Không có gap.
4. Trong Sprint, có những ràng buộc để bảo vệ Sprint Goal:
- Không thay đổi nào được làm nếu nó gây nguy hiểm cho Sprint Goal (No changes are made that would endanger the Sprint Goal).
- Chất lượng không bị giảm (Quality does not decrease).
- Product Backlog được refine khi cần.
- Phạm vi (scope) có thể được làm rõ và thương lượng lại (re-negotiated) với Product Owner khi hiểu biết tăng lên.
Sprint giúp dự đoán và kiểm soát rủi ro
Mỗi Sprint có thể được xem như một dự án ngắn (short project) — nó cho phép áp dụng empiricism một cách đều đặn. Vì độ dài cố định, đến cuối mỗi Sprint bạn luôn có một điểm dừng để inspect (qua Review và Retrospective) và adapt. Khi một Sprint dài hơn một tháng, định nghĩa về cái đang được xây dựng có thể thay đổi, độ phức tạp tăng, và rủi ro tăng theo. Đó là lý do giới hạn "một tháng hoặc ngắn hơn" tồn tại.
Ai có thể hủy Sprint (Sprint Cancellation)
Một Sprint có thể bị hủy nếu Sprint Goal trở nên lỗi thời (obsolete). Chỉ Product Owner mới có quyền hủy Sprint. Đây là một điểm thuộc về Sprint nên mentor nhắc ở đây, nhưng cơ chế chi tiết (chuyện gì xảy ra với công việc dở dang, tần suất...) sẽ được mổ xẻ riêng ở Bài 36. Ở Bài 12, bạn chỉ cần nhớ: hủy Sprint là chuyện hiếm, và quyền đó thuộc về Product Owner.
Tình huống thực tế
Ví dụ 1 — Tiki và cái bẫy "gia hạn Sprint cho xong"
Giả định một squad tại Tiki (sàn thương mại điện tử Việt Nam) chạy Sprint 2 tuần để xây tính năng "giỏ hàng chia sẻ" cho mùa sale 11/11. Còn 2 ngày nữa hết Sprint, Developers nhận ra phần tích hợp thanh toán chưa xong. Một bạn đề xuất: "Hay mình gia hạn Sprint thêm 3 ngày cho xong rồi Review luôn thể?"
Diễn giải: Đề xuất này nghe rất hợp lý về mặt con người, nhưng nó vi phạm bản chất của Sprint như một container có độ dài cố định. Nếu gia hạn, bạn phá vỡ nhịp tim (heartbeat) đều đặn, làm hỏng khả năng dự báo, và quan trọng nhất là che giấu vấn đề thay vì phơi bày nó (transparency bị tổn hại). Cái đúng là: Sprint vẫn kết thúc đúng hạn. Phần thanh toán chưa hoàn thành thì không nằm trong Increment, nó quay lại Product Backlog để Product Owner sắp xếp lại độ ưu tiên. Tại Sprint Review, team trình bày những gì đã "Done" một cách trung thực.
Bài học: Sprint không bao giờ được gia hạn để "làm cho xong việc". Việc chưa xong là một tín hiệu — có thể team đã forecast quá nhiều, hoặc có impediment chưa được xử lý. Container giữ nguyên kích thước; chính sự cố định đó tạo ra áp lực lành mạnh để team học cách forecast tốt hơn ở Sprint sau.
Ví dụ 2 — Startup fintech tại Singapore và "tuần nghỉ giữa hai Sprint"
Một startup fintech ở Singapore (giả định tên Paywise, khoảng 25 kỹ sư, 3 Scrum Team) có thói quen: kết thúc Sprint vào chiều thứ Sáu, rồi dành nguyên ngày thứ Hai làm "cooldown day" — không thuộc Sprint nào, để mọi người dọn dẹp kỹ thuật, họp linh tinh, rồi thứ Ba mới Sprint Planning cho Sprint mới.
Một Scrum Master mới về phát hiện điều này và đặt câu hỏi: ngày thứ Hai đó thuộc về đâu?
Diễn giải: Theo Scrum Guide, một Sprint mới bắt đầu ngay lập tức sau khi Sprint trước kết thúc. Không có khái niệm "khoảng nghỉ giữa hai Sprint" trong Scrum chuẩn. Nếu công việc dọn dẹp kỹ thuật là cần thiết, nó nên là một phần công việc bên trong một Sprint (và lý tưởng là nằm trong Definition of Done). "Cooldown day" lơ lửng ngoài mọi Sprint tạo ra một vùng xám không được inspect, không được adapt, và không tạo ra giá trị có thể kiểm chứng.
Bài học: Đối với đề thi PSM I, câu trả lời "by the book" luôn là: không có gap giữa các Sprint. Trong thực tế, nếu một team cần thời gian cho công việc kỹ thuật, cách Scrum-đúng là đưa nó vào trong Sprint, không phải tạo một khoảng thời gian ngoài Sprint.
Ví dụ 3 — Agency tại TP.HCM chọn độ dài Sprint
Một agency phần mềm ở TP.HCM (giả định Saigon Digital, làm outsourcing cho khách Nhật) tranh luận nên chạy Sprint 4 tuần hay 2 tuần. Phía quản lý thích Sprint 4 tuần vì "ít họp hơn, đỡ mất thời gian". Khách hàng Nhật thì hay đổi yêu cầu và muốn thấy kết quả thường xuyên.
Diễn giải: Cả hai lựa chọn đều hợp lệ về mặt quy tắc (đều ≤ một tháng). Nhưng đây là lúc hiểu được vì sao Scrum giới hạn "một tháng hoặc ngắn hơn". Sprint càng dài, khoảng cách giữa các điểm inspect-and-adapt càng xa, rủi ro tích lũy càng lớn — đặc biệt khi khách hàng hay đổi yêu cầu. Sprint 2 tuần tạo ra nhiều learning cycle hơn (gấp đôi số lần Review để lấy phản hồi), giới hạn rủi ro chi phí trong một khung nhỏ hơn. Với một khách hàng biến động, Sprint ngắn gần như luôn là lựa chọn an toàn hơn.
Bài học: Độ dài Sprint không phải là chuyện "đỡ mất thời gian họp". Nó là một quyết định về quản lý rủi ro và tốc độ học hỏi. Sprint ngắn = phản hồi nhanh hơn, rủi ro thấp hơn, nhưng đòi hỏi kỷ luật cao hơn về việc giữ mọi thứ "Done" gọn gàng.
Hướng dẫn từng bước
Khi bạn ngồi trước một câu hỏi PSM I liên quan đến Sprint, hãy áp dụng quy trình suy luận sau:
- Xác định Sprint là container. Mỗi khi đề nhắc đến một event con (Planning, Daily, Review, Retro), tự nhắc mình: "Cái này nằm BÊN TRONG Sprint." Điều đó loại bỏ ngay những đáp án ngụ ý các event ngang hàng với Sprint.
- Kiểm tra quy tắc timebox. Nếu câu hỏi đề cập đến chuyện "kéo dài", "rút ngắn", "gia hạn" Sprint — nhớ: độ dài Sprint cố định, không kéo dài timebox. Việc chưa xong quay lại Product Backlog.
- Kiểm tra quy tắc "không gap". Nếu đáp án nào nói có khoảng nghỉ giữa các Sprint, gần như chắc chắn đó là đáp án sai. Sprint mới bắt đầu ngay sau Sprint cũ.
- Phân biệt Sprint Goal (bất biến) với scope (có thể thương lượng lại). Khi đề hỏi về thay đổi trong Sprint: Sprint Goal không bị đe dọa; nhưng scope có thể được làm rõ và re-negotiated giữa Developers và Product Owner. Chất lượng không giảm.
- Nhớ ai hủy được Sprint. Chỉ Product Owner, và chỉ khi Sprint Goal lỗi thời.
- Nhớ giới hạn một tháng. Mọi đáp án nói Sprint dài hơn một tháng đều sai.
Lỗi thường gặp & mẹo
Lỗi 1: Coi Sprint là một event ngang hàng với bốn event kia. Đây là hiểu nhầm phổ biến nhất. Hãy luôn nhớ hình ảnh chiếc hộp lồng nhau: Sprint bao bọc tất cả.
Lỗi 2: Nghĩ Sprint kết thúc khi Retrospective xong. Đúng là Retrospective là event con cuối cùng, nhưng cái kết thúc Sprint là hết timebox chứ không phải việc hoàn thành một event con. Sắc thái này nhỏ nhưng đề thi có thể khai thác.
Lỗi 3: Cho rằng có thể kéo dài Sprint khi việc chưa xong. Không bao giờ. Container có kích thước cố định.
Lỗi 4: Cho rằng Scrum Master hoặc team hủy được Sprint. Sai — chỉ Product Owner.
Lỗi 5: Lẫn lộn "Sprint Goal không đổi" với "không thay đổi gì trong Sprint". Trong Sprint vẫn có thể làm rõ và thương lượng lại scope, refine Product Backlog. Điều bị cấm là những thay đổi gây nguy hiểm cho Sprint Goal và việc giảm chất lượng.
Mẹo ghi nhớ: Lặp lại câu thần chú — "Sprint is the container; the heartbeat; one month or less; fixed length; no gaps; only the PO cancels." Sáu vế này gói gọn gần như mọi điểm về Sprint mà PSM I kiểm tra.
Mẹo loại trừ: Trong các câu trắc nghiệm, bất kỳ đáp án nào chứa các từ khóa "gia hạn Sprint", "khoảng nghỉ giữa các Sprint", "Sprint dài hơn một tháng", "Scrum Master hủy Sprint" thì gần như chắc chắn là bẫy.
Bài tập thực hành
Bài 1 — Đúng/Sai. Với mỗi phát biểu, ghi Đúng hoặc Sai và giải thích ngắn:
- (a) Sprint Planning, Daily Scrum, Sprint Review và Sprint Retrospective đều diễn ra bên trong Sprint.
- (b) Khi công việc chưa hoàn thành lúc hết timebox, team được phép gia hạn Sprint thêm vài ngày.
- (c) Giữa hai Sprint luôn có một khoảng nghỉ để team chuẩn bị.
- (d) Sprint có thể kéo dài hơn một tháng nếu công việc quá phức tạp.
- (e) Sprint Goal không được thay đổi, nhưng scope có thể được thương lượng lại với Product Owner.
Bài 3 — Áp dụng. Một công ty muốn chọn độ dài Sprint cho sản phẩm có yêu cầu thay đổi liên tục và rủi ro thị trường cao. Hãy viết 3–4 câu lập luận nên chọn Sprint ngắn (ví dụ 1–2 tuần) thay vì 4 tuần, dựa trên khái niệm learning cycle và risk limitation.
Gợi ý đáp án Bài 1: (a) Đúng — đó chính là ý nghĩa container. (b) Sai — không bao giờ kéo dài timebox; phần chưa xong quay lại Product Backlog. (c) Sai — Sprint mới bắt đầu ngay sau Sprint cũ. (d) Sai — tối đa một tháng. (e) Đúng — Sprint Goal bất biến, scope có thể re-negotiated.
Tóm tắt
Sprint là container event — nhịp tim của Scrum, nơi ý tưởng biến thành giá trị. Hãy khắc sâu sáu ý cốt lõi:
- Container: Mọi event con (Planning, Daily, Review, Retro) và toàn bộ công việc đều diễn ra bên trong Sprint. Sprint không ngang hàng với chúng — nó bao bọc chúng.
- Độ dài cố định, một tháng hoặc ngắn hơn: Tạo sự nhất quán và nhịp điệu. Không bao giờ kéo dài timebox.
- Không có gap: Sprint mới bắt đầu ngay khi Sprint cũ kết thúc.
- Sprint ngắn = nhiều learning cycle hơn, rủi ro thấp hơn: Đó là lý do giới hạn một tháng tồn tại.
- Trong Sprint: Sprint Goal không bị đe dọa, chất lượng không giảm, nhưng scope có thể được làm rõ và thương lượng lại với Product Owner; Product Backlog được refine khi cần.
- Chỉ Product Owner mới hủy được Sprint, và chỉ khi Sprint Goal lỗi thời.