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. /Sprint nào cũng "làm 14 story" mà không có mục t…
Agile & Hybrid· Domain: Bàn giao

Sprint nào cũng "làm 14 story" mà không có mục tiêu: viết Sprint Goal để đội có lý do ưu tiên

Sprint Backlog của đội là 14 story rời rạc, Sprint Goal ghi "Hoàn thành các story đã chọn". Khi có sự cố giữa sprint, không ai biết nên bỏ gì. Cách viết Sprint Goal thật sự, dùng nó để thương lượng phạm vi và đọc đúng câu hỏi PMP.

HP
Nguyễn Thu Hà, PMP
15/09/2026
6 phút đọc 0 0
Sprint nào cũng "làm 14 story" mà không có mục tiêu: viết Sprint Goal để đội có lý do ưu tiên

Tình huống minh hoạ

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

Đội phát triển ứng dụng đặt lịch khám của một chuỗi phòng khám chạy Scrum với sprint 2 tuần. Sprint Planning nào cũng diễn ra nhanh: Product Owner (PO) mở backlog, đội kéo 14 story từ trên xuống cho tới khi "đủ velocity", rồi điền vào ô Sprint Goal một câu quen thuộc: "Hoàn thành các story đã chọn".

Đến ngày thứ 6 của sprint, cổng thanh toán báo lỗi trên môi trường thật. Hai lập trình viên phải bỏ việc để xử lý. Daily Scrum hôm sau rơi vào bế tắc:

  • Người thì muốn bỏ story "Đổi giao diện trang cá nhân" vì nó ít quan trọng.
  • Người khác cho rằng story đó đã làm 60%, bỏ thì phí.
  • PO đang đi công tác, nhắn lại: "Cố làm hết, cái nào cũng cần."

Cuối sprint đội hoàn thành 9/14 story, nhưng Sprint Review không có câu chuyện nào để kể: 9 mảnh nhỏ thuộc 6 tính năng khác nhau, không mảnh nào đủ để người dùng thấy khác biệt. Đây là triệu chứng điển hình của sprint không có mục tiêu.

Sprint Goal là gì theo Scrum Guide 2020

Scrum Guide 2020 coi Sprint Goal là mục tiêu duy nhất của sprint, được tạo ra trong Sprint Planning. Nó là cam kết (commitment) gắn với Sprint Backlog, tương tự Product Goal gắn với Product Backlog và Definition of Done gắn với Increment. Sprint Goal mang lại sự gắn kết và tập trung, khuyến khích cả Scrum Team làm việc cùng nhau thay vì mỗi người một hướng.

Ba điểm hay bị hiểu sai:

  1. Sprint Goal không phải danh sách story. Danh sách story là "cách" đạt mục tiêu; mục tiêu là "vì sao" sprint này đáng làm.
  2. Phạm vi có thể thương lượng, mục tiêu thì không. Trong sprint, Developers có thể làm rõ và thương lượng lại phạm vi với PO miễn là Sprint Goal không bị ảnh hưởng.
  3. Sprint Goal là của cả Scrum Team. PO đề xuất cách sản phẩm có thể tăng giá trị trong sprint, nhưng cả đội cùng xác định mục tiêu và phải cam kết với nó trước khi kết thúc Sprint Planning.

Agile Alliance cũng nêu đúng triệu chứng của tình huống trên như một cạm bẫy của Sprint Planning: thiếu Sprint Goal cụ thể thì đội nhận về một tập việc rời rạc và dễ có cảm giác "làm nhiều mà không ra gì".

Một Sprint Goal tốt trông như thế nào

Không có mẫu bắt buộc, nhưng một Sprint Goal hữu ích thường có các đặc điểm:

Tiêu chíCâu hỏi kiểm traVí dụ yếuVí dụ tốt hơn

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
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
Agile & HybridLập kế hoạch

Backlog 180 story mà vẫn không biết phát hành gì trước: lập bản đồ user story theo hành trình người dùng

Danh sách backlog phẳng 180 dòng được xếp theo "giá trị" từng story, nhưng bản phát hành đầu lại không dùng được vì thiếu các bước nền. Cách dựng user story map theo hành trình người dùng, cắt lát phát hành có thể dùng ngay và kiểm tra story bằng INVEST.

Ngày đăng: 26/09/2026Lượt xem: 0Bình luận: 0
Nói về kết quả, không về công việcAi được lợi, lợi gì?"Làm 14 story""Bệnh nhân đặt lại lịch khám mà không cần gọi tổng đài"
Kiểm chứng được ở Sprint ReviewLàm sao biết đã đạt?"Cải thiện trải nghiệm""Người dùng thử nghiệm đổi lịch thành công trên môi trường staging"
Đủ hẹp để tập trungCó thể bỏ bớt story mà vẫn đạt không?"Hoàn thiện module lịch hẹn""Đổi lịch và huỷ lịch cho khách đã đăng nhập"
Đủ rộng để linh hoạtCòn chỗ để đội chọn cách làm không?"Làm API X, màn hình Y, nút Z"Như trên, để đội tự chọn giải pháp

Một mẹo thực tế: viết Sprint Goal trước khi chọn story. PO đến Sprint Planning với câu hỏi "Sprint này nên đưa sản phẩm tiến gần Product Goal theo cách nào?", đội thảo luận, chốt mục tiêu, rồi mới chọn các mục backlog phục vụ mục tiêu đó. Nếu backlog có vài story "lẻ" bắt buộc phải làm (sửa lỗi pháp lý, nâng phiên bản thư viện), có thể đưa vào nhưng cả đội hiểu rằng chúng không phải lý do của sprint.

Dùng Sprint Goal để ra quyết định giữa sprint

Quay lại ngày thứ 6. Nếu sprint có mục tiêu "Bệnh nhân đặt lại lịch khám mà không cần gọi tổng đài", Daily Scrum sẽ có câu hỏi rõ ràng: "Với hai người phải xử lý sự cố, kế hoạch nào còn đưa chúng ta tới mục tiêu?"

  • Story "Đổi giao diện trang cá nhân" không phục vụ mục tiêu → đưa trở lại Product Backlog, không cần tranh luận về "đã làm 60%".
  • Story "Gửi SMS xác nhận đổi lịch" phục vụ mục tiêu → giữ, có thể thu hẹp (chỉ email trước, SMS sau) sau khi trao đổi với PO.
  • Nếu ngay cả phiên bản thu hẹp cũng không kịp, đội báo sớm cho PO để cùng điều chỉnh, thay vì im lặng tới Sprint Review.

Đây đúng là tinh thần của Daily Scrum trong Scrum Guide 2020: kiểm tra tiến độ hướng tới Sprint Goal và điều chỉnh Sprint Backlog khi cần. Không có Sprint Goal thì Daily Scrum chỉ còn là kiểm tra tiến độ từng việc — và mọi việc trông đều quan trọng như nhau.

Những lý do đội né viết Sprint Goal và cách gỡ

"Backlog của chúng tôi toàn việc lặt vặt, không gom được thành mục tiêu." Thường đây là dấu hiệu Product Backlog thiếu thứ tự theo giá trị hoặc thiếu Product Goal. PO cần sắp xếp lại backlog quanh một vài kết quả lớn; tạm thời có thể chọn mục tiêu dạng "Giảm 50% số việc tồn đọng về lỗi thanh toán" thay vì gom tính năng.

"Viết mục tiêu rồi không đạt thì bị đánh giá." Nếu tổ chức dùng Sprint Goal như KPI cá nhân, đội sẽ viết mục tiêu dễ cho chắc. Scrum Master cần giải thích với quản lý: Sprint Goal là công cụ tập trung và minh bạch; sprint không đạt mục tiêu là dữ liệu để Sprint Retrospective học hỏi, không phải lỗi để phạt.

"Đội làm nhiều sản phẩm cùng lúc." Nhiều mục tiêu song song nghĩa là không có mục tiêu nào. Trước hết cần làm rõ đội đang phục vụ sản phẩm nào; nếu tổ chức buộc đội làm hai luồng, ít nhất hãy chọn một mục tiêu chính và nói rõ các việc khác là phần phụ.

"Sprint Planning đã dài, thêm bước viết mục tiêu càng dài." Thực tế ngược lại: khi mục tiêu rõ, việc chọn story nhanh hơn vì có tiêu chí loại bỏ. Scrum Guide giới hạn Sprint Planning tối đa 8 giờ cho sprint một tháng và thường ngắn hơn với sprint ngắn hơn.

Sprint Goal và Sprint Review

Khi có mục tiêu, Sprint Review trở thành câu chuyện: "Sprint này chúng tôi nhắm tới việc bệnh nhân tự đổi lịch. Đây là kết quả, đây là phản hồi từ 5 người dùng thử, đây là những gì còn thiếu." Bên liên quan nhìn thấy tiến độ về kết quả, không phải số story. Nếu mục tiêu chỉ đạt một phần, việc trình bày minh bạch phần đạt và chưa đạt giúp PO điều chỉnh Product Backlog cho sprint tiếp theo — đúng chu trình kiểm tra và thích ứng (inspect and adapt) của chủ nghĩa kinh nghiệm (empiricism).

Góc PMP

  • Câu hỏi về "việc phát sinh giữa sprint" thường có đáp án gắn với Sprint Goal: Developers và PO thương lượng lại phạm vi miễn là không ảnh hưởng Sprint Goal; việc lớn làm thay đổi mục tiêu đưa vào Product Backlog cho PO sắp xếp.
  • Sprint Goal do cả Scrum Team xác định trong Sprint Planning, không phải do PO hay Scrum Master áp xuống.
  • Ba cam kết của Scrum Guide 2020: Product Goal ↔ Product Backlog, Sprint Goal ↔ Sprint Backlog, Definition of Done ↔ Increment.
  • Đáp án "PM/Scrum Master giao việc cho từng người để kịp" thường sai: Developers tự quản lý (self-managing) cách đạt mục tiêu.

Nguồn tham khảo

  • The Scrum Guide (2020) – Ken Schwaber & Jeff Sutherland
  • Agile Alliance Glossary – Sprint Planning
  • Agile Alliance Glossary – Timebox
#sprint-goal#sprint-planning#scrum#sprint-backlog#tu-quan-ly

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

Câu 1/1
Giữa sprint, một sự cố trên môi trường thật khiến hai Developers phải dừng việc. Đội nhận thấy không thể hoàn thành tất cả mục trong Sprint Backlog. Sprint Goal là "Khách hàng tự đổi lịch hẹn mà không cần gọi tổng đài". Đội nên làm gì?

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

Product Owner của bạn quen đến Sprint Planning với danh sách 14 story đã chọn sẵn và muốn ghi Sprint Goal là "Hoàn thành các story đã chọn". Các story thuộc 5 tính năng khác nhau. Nếu là PM/Scrum Master, bạn làm gì trước?

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ạSprint Goal là gì theo Scrum Guide 2020Một Sprint Goal tốt trông như thế nàoDùng Sprint Goal để ra quyết định giữa sprintNhững lý do đội né viết Sprint Goal và cách gỡSprint Goal và Sprint ReviewGóc PMPNguồn tham khảoTrắc nghiệmBình chọn
Quảng cáoTemplate quản lý dự án (mẫu)
Quảng cáoBộ đề thi thử PMP (mẫu)