Mở đầu — vì sao bài này quan trọng
Trong Scrum Guide, có một câu rất ngắn nhưng lại là một trong những điểm dễ bị hiểu sai nhất trong đề thi PSPO I: "A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint." Nghĩa là: một Sprint có thể bị hủy nếu Sprint Goal trở nên lỗi thời, và chỉ Product Owner mới có thẩm quyền hủy Sprint.
Đây là một trong số rất ít quyền lực mang tính "tuyệt đối" mà Scrum trao riêng cho Product Owner. Trong toàn bộ framework, PO không phải là người ra lệnh cho Developers, không quyết định kỹ thuật, không ấn định ai làm việc gì. Nhưng riêng quyết định "dừng cả Sprint này lại" thì không ai khác — kể cả Scrum Master, kể cả sếp, kể cả Developers — được phép thay PO làm điều đó.
Tại sao bài này quan trọng với kỳ thi PSPO I? Vì câu hỏi về cancel Sprint gần như chắc chắn xuất hiện, và nó được thiết kế để bẫy những người học vẹt. Người ra đề sẽ đưa ra các phương án như "Scrum Master cancel", "Team biểu quyết cancel", "Stakeholder yêu cầu nên cancel" — tất cả đều SAI. Họ cũng bẫy bạn ở chỗ "khi nào thì nên cancel": nhiều người tưởng cứ Sprint trục trặc, tiến độ chậm, hay phát hiện estimate sai là cancel. Hoàn toàn không phải vậy.
Quan trọng hơn cả thi cử: hiểu đúng về cancel Sprint giúp bạn — với tư cách một PO thực thụ — biết khi nào nên dùng "nút dừng khẩn cấp" này, và quan trọng không kém, khi nào không nên dùng nó dù bị áp lực rất lớn. Cancel Sprint là một sự kiện hiếm, tốn kém và gây xáo trộn. Một PO giỏi hiểu rằng nó là vũ khí cuối cùng, không phải công cụ quản lý hằng ngày.
Khái niệm cốt lõi
Cancel Sprint là gì?
Cancel Sprint nghĩa là chấm dứt một Sprint trước khi hết timebox. Bình thường một Sprint kết thúc khi hết khoảng thời gian đã ấn định (ví dụ 2 tuần), bất kể công việc đã xong hay chưa. Cancel là trường hợp ngoại lệ: Sprint bị "khai tử" giữa chừng.
Khi một Sprint bị hủy, mọi Product Backlog Item đã hoàn thành (đạt Definition of Done) sẽ được xem xét. Nếu phần đã hoàn thành có giá trị, PO thường chấp nhận (accept) nó. Phần công việc chưa hoàn thành sẽ được đưa trở lại Product Backlog (re-estimate, re-order) để cân nhắc cho các Sprint sau.
Ai có quyền? — Chỉ Product Owner
Đây là phần phải khắc cốt ghi tâm: Only the Product Owner has the authority to cancel the Sprint. Không phải "Product Owner và Scrum Master", không phải "cả Scrum Team biểu quyết", không phải "quản lý cấp cao". Chỉ một mình PO.
Tại sao Scrum trao quyền này riêng cho PO? Vì PO là người chịu trách nhiệm tối đa hóa giá trị (maximizing value) và là người duy nhất nắm bức tranh tổng thể về giá trị sản phẩm, thị trường, và mục tiêu kinh doanh. Sprint Goal là cam kết về giá trị mà PO bảo vệ. Khi giá trị đó không còn nữa, người hiểu rõ điều này nhất — và có thẩm quyền điều chỉnh hướng đi của sản phẩm — chính là PO.
Tất nhiên, trên thực tế PO thường bị ảnh hưởng bởi nhiều bên. Stakeholder có thể báo "thị trường thay đổi rồi". Developers có thể nói "Sprint Goal này giờ vô nghĩa rồi anh ơi". Scrum Master có thể tư vấn. Nhưng tất cả những điều đó chỉ là đầu vào (influence). Quyết định cuối cùng và chữ ký vẫn thuộc về PO. Trong đề thi, hãy phân biệt rõ "ai có thể đề xuất" với "ai có thẩm quyền quyết định".
Khi nào cancel? — Khi Sprint Goal trở nên obsolete
Lý do duy nhất, chính thống mà Scrum Guide nêu ra để cancel một Sprint là: Sprint Goal becomes obsolete — Sprint Goal trở nên lỗi thời, vô nghĩa, không còn đáng theo đuổi.
Sprint Goal trở nên obsolete khi nào? Một vài tình huống điển hình:
- Thị trường thay đổi đột ngột: một đối thủ ra mắt tính năng làm Sprint Goal của bạn mất ý nghĩa cạnh tranh.
- Công ty đổi chiến lược hoặc đổi định hướng (pivot): lãnh đạo quyết định xoay sang phân khúc khách hàng khác, dòng sản phẩm bạn đang xây không còn được ưu tiên.
- Thay đổi pháp lý / chính sách: một quy định mới khiến tính năng đang làm trở nên không hợp pháp hoặc không cần thiết.
- Công nghệ hoặc giả định nền tảng sụp đổ: ví dụ nhà cung cấp API bên thứ ba mà cả Sprint Goal dựa vào bất ngờ ngừng dịch vụ.
Cancel hiếm khi xảy ra và rất tốn kém
Scrum Guide nhấn mạnh: Sprint cancellation thường gây xáo trộn (disruptive) và rất hiếm xảy ra. Đây là điểm bẫy quan trọng. Vì Sprint vốn đã ngắn (tối đa 1 tháng, thường 1–2 tuần), nên trong đa số trường hợp, nếu Sprint Goal vừa mới trở nên obsolete, PO chỉ cần... đợi vài ngày nữa là Sprint kết thúc tự nhiên rồi điều chỉnh ở Sprint Planning tiếp theo. Cancel chỉ thực sự đáng làm khi thời gian còn lại đủ dài để việc "ngồi đợi hết Sprint" gây lãng phí đáng kể.
Phân biệt: cancel KHÔNG phải để xử lý các vấn đề sau
Đây là loạt tình huống mà nhiều người nhầm là lý do cancel, nhưng thực ra KHÔNG phải:
- Developers ước lượng sai, không kịp hoàn thành scope: đây là chuyện bình thường trong Scrum. Sprint vẫn chạy hết timebox; phần chưa xong quay lại Backlog. Không cancel.
- Một số PBI bị block kỹ thuật: Team adapt, đổi sang việc khác hướng tới Sprint Goal. Không cancel.
- Stakeholder muốn thêm việc gấp vào giữa Sprint: PO thương lượng, đưa vào Backlog hoặc Sprint sau. Không cancel.
- Sprint Goal vẫn còn giá trị nhưng khó đạt: vẫn theo đuổi, có thể thu hẹp scope (negotiate scope) với Developers. Không cancel.
Tình huống thực tế
Tình huống 1 — Fintech tại TP.HCM và một thay đổi pháp lý qua đêm
Một công ty fintech ở TP.HCM (tạm gọi là VietPay) đang chạy một Sprint 2 tuần với Sprint Goal: "Cho phép người dùng nạp tiền vào ví điện tử bằng thẻ tín dụng quốc tế từ luồng đăng ký mới." Đây là tính năng được kỳ vọng tăng 20% tỷ lệ nạp tiền lần đầu.
Đến ngày thứ 3 của Sprint, Ngân hàng Nhà nước ban hành một hướng dẫn mới siết chặt việc liên kết thẻ quốc tế với ví điện tử cho tài khoản chưa định danh đầy đủ (eKYC). Toàn bộ luồng mà Sprint Goal đang xây dựng trở nên không được phép triển khai. Pháp chế xác nhận: nếu làm xong cũng không thể bật cho người dùng.
Chị Lan — Product Owner — họp nhanh với Scrum Master, pháp chế và Developers. Developers cho biết họ đã hoàn thành phần backend tách biệt (module mã hóa thông tin thẻ) đạt Definition of Done, nhưng phần luồng UI nạp tiền — trái tim của Sprint Goal — thì giờ vô nghĩa. Còn tới 7 ngày nữa Sprint mới hết.
Chị Lan quyết định cancel Sprint. Lý do: Sprint Goal đã obsolete vì thay đổi pháp lý, và còn quá nhiều thời gian để ngồi đợi. Chị accept phần backend đã DoD (vì nó vẫn tái sử dụng được cho luồng eKYC sau này), đưa phần còn lại về Backlog, rồi tổ chức Sprint Planning mới với Sprint Goal xoay sang "Hoàn thiện luồng eKYC để chuẩn bị cho phương án nạp tiền hợp quy."
Bài học: Đây là một cancel "đúng sách". Thay đổi đến từ bên ngoài (pháp lý), Sprint Goal mất hoàn toàn giá trị, thời gian còn lại đủ dài, và chỉ PO ký quyết định. Lưu ý phần đã DoD vẫn được accept chứ không vứt bỏ.
Tình huống 2 — E-commerce và cú pivot của ban lãnh đạo
Một sàn thương mại điện tử khu vực Đông Nam Á (tạm gọi ShopGo) có một team đang chạy Sprint 3 tuần với Sprint Goal: "Ra mắt tính năng livestream bán hàng tích hợp trực tiếp trong app cho seller hạng Gold."
Giữa Sprint, công ty mẹ ở Singapore công bố quyết định chiến lược: dừng toàn bộ đầu tư vào mảng livestream để dồn lực cho mảng logistics giao hàng nhanh, sau khi một thương vụ M&A với một startup giao vận hoàn tất. Mảng livestream chính thức bị "đóng băng" vô thời hạn.
Anh Minh — PO của team — đứng trước áp lực. Scrum Master nói: "Theo Scrum Guide thì anh có thể cancel Sprint vì Sprint Goal obsolete rồi." Stakeholder marketing thì tiếc nuối muốn làm cho xong để "có cái demo". Còn 9 ngày nữa mới hết Sprint.
Anh Minh chọn cancel Sprint. Sprint Goal đã hoàn toàn mất giá trị do pivot chiến lược, và việc để team làm tiếp 9 ngày một thứ sẽ bị bỏ xó là lãng phí rõ ràng. Anh accept một vài PBI hạ tầng video đã DoD (có thể tái dùng), đưa phần còn lại về Backlog, và lập tức làm việc với Scrum Master để khởi động Sprint Planning mới cho hướng logistics.
Điểm tinh tế: Anh Minh KHÔNG cancel chỉ vì Scrum Master "gợi ý", cũng KHÔNG giữ Sprint chỉ vì marketing "muốn có demo". Anh tự ra quyết định dựa trên giá trị. Đây chính là quyền tự chủ của PO. Trong đề thi, nếu phương án là "Scrum Master cancel Sprint" — sai; phải là "PO cân nhắc và cancel".
Tình huống 3 — Cái bẫy: Sprint "be bét" nhưng KHÔNG nên cancel
Một startup edtech ở Hà Nội (tạm gọi HocNhanh) đang chạy Sprint 2 tuần với Sprint Goal: "Cho phép học viên thanh toán khóa học qua VNPay ngay trong app." Đến ngày thứ 6, mọi thứ rối tung: tích hợp VNPay phức tạp hơn dự kiến, hai Developers nghỉ ốm, và team mới hoàn thành khoảng 30% scope. Nhìn vào, gần như chắc chắn Sprint sẽ không đạt được toàn bộ những gì đã lên kế hoạch.
Một bạn Developer sốt ruột đề xuất: "Hay mình cancel Sprint này đi, lập kế hoạch lại cho gọn?" Stakeholder cũng bực vì tiến độ chậm.
Chị Hà — PO — bình tĩnh phân tích: Sprint Goal "cho phép thanh toán qua VNPay" vẫn còn nguyên giá trị. Thị trường không đổi, chiến lược không đổi, không có gì làm mục tiêu trở nên vô nghĩa. Vấn đề ở đây chỉ là khó đạt, không phải mất giá trị. Vì vậy chị quyết định KHÔNG cancel. Thay vào đó, chị làm việc với Developers để thu hẹp scope (negotiate scope) — ưu tiên hoàn thành luồng thanh toán cơ bản nhất đủ để đạt Sprint Goal ở mức tối thiểu, gác lại các trường hợp ngoại lệ. Phần nào không kịp thì quay về Backlog khi hết timebox.
Bài học quan trọng nhất của cả bài: Sprint trục trặc, chậm tiến độ, estimate sai — đó KHÔNG phải lý do để cancel. Cancel chỉ khi Sprint Goal mất giá trị. Đây chính là cái bẫy kinh điển trong PSPO I.
Hướng dẫn từng bước
Khi bạn là PO và nghi ngờ rằng có thể cần cancel một Sprint, hãy đi qua quy trình suy nghĩ sau:
- Xác định điều gì vừa thay đổi. Hỏi rõ: có sự kiện nào từ bên ngoài (thị trường, pháp lý, chiến lược, công nghệ nền tảng) khiến Sprint Goal không còn đáng theo đuổi không? Nếu thay đổi chỉ liên quan đến tiến độ hoặc năng lực team — dừng lại, đây không phải tình huống cancel.
- Đánh giá Sprint Goal còn giá trị không. Đặt câu hỏi: "Nếu team hoàn thành đúng Sprint Goal này vào cuối Sprint, kết quả đó có còn mang lại giá trị cho sản phẩm/khách hàng/kinh doanh không?" Nếu câu trả lời là KHÔNG — Sprint Goal đã obsolete.
- Cân nhắc thời gian còn lại. Còn 1–2 ngày? Thường nên để Sprint chạy hết tự nhiên rồi điều chỉnh ở Sprint Planning kế tiếp — đỡ xáo trộn hơn. Còn nhiều ngày và việc tiếp tục là lãng phí rõ ràng? Cancel hợp lý hơn.
- Tham vấn (nhưng tự quyết định). Trao đổi với Scrum Master, Developers, stakeholder để thu thập thông tin. Nhưng nhớ: họ tư vấn, bạn quyết định. Đừng giao quyền này cho ai khác.
- Ra quyết định cancel. Chính thức tuyên bố Sprint kết thúc.
- Xử lý công việc sau cancel. Review các PBI đã đạt Definition of Done — accept nếu có giá trị. Đưa toàn bộ phần chưa hoàn thành về Product Backlog, sẵn sàng re-estimate và re-order.
- Khởi động Sprint Planning mới. Cancel xong, team sẽ bắt đầu một Sprint mới qua một Sprint Planning mới với Sprint Goal phù hợp với thực tại mới. Sprint mới không "thừa kế" timebox cũ.
Lỗi thường gặp & mẹo
Lỗi 1 — Nghĩ rằng Scrum Master hoặc cả team có quyền cancel. Đây là bẫy số một. Nhớ tuyệt đối: chỉ PO. Scrum Master có thể facilitate, có thể tư vấn, nhưng không cancel.
Lỗi 2 — Cancel vì Sprint chậm tiến độ / estimate sai. Như tình huống 3, đây là sai lầm phổ biến. Sprint khó đạt vẫn chạy hết timebox; phần dở dang quay về Backlog. Cancel chỉ khi Sprint Goal mất giá trị.
Lỗi 3 — Vứt bỏ hết công việc khi cancel. Sai. Phần đã đạt DoD vẫn được review và accept nếu có giá trị; phần còn lại quay về Backlog, không phải bị xóa sổ.
Lỗi 4 — Cancel quá dễ dàng, biến nó thành công cụ thường ngày. Scrum Guide nói cancel rất hiếm và gây xáo trộn. Nếu team bạn cancel Sprint liên tục, đó là dấu hiệu Sprint Goal được đặt sai, hoặc môi trường quá hỗn loạn, cần chữa tận gốc chứ không phải cancel hoài.
Lỗi 5 — Để stakeholder hoặc sếp "ép" cancel. Họ có thể là nguồn thông tin quan trọng (ví dụ báo tin pivot), nhưng quyết định phải do PO đưa ra dựa trên đánh giá giá trị, không phải vì bị ép.
Mẹo ghi nhớ cho kỳ thi: Khi gặp câu hỏi về cancel Sprint, hãy soi hai trục: (1) AI — luôn là PO; (2) KHI NÀO — chỉ khi Sprint Goal obsolete (mất giá trị), không phải khi khó đạt. Bất kỳ phương án nào lệch khỏi hai trục này đều đáng nghi.
Mẹo thực chiến: Cách phòng tránh cancel tốt nhất là đặt Sprint Goal đủ ngắn hạn, tập trung và linh hoạt, đồng thời giữ Sprint không quá dài. Sprint càng ngắn, "thiệt hại" khi môi trường thay đổi càng nhỏ, và nhu cầu cancel càng hiếm.
Bài tập thực hành
Bài 1 — Phân loại tình huống. Với mỗi tình huống dưới đây, hãy quyết định: NÊN cancel hay KHÔNG, và giải thích bằng tiêu chí "Sprint Goal có obsolete không":
- (a) Đối thủ vừa ra mắt đúng tính năng mà Sprint Goal của bạn đang xây, khiến lợi thế cạnh tranh biến mất. Còn 8 ngày.
- (b) Team phát hiện ước lượng sai gấp đôi, chắc chắn không kịp toàn bộ scope. Còn 5 ngày.
- (c) Lãnh đạo thông báo dừng dòng sản phẩm bạn đang làm để dồn lực sang mảng khác. Còn 10 ngày.
- (d) Một API bên thứ ba bị block tạm thời, nhưng Sprint Goal vẫn còn giá trị và có cách đi vòng. Còn 6 ngày.
Bài 3 — Câu hỏi dạng đề thi. Tự đặt một câu hỏi trắc nghiệm 4 phương án về "ai có quyền cancel Sprint", trong đó có ít nhất một phương án bẫy (ví dụ: "Scrum Master và Product Owner cùng quyết định"). Sau đó chỉ ra đáp án đúng và giải thích vì sao các phương án còn lại sai.
Gợi ý đáp án Bài 1: (a) Cancel — Sprint Goal mất giá trị cạnh tranh, còn nhiều thời gian. (b) KHÔNG — chỉ khó đạt, không mất giá trị; thu hẹp scope, để Sprint chạy hết. (c) Cancel — pivot chiến lược làm mục tiêu obsolete, còn nhiều thời gian. (d) KHÔNG — mục tiêu vẫn có giá trị, team adapt.
Tóm tắt
- Cancel Sprint là chấm dứt Sprint trước khi hết timebox — một sự kiện hiếm và gây xáo trộn.
- Chỉ Product Owner có thẩm quyền cancel. Không phải Scrum Master, không phải cả team, không phải sếp hay stakeholder — họ chỉ có thể đưa ra đầu vào.
- Lý do duy nhất chính thống để cancel là Sprint Goal trở nên obsolete (mất giá trị) — thường do thị trường, chiến lược, pháp lý hoặc công nghệ nền tảng thay đổi từ bên ngoài.
- Sprint khó đạt, chậm tiến độ, estimate sai KHÔNG phải lý do cancel — đây là cái bẫy kinh điển. Trường hợp này để Sprint chạy hết timebox, phần dở dang quay về Backlog.
- Khi cancel: review và accept các PBI đã đạt DoD nếu có giá trị; phần còn lại trả về Product Backlog; sau đó khởi động một Sprint mới qua Sprint Planning mới.
- Mẹo thi: luôn soi hai trục AI (PO) và KHI NÀO (Sprint Goal obsolete). Lệch khỏi hai trục này là sai.