Mở đầu — vì sao bài này quan trọng
Trong tất cả các quyết định mà một Scrum Team có thể đưa ra, hủy một Sprint (Sprint Cancellation) là một trong những quyết định "nặng ký" nhất — và cũng là một trong những chủ đề mà đề thi PSM I yêu thích nhất để gài bẫy thí sinh. Vì sao? Bởi vì hủy Sprint là một sự kiện cực kỳ hiếm gặp trong thực tế. Nhiều Scrum Master làm việc nhiều năm mà chưa từng thấy một Sprint bị hủy. Chính vì hiếm, nên người ta dễ hiểu sai, dễ áp dụng tùy tiện, và dễ nhầm về việc "ai mới là người có quyền".
Đề thi PSM I khai thác đúng vùng "mờ" này. Một câu hỏi điển hình sẽ vẽ ra một tình huống đầy áp lực — sếp lớn yêu cầu, khách hàng đổi ý, hay team gặp sự cố kỹ thuật — rồi hỏi bạn: "Ai có thể hủy Sprint?" hoặc "Khi nào nên hủy Sprint?". Nếu bạn không nắm chắc nguyên tắc gốc theo Scrum Guide, bạn sẽ chọn nhầm phương án "nghe có vẻ hợp lý" nhưng sai về mặt framework.
Bài học này tập trung làm rõ ba câu hỏi cốt lõi: Ai có quyền hủy Sprint, Khi nào việc hủy là hợp lệ, và Điều gì xảy ra sau khi Sprint bị hủy. Nắm chắc ba điểm này, bạn không chỉ trả lời đúng câu hỏi thi mà còn hiểu được triết lý sâu xa của Scrum về quyền tự chủ và trách nhiệm. Hãy cùng đi vào chi tiết.
Khái niệm cốt lõi
Sprint Cancellation là gì
Theo Scrum Guide 2020, một Sprint có thể bị hủy trước khi hết timebox của nó. Nói cách khác, hủy Sprint là việc kết thúc Sprint sớm hơn dự kiến — thay vì để nó chạy hết 1, 2 hay 4 tuần như đã định, ta dừng nó lại giữa chừng. Đây không phải là việc "kéo dài thêm" Sprint (điều mà Scrum tuyệt đối không cho phép), mà là việc chấm dứt Sprint trước hạn.
Cần phân biệt rõ ngay từ đầu: hủy Sprint khác với việc Sprint kết thúc bình thường. Khi Sprint chạy hết timebox, nó đơn giản là "đóng lại" qua Sprint Review và Sprint Retrospective. Còn hủy Sprint là một hành động chủ động, có chủ đích, được kích hoạt bởi một lý do cụ thể và nghiêm trọng.
Ai có quyền hủy Sprint — chỉ Product Owner
Đây là điểm quan trọng nhất của cả bài, và là câu trả lời "by the book" mà đề thi PSM I muốn bạn ghi nhớ tuyệt đối:
> Chỉ Product Owner mới có quyền hủy một Sprint. Không phải Scrum Master, không phải Developers, không phải quản lý cấp trên, không phải khách hàng, và không phải bất kỳ stakeholder nào.
Vì sao lại là Product Owner? Hãy nhớ lại trách nhiệm cốt lõi của Product Owner: tối đa hóa giá trị của sản phẩm. Product Owner là người chịu trách nhiệm về điều gì team đang xây dựng và vì sao. Một Sprint chỉ nên bị hủy khi mục tiêu của nó — Sprint Goal — không còn ý nghĩa, không còn giá trị. Và người duy nhất có thẩm quyền phán xét về giá trị của Sprint Goal chính là người sở hữu định hướng sản phẩm: Product Owner.
Điều này không có nghĩa Product Owner ra quyết định trong cô lập. Trong thực tế, Product Owner thường lắng nghe ý kiến từ Developers, Scrum Master và stakeholders. Developers có thể phát hiện vấn đề kỹ thuật nghiêm trọng, stakeholders có thể báo về thay đổi thị trường. Nhưng quyền quyết định cuối cùng — cây bút ký vào "lệnh hủy" — luôn nằm trong tay Product Owner. Người khác có thể gây ảnh hưởng, nhưng không thể quyết định.
Khi nào việc hủy Sprint là hợp lệ — Sprint Goal trở nên lỗi thời
Scrum Guide 2020 nêu rất rõ và rất gọn: Một Sprint sẽ bị hủy nếu Sprint Goal trở nên lỗi thời (obsolete). Đây là lý do hợp lệ duy nhất được Scrum Guide nêu tên.
"Sprint Goal trở nên lỗi thời" nghĩa là gì? Đó là khi mục tiêu mà team đang theo đuổi không còn mang lại giá trị nữa, hoặc không còn phù hợp với thực tế nữa. Một vài tình huống điển hình:
- Công ty đột ngột thay đổi định hướng (pivot). Sản phẩm mà bạn đang làm bỗng bị ngừng đầu tư, hoặc thị trường mục tiêu thay đổi hoàn toàn.
- Đối thủ cạnh tranh ra mắt tính năng mà Sprint Goal của bạn nhắm tới, khiến việc tiếp tục trở nên vô nghĩa.
- Thay đổi về luật pháp, quy định khiến tính năng đang phát triển trở nên bất hợp pháp hoặc không còn cần thiết.
- Công nghệ nền tảng thay đổi đột ngột khiến hướng tiếp cận của Sprint Goal không còn khả thi.
Điều gì xảy ra sau khi hủy Sprint
Khi một Sprint bị hủy, một chuỗi hệ quả sau diễn ra theo Scrum Guide:
- Mọi Product Backlog Item đã hoàn thành (Done) sẽ được xem xét (reviewed). Nếu phần việc đó có thể release và mang lại giá trị, Product Owner thường sẽ chấp nhận nó. Công sức đã tạo ra giá trị "Done" không bị vứt bỏ một cách lãng phí.
- Mọi công việc chưa hoàn thành sẽ được đưa trở lại Product Backlog (re-estimated và đưa lại vào Product Backlog). Nó không bị mất; nó quay về để được sắp xếp lại ưu tiên cho các Sprint sau.
- Sprint Backlog của Sprint bị hủy sẽ không còn tồn tại. Một Sprint mới sẽ bắt đầu bằng một Sprint Planning mới.
Vì sao hủy Sprint lại gây "chấn động" và nên hiếm
Scrum Guide nhấn mạnh rằng việc hủy Sprint tiêu tốn tài nguyên (consume resources) — vì team phải tái tổ chức lại trong một Sprint Planning mới — và thường gây traumatic (gây tổn thương) cho Scrum Team. Đó là lý do tại sao hủy Sprint rất hiếm khi xảy ra. Sprint vốn đã ngắn (tối đa 1 tháng), nên trong hầu hết trường hợp, kể cả khi có vấn đề, team chỉ cần đợi Sprint hiện tại kết thúc tự nhiên rồi điều chỉnh ở Sprint sau. Việc hủy chỉ dành cho những trường hợp Sprint Goal thực sự không còn lý do tồn tại.
Tình huống thực tế
Tình huống 1 — Startup fintech Việt Nam và cú "pivot" bất ngờ
Hãy hình dung MoMoPay Lab (tên giả định), một nhóm sản phẩm trong một startup fintech ở TP.HCM, đang chạy một Sprint 2 tuần với Sprint Goal: "Hoàn thành luồng thanh toán qua thẻ tín dụng quốc tế để mở rộng sang khách du lịch nước ngoài." Team có 5 Developers, đã làm được 4 ngày.
Đến cuối tuần thứ nhất, ban lãnh đạo họp khẩn và quyết định: do thay đổi trong giấy phép trung gian thanh toán từ Ngân hàng Nhà nước, mảng thẻ quốc tế phải tạm dừng vô thời hạn. Sprint Goal "mở rộng sang khách du lịch nước ngoài" bỗng chốc trở nên vô nghĩa — không còn ai cần luồng thanh toán đó nữa.
Diễn giải: Product Owner của team, sau khi nắm thông tin từ ban lãnh đạo, đánh giá rằng Sprint Goal đã thực sự obsolete. Cô ấy là người ra quyết định hủy Sprint. Lưu ý: ban lãnh đạo cung cấp thông tin và thay đổi định hướng kinh doanh, nhưng chính Product Owner mới là người chính thức hủy Sprint trong khuôn khổ Scrum. Các phần đã Done (ví dụ một module xác thực thẻ dùng chung) được review và giữ lại; phần dở dang được đưa về Product Backlog. Team bắt đầu một Sprint mới với Sprint Planning để hướng vào ưu tiên mới: tối ưu thanh toán nội địa.
Bài học rút ra: Lý do hủy ở đây hoàn toàn chính đáng — Sprint Goal mất giá trị do thay đổi pháp lý và định hướng. Và người bấm nút hủy là Product Owner, không phải ban lãnh đạo, dù áp lực đến từ trên.
Tình huống 2 — Cái bẫy kinh điển: "Sếp yêu cầu hủy Sprint"
Tại một công ty gia công phần mềm ở Hà Nội, giả định là VietSoft Solutions, một Giám đốc Kỹ thuật (CTO) bước vào phòng team giữa Sprint và nói: "Tôi muốn dừng Sprint này ngay, chuyển toàn bộ team sang lo cho demo với khách hàng Nhật vào tuần sau." Scrum Master mới vào nghề lúng túng, định làm theo lệnh CTO ngay.
Diễn giải: Đây chính xác là dạng câu hỏi đề thi PSM I rất hay hỏi. CTO không có quyền hủy Sprint — đó không phải là vai trò của ông ấy trong Scrum. Hơn nữa, "chuyển team sang demo khác" không nhất thiết khiến Sprint Goal hiện tại trở nên lỗi thời; có khi đó chỉ là một yêu cầu công việc mới cần được đưa vào Product Backlog. Cách xử lý đúng: Scrum Master bảo vệ team, giải thích cho CTO cách Scrum vận hành, và đưa yêu cầu này đến Product Owner. Product Owner sẽ là người đánh giá: liệu Sprint Goal hiện tại có còn giá trị hay không. Nếu vẫn còn giá trị, có lẽ tốt nhất là để Sprint chạy hết (Sprint chỉ còn vài ngày) rồi điều chỉnh sau. Chỉ khi Product Owner kết luận Sprint Goal thực sự mất ý nghĩa, mới đến chuyện hủy.
Bài học rút ra: Áp lực từ cấp trên không tự động biến thành "lý do hợp lệ để hủy Sprint", và chức danh cao không tự động trao quyền hủy. Quyền hủy thuộc về Product Owner; vai trò của Scrum Master là bảo vệ tính toàn vẹn của Scrum và "che chắn" cho team khỏi gián đoạn không cần thiết.
Tình huống 3 — Khi team muốn hủy vì... gặp bug nặng
Một nhóm phát triển game mobile tại Đà Nẵng (giả định: Saigon Pixel Studio) đang ở giữa Sprint 3 tuần với Sprint Goal: "Ra mắt chế độ chơi nhiều người (multiplayer) cho phiên bản beta." Sang ngày thứ 10, Developers phát hiện rằng thư viện networking họ chọn có một lỗi nghiêm trọng khiến độ trễ quá cao. Một Developer bực bội đề xuất: "Thôi hủy Sprint này đi, làm lại từ đầu."
Diễn giải: Đây là một cái bẫy tinh vi khác. Một bug kỹ thuật, dù nặng đến đâu, không tự động khiến Sprint Goal trở nên lỗi thời. Sprint Goal "ra mắt chế độ multiplayer cho beta" vẫn còn giá trị — khách hàng vẫn muốn tính năng đó. Vấn đề chỉ là cách thực hiện gặp trở ngại. Trong trường hợp này, team không nên hủy Sprint. Thay vào đó, đây là lúc Scrum thể hiện sức mạnh của empiricism: Developers, với tư cách self-managing team, có thể điều chỉnh phạm vi (scope) trong Sprint Backlog, thương lượng lại với Product Owner về cách đạt Sprint Goal (ví dụ: đổi thư viện, hoặc giảm phạm vi multiplayer xuống mức tối thiểu khả thi). Sprint vẫn tiếp tục; chỉ có kế hoạch bên trong được điều chỉnh linh hoạt.
Còn nếu — và chỉ nếu — sau phân tích, hóa ra việc làm multiplayer là bất khả thi về mặt kỹ thuật trong tầm nhìn gần và Product Owner kết luận mục tiêu này không còn đáng theo đuổi nữa, thì lúc đó Sprint Goal mới thực sự obsolete, và Product Owner mới cân nhắc hủy.
Bài học rút ra: Khó khăn kỹ thuật không phải lý do hủy Sprint; nó là lý do để inspect và adapt bên trong Sprint. Đừng nhầm "kế hoạch gặp trục trặc" với "mục tiêu mất giá trị".
Hướng dẫn từng bước
Khi đối mặt với một tình huống có vẻ cần hủy Sprint — trong công việc thật hay trong phòng thi — hãy đi qua các bước sau:
- Xác định: Sprint Goal có còn giá trị không? Đây là câu hỏi đầu tiên và quan trọng nhất. Nếu Sprint Goal vẫn còn ý nghĩa với sản phẩm và khách hàng, thì gần như chắc chắn không nên hủy. Mọi vấn đề khác (bug, chậm tiến độ, thiếu người) đều được giải quyết bằng inspect & adapt bên trong Sprint.
- Nếu Sprint Goal thực sự đã lỗi thời, xác định ai ra quyết định. Câu trả lời luôn là: Product Owner. Scrum Master và Developers có thể cung cấp thông tin và quan điểm, nhưng quyết định cuối cùng thuộc về Product Owner.
- Product Owner đánh giá tổng thể. Cân nhắc: Sprint còn lại bao lâu? Nếu chỉ còn 1-2 ngày, thường tốt hơn là để Sprint kết thúc tự nhiên rồi điều chỉnh ở Sprint Planning kế tiếp, vì hủy Sprint tiêu tốn tài nguyên và gây xáo trộn.
- Nếu quyết định hủy, xử lý các Product Backlog Item. Phần đã Done được review và cân nhắc release. Phần dở dang được re-estimate và đưa trở lại Product Backlog.
- Bắt đầu Sprint mới bằng Sprint Planning mới. Sprint không thể "tiếp nối"; mỗi Sprint mới luôn khởi đầu bằng một Sprint Planning để thiết lập Sprint Goal mới và Sprint Backlog mới.
- Khuyến khích team nhìn lại để học hỏi. Dù không bắt buộc cứng nhắc, một cuộc trao đổi ngắn về việc "vì sao Sprint Goal lại trở nên lỗi thời, ta có thể phát hiện sớm hơn không" thường rất có giá trị.
Lỗi thường gặp & mẹo
Lỗi 1 — Nghĩ rằng Scrum Master có thể hủy Sprint. Đây là sai lầm phổ biến nhất. Scrum Master là servant leader, facilitator, người bảo vệ Scrum — nhưng không có quyền hủy Sprint. Mẹo ghi nhớ: gắn quyền hủy với người chịu trách nhiệm về giá trị — đó là Product Owner.
Lỗi 2 — Tin rằng quản lý cấp cao hoặc khách hàng có thể hủy Sprint. Chức danh không trao quyền hủy Sprint trong Scrum. Họ chỉ có thể ảnh hưởng đến Product Owner. Đề thi rất hay đưa nhân vật "sếp lớn" vào để gài bẫy bạn.
Lỗi 3 — Hủy Sprint vì lý do sai. Bug nặng, team làm chậm, thành viên nghỉ ốm, ước lượng sai — tất cả những điều này không phải lý do hủy. Chúng được giải quyết bằng inspect & adapt bên trong Sprint, hoặc bằng việc thương lượng lại scope. Chỉ có Sprint Goal trở nên obsolete mới là lý do hợp lệ.
Lỗi 4 — Nghĩ rằng công việc dở dang bị "mất trắng" khi hủy Sprint. Không. Công việc chưa hoàn thành quay về Product Backlog để được ưu tiên lại. Không có gì bị vứt bỏ một cách vô ích.
Lỗi 5 — Quên rằng Sprint mới cần một Sprint Planning mới. Không có chuyện "hủy rồi chạy tiếp Sprint cũ". Mỗi Sprint là một container mới, bắt đầu bằng Planning.
Mẹo cho phòng thi: Khi thấy câu hỏi về hủy Sprint, hãy quét nhanh hai từ khóa: (1) Ai — nếu phương án nói ai đó ngoài Product Owner hủy Sprint, loại ngay; (2) Vì sao — nếu lý do không phải "Sprint Goal lỗi thời", hãy cảnh giác cao độ. Hai bộ lọc này loại được phần lớn đáp án sai.
Bài tập thực hành
- Tự kiểm tra khái niệm: Viết ra (không nhìn tài liệu) câu trả lời cho ba câu: Ai có quyền hủy Sprint? Lý do hợp lệ duy nhất để hủy là gì? Công việc dở dang đi đâu sau khi hủy? Sau đó đối chiếu với bài.
- Phân tích tình huống: Một Product Owner muốn hủy Sprint vì "team đang làm chậm và chắc chắn không kịp Sprint Goal." Theo bạn, đây có phải lý do hợp lệ không? Hãy lập luận bằng nguyên tắc Scrum, rồi đề xuất hướng xử lý đúng (gợi ý: nghĩ về inspect & adapt và việc thương lượng scope của Sprint Goal).
- Đóng vai Scrum Master: Một Project Manager yêu cầu bạn hủy Sprint hiện tại để dồn lực cho một dự án khác. Hãy viết ra 3-4 câu bạn sẽ nói để vừa tôn trọng PM, vừa bảo vệ tính toàn vẹn của Scrum, vừa định tuyến quyết định đến đúng người.
- Soạn câu hỏi PSM I của riêng bạn: Tự viết một câu hỏi trắc nghiệm 4 phương án về hủy Sprint, trong đó có ít nhất một "bẫy về Ai" và một "bẫy về Vì sao". Việc tự ra đề giúp bạn nhìn thấy cấu trúc bẫy của đề thi thật.
Tóm tắt
- Hủy Sprint (Sprint Cancellation) là việc kết thúc Sprint trước khi hết timebox — một sự kiện hiếm gặp, tốn tài nguyên và thường gây xáo trộn cho team.
- Chỉ Product Owner có quyền hủy Sprint. Không phải Scrum Master, Developers, quản lý cấp cao hay khách hàng. Người khác có thể gây ảnh hưởng, nhưng quyết định cuối cùng thuộc về Product Owner — người chịu trách nhiệm về giá trị sản phẩm.
- Lý do hợp lệ duy nhất là khi Sprint Goal trở nên lỗi thời (obsolete) — mục tiêu không còn giá trị, thường do thay đổi định hướng kinh doanh, thị trường, pháp lý hoặc công nghệ. Bug, chậm tiến độ, thiếu người không phải lý do hủy.
- Sau khi hủy: việc đã Done được review (và có thể release), việc dở dang quay về Product Backlog, và một Sprint mới bắt đầu bằng Sprint Planning mới.
- Trong phòng thi, dùng hai bộ lọc: kiểm tra Ai (phải là Product Owner) và Vì sao (phải là Sprint Goal lỗi thời) để loại nhanh các đáp án sai.