Phân hệ PM Study
  • Tình huốngTình huống thực chiến
  • Kịch bảnRa quyết định tình huống
  • Biểu mẫuKho biểu mẫu tải về
  • Thẻ ghi nhớHọc thuật ngữ PMP
  • Công cụMáy tính EVM, PERT, dự phòng
  • Hỏi đápHỏi đáp & thảo luận
  • Thử tháchMỗi ngày một câu hỏi PMP
  • Lý thuyếtBài học PMBOK 8 & ECO 2026
  • Luyện thiThi thử & ôn tập PMP
  • Bài viếtThư viện bài viết PMP
PM Study
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đáp
6 chuyên mụcXem tất cả bài viết →
  • Quản lý các bên liên quanTình huống về kỳ vọng, giao tiếp và gắn kết stakeholder.
  • Lãnh đạo & đội nhómXây dựng, dẫn dắt và giải quyết xung đột trong đội dự án.
  • Kế hoạch & tiến độLập kế hoạch, ước lượng, nén tiến độ và kiểm soát baseline.
  • Rủi ro & thay đổiNhận diện, ứng phó rủi ro và kiểm soát thay đổi phạm vi.
  • Agile & HybridLựa chọn và vận hành cách tiếp cận Agile, Predictive, Hybrid.
  • Luyện thi PMPChiến lược ôn tập và mẹo xử lý câu hỏi tình huống PMP.
Công cụBài viết
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đápChuyên mụcCông cụBài viết
/
PM Study

Học quản lý dự án và ôn thi PMP bằng tiếng Việt: lý thuyết PMBOK® Guide 8, tình huống thực tế và đề luyện thi theo ECO 2026.

Chuyên mục

  • Quản lý các bên liên quan
  • Lãnh đạo & đội nhóm
  • Kế hoạch & tiến độ
  • Rủi ro & thay đổi
  • Agile & Hybrid
  • Luyện thi PMP

Tài nguyên

  • Project Management Institute (PMI)
  • PMP Exam Content Outline
  • The Scrum Guide
  • PMI Vietnam Chapter

PM Study

  • Tất cả bài viết
  • Bài viết nổi bật
© 2026 PM StudyPMP® và PMBOK® là nhãn hiệu đã đăng ký của Project Management Institute.Phiên bản 1.12.1
  1. /Agile & Hybrid
  2. /Đối thủ ra mắt trước, Sprint Goal mất ý nghĩa: k…
Agile & Hybrid· Domain: Sự không chắc chắn (rủi ro)

Đối thủ ra mắt trước, Sprint Goal mất ý nghĩa: khi nào huỷ sprint và ai được quyền huỷ

Giữa sprint, cơ quan quản lý công bố quy định mới làm tính năng đang phát triển trở nên vô nghĩa. Trưởng phòng muốn "dừng ngay", đội muốn "làm cho xong". Scrum Guide 2020 nói gì về huỷ sprint, ai có quyền, xử lý công việc dở dang ra sao và vì sao huỷ sprint nên hiếm.

HP
Nguyễn Thu Hà, PMP
05/08/2026
6 phút đọc 0 0
Đối thủ ra mắt trước, Sprint Goal mất ý nghĩa: khi nào huỷ sprint và ai được quyền huỷ

Tình huống minh hoạ

Tình huống và số liệu dưới đây là giả định, dùng để minh hoạ.

Một công ty bảo hiểm có đội Scrum phát triển cổng bồi thường trực tuyến, sprint 3 tuần. Sprint Goal của sprint hiện tại: "Khách hàng nộp hồ sơ bồi thường xe kèm ảnh giấy tờ bản giấy và nhận mã hồ sơ ngay".

Ngày thứ 5 của sprint, cơ quan quản lý công bố quy định mới: từ quý sau, hồ sơ bồi thường phải xác thực bằng giấy tờ điện tử qua ứng dụng định danh quốc gia, ảnh chụp giấy tờ bản giấy không còn được chấp nhận. Phần lớn công việc của sprint — luồng tải ảnh, nhận dạng ký tự trên ảnh, kiểm tra chất lượng ảnh — trở nên vô ích.

Phản ứng trong công ty rất khác nhau:

  • Trưởng phòng kinh doanh: "Dừng sprint ngay, chuyển sang làm xác thực điện tử."
  • Một số Developers: "Đã làm được gần nửa, cứ làm nốt cho trọn, sprint sau tính."
  • Scrum Master: "Scrum không cho phép thay đổi giữa sprint."

Cả ba đều chưa đúng hoàn toàn.

Scrum Guide 2020 nói gì

Scrum Guide 2020 quy định rõ:

  • Một sprint có thể bị huỷ nếu Sprint Goal trở nên lỗi thời (obsolete).
  • Chỉ Product Owner (PO) có quyền huỷ sprint.

Ngoài ra, Scrum Guide cũng nói trong sprint không được thực hiện thay đổi làm nguy hại Sprint Goal, nhưng phạm vi có thể được làm rõ và thương lượng lại khi hiểu biết thay đổi. Nghĩa là Scrum không "cấm thay đổi" — nó phân biệt hai loại:

Loại thay đổiVí dụCách xử lý
Thay đổi phạm vi, mục tiêu vẫn còn giá trịMột story phức tạp hơn dự kiến, cần cắt bớtDevelopers và PO thương lượng lại phạm vi trong sprint
Yêu cầu mới, mục tiêu vẫn còn giá trịBên liên quan muốn thêm tính năngĐưa vào Product Backlog, PO sắp xếp cho sprint sau
Mục tiêu mất giá trịQuy định mới khiến kết quả sprint vô dụngPO cân nhắc huỷ sprint

Trong tình huống trên, Sprint Goal "nộp hồ sơ kèm ảnh giấy tờ bản giấy" không còn đem lại giá trị cho kinh doanh. Đây chính là trường hợp mục tiêu lỗi thời.

Sprint là một hộp thời gian (timebox) cố định, một tháng hoặc ít hơn. Huỷ sprint không phải "kéo dài" hay "rút ngắn" sprint như một thủ thuật; nó là sự thừa nhận rằng hộp thời gian hiện tại không còn phục vụ mục đích gì.

Ai làm gì

Trưởng phòng kinh doanh không có quyền huỷ sprint. Ông có thể (và nên) đưa thông tin quy định mới tới PO ngay lập tức, nhưng quyết định thuộc về PO. Nếu trưởng phòng ra lệnh trực tiếp cho Developers đổi việc, đó là can thiệp làm hỏng trách nhiệm giải trình của PO.

Tình huống liên quan

Agile & HybridĐo lường

Bảng Kanban kín việc mà khách vẫn chờ lâu: giới hạn WIP và định luật Little

Đội hỗ trợ triển khai có 6 người nhưng đang "ôm" 31 yêu cầu dở dang, khách hàng chờ trung bình hơn ba tuần. Dùng bốn chỉ số dòng chảy của Kanban Guide và định luật Little để chứng minh rằng bắt đầu ít việc hơn mới là cách xong việc nhanh hơn.

Ngày đăng: 02/10/2026Lượt xem: 2Bình luận: 0
Agile & HybridBàn giao

Product Owner kiêm nhiệm "vắng mặt": khi backlog chờ quyết định cả tuần

Product Owner là trưởng phòng nghiệp vụ, chỉ dành được vài giờ mỗi tuần cho đội. Câu hỏi tồn đọng, đội tự đoán yêu cầu và làm lại. Cách chẩn đoán, khôi phục quyền ra quyết định và ủy quyền đúng cách.

Ngày đăng: 01/10/2026Lượt xem: 7Bình luận: 0
Rủi ro & thay đổiSự không chắc chắn (rủi ro)

Thiết bị y tế nhập khẩu đội giá vì tỷ giá: quản lý rủi ro tài chính trong dự án bệnh viện

Ngân sách mua thiết bị chẩn đoán hình ảnh được lập bằng VND, nhưng giá chào bằng USD. Khi tỷ giá biến động, dự án bệnh viện đứng trước nguy cơ thiếu vốn. Cách nhận diện, định lượng và ứng phó rủi ro tỷ giá.

Ngày đăng: 01/10/2026Lượt xem: 1Bình luận: 0
Agile & HybridĐội dự án

Mỗi story qua tay bốn người, cuối sprint dồn kiểm thử: phá silo chuyên môn bằng swarming và kỹ năng hình chữ T

Đội Scrum 8 người nhưng thực chất là bốn "phòng ban mini": phân tích, backend, frontend, kiểm thử. Story nào cũng đi qua bốn tay, kiểm thử viên ngập việc ba ngày cuối sprint. Vì sao đội liên chức năng không có nghĩa là mỗi người một chuyên môn, và cách chuyển sang làm việc theo kiểu "cả đội dồn vào ít việc".

Ngày đăng: 29/09/2026Lượt xem: 2Bình luận: 0

Developers không tự quyết "làm nốt cho trọn". Hoàn thành một Increment không có giá trị là lãng phí; nỗ lực đã bỏ ra là chi phí chìm (sunk cost) và không nên là lý do tiếp tục.

Scrum Master cần sửa hiểu lầm "Scrum cấm thay đổi giữa sprint", giúp PO hiểu quyền và hệ quả của việc huỷ, và tạo điều kiện cho cuộc thảo luận nhanh, minh bạch với cả đội.

PO đánh giá: mục tiêu có thật sự lỗi thời không, hay vẫn có thể giữ một phần giá trị (ví dụ quy định mới chỉ áp dụng từ quý sau, trong khi luồng hiện tại vẫn dùng được 3 tháng)? Nếu vẫn còn giá trị đáng kể, có thể giữ sprint và điều chỉnh phạm vi thay vì huỷ.

Nếu huỷ: xử lý công việc dở dang thế nào

Scrum Guide 2020 không quy định chi tiết các bước sau khi huỷ, nên đội cần thực hành có cân nhắc. Một trình tự hợp lý:

  1. Rà soát các mục đã "Done". Những mục đạt Definition of Done và vẫn có giá trị (ví dụ màn hình tra cứu trạng thái hồ sơ — dùng được cho cả luồng mới) có thể được giữ lại như một phần của Increment.
  2. Đưa các mục chưa xong trở lại Product Backlog. PO ước lượng lại giá trị của chúng dưới bối cảnh mới; nhiều mục có thể bị loại.
  3. Ghi nhận hiểu biết thu được. Ví dụ, kinh nghiệm tích hợp dịch vụ nhận dạng ký tự có thể không còn cần, nhưng hiểu biết về luồng duyệt hồ sơ thì vẫn hữu ích.
  4. Lập sprint mới bằng Sprint Planning với Sprint Goal mới (ví dụ thử nghiệm xác thực giấy tờ điện tử với ứng dụng định danh).
  5. Rút kinh nghiệm: buổi nhìn lại ngắn về vì sao thông tin quy định đến muộn với đội, có kênh theo dõi thay đổi pháp lý nào cần thiết lập không.

Vì sao huỷ sprint nên là chuyện hiếm

Huỷ sprint tốn kém: kế hoạch bị bỏ, đội phải chuyển ngữ cảnh, các sự kiện Scrum phải làm lại, bên liên quan có thể mất niềm tin vào khả năng dự báo. Vì vậy:

  • Sprint ngắn giảm nhu cầu huỷ. Scrum Guide nhận xét sprint ngắn hơn tạo ra nhiều vòng học hỏi hơn và giới hạn rủi ro chi phí, công sức trong khung thời gian nhỏ hơn. Nếu đội thường xuyên gặp mục tiêu lỗi thời giữa sprint, có thể sprint đang quá dài so với tốc độ thay đổi của môi trường.
  • Sprint Goal vừa phải chịu được biến động. Mục tiêu viết quá cụ thể vào giải pháp ("tải ảnh giấy tờ") dễ lỗi thời hơn mục tiêu viết về kết quả ("khách nộp hồ sơ bồi thường trực tuyến nhanh").
  • Theo dõi rủi ro bên ngoài. Quy định mới hiếm khi xuất hiện không có dấu hiệu báo trước. Thông tin về dự thảo quy định nên được PO và bên liên quan đưa vào Product Backlog refinement sớm.

Liên hệ quản lý rủi ro

Trong ngôn ngữ PMBOK, quy định mới là một rủi ro bên ngoài đã xảy ra (trở thành vấn đề). Huỷ sprint là một phản ứng thích ứng (adaptation), phù hợp lĩnh vực hiệu suất Bất định (Uncertainty) trong PMBOK 7: môi trường thay đổi thì kế hoạch phải thay đổi theo, nhưng thông qua người có thẩm quyền và quy trình minh bạch. Với dự án hybrid có đường cơ sở hợp đồng, quyết định đổi hướng còn có thể cần qua quy trình kiểm soát thay đổi (change control) ở cấp dự án, dù sprint huỷ thuộc quyền PO.

Góc PMP

  • "Ai có quyền huỷ sprint?" → Product Owner. Không phải Scrum Master, không phải sponsor, không phải PM.
  • "Khi nào?" → khi Sprint Goal trở nên lỗi thời. Thay đổi phạm vi hoặc yêu cầu mới không phải lý do huỷ.
  • Đáp án "tiếp tục làm theo kế hoạch vì đã cam kết" thường sai khi bối cảnh cho thấy kết quả không còn giá trị.
  • Đáp án "Scrum Master ra quyết định huỷ" là bẫy hay gặp.

Nguồn tham khảo

  • The Scrum Guide (2020) – Ken Schwaber & Jeff Sutherland
  • Agile Alliance Glossary – Timebox
  • Agile Alliance Glossary – Iteration
#huy-sprint#sprint-cancellation#product-owner#sprint-goal#thich-ung

Trắc nghiệm tình huống PMP

Câu 1/1
Giữa sprint, một đối tác chiến lược thông báo chấm dứt hợp tác. Sprint Goal hiện tại là tích hợp thanh toán với chính đối tác này. Sponsor gọi cho Scrum Master yêu cầu "dừng sprint ngay và chuyển đội sang dự án khác". Scrum Master nên làm gì?

Bạn chọn phương án nào?

Ngày thứ 8 của sprint 10 ngày, quy định mới khiến Sprint Goal mất phần lớn giá trị. Đội đã hoàn thành khoảng 70% Sprint Backlog, một số mục vẫn có thể dùng lại cho hướng mới. Nếu là PM hỗ trợ Product Owner, bạn khuyến nghị gì?

Bài viết hữu ích? Chia sẻ cho đồng nghiệp nhé!

Đánh giá bài viết

Bình luận

Mục lục

Tình huống minh hoạScrum Guide 2020 nói gìAi làm gìNếu huỷ: xử lý công việc dở dang thế nàoVì sao huỷ sprint nên là chuyện hiếmLiên hệ quản lý rủi roGóc PMPNguồn tham khảoTrắc nghiệmBình chọn
Quảng cáoBộ đề thi thử PMP (mẫu)
Quảng cáoTemplate quản lý dự án (mẫu)