Skip to main content

Scrum Activities – Scrum Events / Ceremonies (PMI-ACP)

Minh hoạ 5 Scrum Events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.

Scrum Activities – 5 “khung họp” quen thuộc lặp lại trong từng Sprint.

Ngôn ngữ • Language

Scrum Activities (Scrum Events / Ceremonies)​

💡 Bài này dành cho ai?

  • Bạn đã đọc Scrum Process và muốn hiểu rõ “trong Sprint thì họp những gì?”
  • Bạn hay nghe từ “Scrum Ceremonies” mà chưa phân biệt được mục tiêu từng buổi.
  • Bạn chuẩn bị thi PMI-ACP và muốn tránh nhầm lẫn Daily Scrum vs status meeting, Review vs Retrospective.
TL;DR – 5 Scrum Activities trong một Sprint
  • Scrum có 5 Scrum Events (Scrum Activities / Ceremonies):
    1. Sprint – Timebox 1–4 tuần, “container” cho mọi hoạt động.
    2. Sprint Planning – Mở Sprint: đặt Sprint Goal, chọn & lập plan cho Sprint Backlog.
    3. Daily Scrum – 15 phút mỗi ngày cho Developers đồng bộ & lên plan 24h tới.
    4. Sprint Review – Cuối Sprint: demo Increment với stakeholder, inspect & adapt Product Backlog.
    5. Sprint Retrospective – Cuối Sprint: Scrum Team hồi cứu cách làm việc & chốt vài cải tiến cho Sprint sau.
  • Keywords hay ra đề PMI-ACP:
    • Timebox, Sprint Goal, Sprint Backlog, Increment, Inspect & Adapt, facilitation, servant leadership.
Lối tắt:ECO 2025 · 4 domain
Cho người mới bắt đầu

Nếu thấy bài hơi dày, bạn có thể:

  1. Đọc nhanh phần TL;DR + bảng overview ở giữa bài.
  2. Đọc kỹ 5 mục: Sprint, Sprint Planning, Daily, Review, Retro.
  3. Khi gần thi, quay lại phần Exam patterns & traps phía dưới.

🤭 Fun fact nhỏ về “Scrum Ceremonies”

  • Ngày xưa, nhiều sách Agile gọi 4 buổi họp chính là Scrum Ceremonies.
  • Scrum Guide bản mới dùng từ Scrum Events (sự kiện), tránh cảm giác “hình thức cho có lễ nghi”.
  • Trong thực tế & đề thi, bạn có thể gặp cả hai từ:
    • Hễ nhắc Scrum Ceremonies → hãy nghĩ ngay đến 4 buổi họp + Sprint là container.
Product Backlog Refinement ở đâu?
  • Product Backlog Refinement (làm rõ, chẻ nhỏ, estimate, sắp xếp lại PBI) không phải là một Scrum Event chính thức.
  • Tuy vậy, trong thực tế & đề PMI-ACP, bạn cần nhớ đây là hoạt động diễn ra liên tục trong Sprint, giúp phần trên cùng của Product Backlog sẵn sàng cho các Sprint sau.
  • Khi câu hỏi nhắc đến refinement, hãy liên hệ đến tư duy inspect & adapt + collaboration chứ đừng cố gán nó như một “buổi họp thứ 6”.

1. Bức tranh tổng thể: 5 Scrum Activities trong một Sprint​

Trong một Sprint, Scrum Team đi qua 5 “khung hoạt động”:

  • Sprint – khung thời gian cố định (timebox).
  • Sprint Planning – họp mở Sprint, quyết định làm gì & làm thế nào.
  • Daily Scrum – họp đứng 15 phút, cập nhật & lên kế hoạch 24h.
  • Sprint Review – review sản phẩm với stakeholder, lấy feedback.
  • Sprint Retrospective – review cách làm việc, rút kinh nghiệm & cải tiến.

  1. Sprint – khung thời gian cố định (timebox)

2.1. Sprint là gì?​

  • Sprint là một timebox cố định 1–4 tuần, trong đó Scrum Team tạo ra một Increment có thể sử dụng được (potentially releasable).
  • Mọi hoạt động – từ planning, coding, testing đến review, retrospective – đều diễn ra bên trong Sprint.

🧩 Hiểu đơn giản: Sprint là một “hộp thời gian” – bạn không kéo giãn hộp, mà phải sắp xếp công việc để vừa trong hộp.

2.2. Độ dài Sprint – đề thi nói gì?​

  • Scrum Guide: Sprint thường 1–4 tuần, độ dài cố định trong suốt dự án.
  • Một số tài liệu cũ nói 2–6 tuần, nhưng trong thi & thực tế hiện đại, >4 tuần rất hiếm.
  • Ngắn quá → overhead meeting nhiều. Dài quá → feedback chậm, rủi ro cao.

2.3. Trong Sprint có được thay đổi gì không?​

Trong Sprint:

  • Không thay đổi Sprint Goal chỉ vì ý thích nhất thời.
  • PO có thể thảo luận yêu cầu mới, nhưng:
    • Không “quăng” thêm việc phá vỡ Sprint Goal nếu Scrum Team không đồng ý.
    • Những yêu cầu mới thường được đưa vào Product Backlog, prioritize cho các Sprint sau.
  • Sprint Backlog có thể được điều chỉnh:
    • Developers có thể thêm/bớt/chỉnh task khi học được thông tin mới, miễn vẫn hướng tới Sprint Goal.
    • Sprint Backlog thuộc quyền sở hữu của Developers, không phải line manager.
  • Hạn chế thay đổi thành viên:
    • Team estimate & lên capacity dựa trên số người hiện tại.
    • Thay người liên tục sẽ làm velocity không ổn định, khó predict.

⚠️ Trong đề thi, nếu thấy option “thay người giữa Sprint cho kịp deadline” hoặc “ép team làm thêm việc giữa Sprint, kéo dài Sprint cho đến khi xong” → thường là đáp án sai Agile mindset.

2.4. Khi nào có thể huỷ Sprint?​

Đôi khi, Sprint có thể bị huỷ – nhưng đây là trường hợp đặc biệt:

  • Ai có quyền huỷ Sprint?
    • Product Owner là người có quyền huỷ Sprint (thường sau khi tham khảo Scrum Team & stakeholders).
  • Khi nào nên cân nhắc huỷ?
    • Sprint Goal không còn ý nghĩa (ví dụ: thay đổi lớn về business, pivot sản phẩm).
    • Có sự kiện bên ngoài làm cho việc theo đuổi Sprint Goal hiện tại không còn tạo value.
  • Khi huỷ Sprint:
    • Những PBI đã hoàn thành & đủ Definition of Done vẫn có thể release.
    • Phần việc còn lại được quay lại Product Backlog để sắp xếp lại.
Hint đề thi – Huỷ Sprint

Nếu câu hỏi có option “kéo dài Sprint thêm 1–2 tuần cho kịp scope” vs “kết thúc/huỷ Sprint rồi re-plan Sprint mới với mục tiêu phù hợp hơn”, PMI-ACP thường ưu tiên giữ timebox & xem xét huỷ/đóng Sprint sớm hơn là kéo dài vô hạn.

  1. Sprint Planning – “Mở bát” Sprint

3.1. Mục tiêu Sprint Planning​

Sprint Planning trả lời 3 câu hỏi lớn:

  1. Tại sao Sprint này có giá trị? → Sprint Goal.
  2. Chúng ta sẽ làm những gì? → chọn Product Backlog Items cho Sprint Backlog.
  3. Chúng ta sẽ làm như thế nào? → plan chi tiết, chia nhỏ công việc.

Tóm gọn: “Why + What + How cho Sprint này.”

3.2. Ai tham gia?​

  • Product Owner – giải thích mục tiêu & giải đáp yêu cầu.
  • Scrum Master / Agile PM – facilitation, bảo vệ timebox & Scrum values.
  • Developers – ước lượng, kéo việc, thiết kế cách thực hiện.

Đây không phải là cuộc họp sếp giao task; team tự kéo việc dựa trên capacity & past performance.

3.3. Timebox​

  • Gợi ý: tối đa 8 giờ cho Sprint 1 tháng.
  • Sprint 2 tuần → khoảng 4 giờ là hợp lý.

3.4. Đầu vào & đầu ra​

Input:

  • Phần trên cùng của Product Backlog đã được refine.
  • Velocity / capacity lịch sử của team.

Output:

  • Một Sprint Goal rõ ràng, 1–2 câu.
  • Một Sprint Backlog – gồm các PBI đã chọn + plan để hiện thực hoá.
  • Team hiểu rõ định hướng & ranh giới của Sprint.
🔍 Hint đề thi
  • Ai quyết định Sprint Goal? → Scrum Team, với PO dẫn dắt về value.
  • Ai quyết định team có thể kéo bao nhiêu việc? → Developers, dựa trên capacity & past performance, không phải line manager.

  1. Daily Scrum – 15 phút “soi & chỉnh” mỗi ngày

4.1. Daily Scrum để làm gì?​

  • Daily Scrum giúp Developers đồng bộ và lên kế hoạch cho 24h tới để đạt Sprint Goal.
  • Đây không phải là buổi báo cáo cho sếp.

4.2. Timebox & tần suất​

  • Timebox: tối đa 15 phút.
  • Mỗi ngày 1 lần, cùng giờ, cùng chỗ (hoặc cùng Zoom/Teams).

4.3. Ai nói, ai nghe?​

  • Người “chính” là Developers – họ nói với nhau để điều chỉnh kế hoạch.
  • PO, Scrum Master, stakeholder có thể tham dự, nhưng:
    • Không biến cuộc họp thành status report cho riêng họ.
    • Nếu có vấn đề to, để sau Daily tách ra bàn riêng.

4.4. 3 câu hỏi kinh điển​

Một template dễ nhớ:

  1. Hôm qua (từ lần Daily trước) mình đã làm gì giúp đạt Sprint Goal?
  2. Hôm nay mình sẽ làm gì để tiến gần Sprint Goal hơn?
  3. Có vướng mắc / impediment nào đang chặn mình không?

Quan trọng:

  • Trong Daily, không ngồi giải quyết vấn đề đến nơi đến chốn.
  • Nếu có impediment:
    • Chỉ cần nêu ra.
    • Scrum Master hoặc người liên quan ghi nhận, set up buổi nhỏ sau đó.
Scrum Guide mới & 3 câu hỏi
  • Scrum Guide bản mới không bắt buộc phải dùng đúng 3 câu hỏi này.
  • Yêu cầu cốt lõi: Daily Scrum phải giúp Developers inspect tiến độ toward Sprint Goal và adapt kế hoạch cho 24h tới.
  • Trong đề PMI-ACP, nếu thấy phương án nhấn mạnh “inspect & adapt toward Sprint Goal” thì thường đáng tin hơn những option chỉ chăm chăm “trả lời đủ 3 câu hỏi”.

⚠️ Bẫy đề: câu nào mô tả Daily Scrum thành “1 giờ giải bug tập thể” hoặc “Manager hỏi từng người xong mắng” → gần như luôn sai.

  1. Sprint Review – inspect Increment với stakeholder

5.1. Mục tiêu Sprint Review​

  • Demo Increment – cho stakeholder thấy thứ team vừa làm xong.
  • Lấy feedback thực tế từ người dùng / business.
  • Cập nhật Product Backlog dựa trên học được.

Đây là event focus vào sản phẩm & value, không phải họp chê trách.

5.2. Ai tham gia?​

  • Scrum Team – PO, Scrum Master / Agile PM, Developers.
  • Stakeholders liên quan – khách hàng, user, sponsor, compliance, v.v.

5.3. Timebox​

  • Gợi ý: tối đa 1 giờ cho mỗi tuần Sprint.
    • Sprint 2 tuần → khoảng 2 giờ.
    • Sprint 4 tuần → khoảng 4 giờ.

5.4. Nội dung chính​

  • Team demo sản phẩm thật (Increment), không chỉ slide.
  • Stakeholder đặt câu hỏi, đưa nhận xét.
  • PO & team:
    • Ghi nhận feedback, thêm/bớt/ưu tiên lại Product Backlog.
    • Thảo luận về kế hoạch release / hướng đi tiếp.
Review vs UAT?
  • Sprint Review là activity của Scrum Team → inspect & adapt.
  • UAT (User Acceptance Test) có thể là một phần của Review, hoặc một hoạt động riêng, tuỳ tổ chức.
  • Trong đề PMI-ACP, nếu nói riêng về Scrum, hãy ưu tiên tư duy theo Sprint Review + Increment.

  1. Sprint Retrospective – “soi lại cách làm việc”

6.1. Mục tiêu Retrospective​

  • Nhìn lại cách team đã làm việc trong Sprint:
    • Quy trình, cách phối hợp, công cụ, chất lượng, communication…
  • Chọn ra một vài cải tiến cụ thể để áp dụng ngay từ Sprint sau.

Nói nôm na: Retro = “họp rút kinh nghiệm nhưng không drama”.

6.2. Ai tham gia?​

  • Chỉ Scrum Team – PO, Scrum Master / Agile PM, Developers.
  • Không mời “sếp to” nếu chỉ để “hỏi tội”; mục tiêu là tạo không gian an toàn để team nói thật với nhau.

6.3. Timebox​

  • Gợi ý: tối đa 3 giờ cho Sprint 1 tháng.
  • Sprint ngắn hơn → thời lượng thường ngắn hơn.

6.4. Câu hỏi gợi ý​

  • Điều gì đã làm tốt, nên làm nhiều hơn?
  • Điều gì chưa ổn, nên giảm bớt hoặc dừng lại?
  • Ta muốn thử nghiệm điều gì mới trong Sprint tới?

Output lý tưởng:

  • 1–3 action items rõ ràng được đưa vào Sprint Backlog tiếp theo.
  • Ví dụ:
    • “Mỗi PR phải có ít nhất 1 người review.”
    • “Thêm 10–15% capacity cho refactor / nợ kỹ thuật.”
Retro != blame

Đề PMI-ACP rất ghét phương án “tìm ra ai sai rồi phạt”.
Retrospective là để cải thiện hệ thống & cách làm việc, không phải “xử lý cá nhân”.

7. Bảng tóm tắt – Scrum Activities & key points​

Sự kiệnMục tiêuTimebox (gợi ý)Ai tham gia chính?
SprintTimebox 1–4 tuần để tạo Increment và thực hiện tất cả Scrum Events.1–4 tuần, cố địnhToàn bộ Scrum Team
Sprint PlanningĐặt Sprint Goal, chọn việc, lập plan cho Sprint Backlog.~8 giờ cho Sprint 1 thángPO, Scrum Master / Agile PM, Developers
Daily ScrumĐồng bộ & lên kế hoạch 24h để bám Sprint Goal.15 phút mỗi ngàyDevelopers (PO & SM có thể tham dự)
Sprint ReviewDemo Increment, lấy feedback, adapt Product Backlog.~1 giờ / tuần SprintScrum Team + Stakeholders
Sprint RetrospectiveHồi cứu cách làm việc, chốt một vài cải tiến cho Sprint sau.~3 giờ cho Sprint 1 thángScrum Team

8. Exam patterns & traps – Scrum Activities​

Advanced – Bẫy đề PMI-ACP về Scrum Activities
  • Daily Scrum = status meeting cho sếp?
    • Sai. Daily Scrum là meeting của Developers để inspect & adapt kế hoạch 24h.
  • Sprint Review vs Retrospective
    • Review: tập trung vào sản phẩm & stakeholder feedback.
    • Retro: tập trung vào team & cách làm việc.
    • Câu nào trộn 2 cái này vào nhau → cẩn thận.
  • Thay đổi scope giữa Sprint
    • PO có thể đổi Product Backlog bất kỳ lúc nào, nhưng Sprint Backlog thuộc quyền Developers; scope trong Sprint không nên bị phá vỡ nếu làm hỏng Sprint Goal.
    • Nếu thay đổi quá lớn → có thể kết thúc Sprint sớm/huỷ Sprint, không kéo dài timebox.
  • Timebox bị ignore
    • Câu trả lời “kéo dài Daily Scrum cho đến khi xong việc” hay “Sprint có thể kéo dài thêm 1–2 tuần nếu chưa xong” → thường sai Sprint timebox.
  • Retro bị skip vì “không có gì để nói”
    • Đáp án tốt: Scrum Master coaching team về tầm quan trọng của continuous improvement, vẫn giữ Retro (có thể timebox ngắn hơn), không bỏ hẳn.
  • PO vắng mặt Sprint Review
    • Sprint Review liên quan mạnh đến value & backlog direction → PO nên tham gia. Các phương án chấp nhận “PO luôn bận nên không cần tham gia Review” thường là anti-pattern.

9. Checklist học & tự soi​

  1. Đọc lại bảng tóm tắt 5 Scrum Events.
  2. Lấy Sprint gần nhất của bạn và thử gắn từng hoạt động vào: Planning, Daily, Review, Retro.
  3. Ghi lại 1–2 bẫy đề bạn hay nhầm (ví dụ: Review vs Retro).

Checklist – Scrum Activities (VI)

Tiến độ: 0/5 (0%)

Mini-mock – Scrum Activities

Loading questions…

10. Liên hệ ECO / Blueprint PMI-ACP​

Để bài này không “đứng riêng lẻ” mà gắn với ECO / Blueprint:

  • Agile Principles & Mindset
    • Timebox, transparency, inspect & adapt trong cả 5 sự kiện.
    • Servant leadership & facilitation của Scrum Master trong Planning, Daily, Review, Retro.
  • Team Performance
    • Cách team phối hợp trong Daily, Retro; tạo psychological safety trong Retro.
    • Tự tổ chức (self-organizing) khi team tự kéo việc và tự lên plan trong Sprint Planning.
  • Delivery
    • Increment, Sprint Goal, Release discussion trong Sprint Review.
    • Liên tục giao giá trị qua từng Sprint.
  • Continuous Improvement / Problem Detection & Resolution
    • Retro là “công cụ ECO sống” cho continuous improvement.
    • Daily Scrum giúp phát hiện sớm impediments để xử lý.

Khi làm đề, hễ thấy câu hỏi xoay quanh meeting trong Sprint, timebox, feedback loop, inspect & adapt → rất có thể đang test các domain trên (chứ không chỉ riêng “Scrum lý thuyết”).

Bài liên quan:

Scrum Roles and Responsibilities

• sắp tới

Scrum Artifacts

Liên hệ & cập nhật

Không spam. Bạn có thể huỷ đăng ký bất cứ lúc nào.