Scrum Activities – Scrum Events / Ceremonies (PMI-ACP)
Scrum Activities – 5 “khung họp” quen thuộc lặp lại trong từng Sprint.
Ngôn ngữ • Language
- VI
- EN
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):
- Sprint – Timebox 1–4 tuần, “container” cho mọi hoạt động.
- Sprint Planning – Mở Sprint: đặt Sprint Goal, chọn & lập plan cho Sprint Backlog.
- Daily Scrum – 15 phút mỗi ngày cho Developers đồng bộ & lên plan 24h tới.
- Sprint Review – Cuối Sprint: demo Increment với stakeholder, inspect & adapt Product Backlog.
- 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ể:
- Đọc nhanh phần TL;DR + bảng overview ở giữa bài.
- Đọc kỹ 5 mục: Sprint, Sprint Planning, Daily, Review, Retro.
- 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.
- 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.
- 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:
- Tại sao Sprint này có giá trị? → Sprint Goal.
- Chúng ta sẽ làm những gì? → chọn Product Backlog Items cho Sprint Backlog.
- 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.
- 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ớ:
- Hôm qua (từ lần Daily trước) mình đã làm gì giúp đạt Sprint Goal?
- Hôm nay mình sẽ làm gì để tiến gần Sprint Goal hơn?
- 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.
- 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.
- 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ện | Mục tiêu | Timebox (gợi ý) | Ai tham gia chính? |
|---|---|---|---|
| Sprint | Timebox 1–4 tuần để tạo Increment và thực hiện tất cả Scrum Events. | 1–4 tuần, cố định | Toà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áng | PO, 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ày | Developers (PO & SM có thể tham dự) |
| Sprint Review | Demo Increment, lấy feedback, adapt Product Backlog. | ~1 giờ / tuần Sprint | Scrum Team + Stakeholders |
| Sprint Retrospective | Hồ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áng | Scrum 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
- Đọc lại bảng tóm tắt 5 Scrum Events.
- 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.
- 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
Scrum Activities (Scrum Events / Ceremonies)
💡 Who this article is for
- You’ve read Scrum Process and now want to understand “what happens during a Sprint?”
- You’ve heard the term Scrum Ceremonies but can’t clearly distinguish each event’s purpose.
- You’re preparing for PMI-ACP and want to avoid confusing Daily Scrum vs status meeting, Review vs Retrospective.
TL;DR – 5 Scrum Activities in a Sprint
- Scrum defines 5 Scrum Events (Scrum Activities / Ceremonies):
- Sprint – 1–4 week timebox that contains all other events.
- Sprint Planning – Start of the Sprint: set the Sprint Goal, select and plan the Sprint Backlog.
- Daily Scrum – 15 minutes each day for Developers to synchronize and plan the next 24 hours.
- Sprint Review – End of Sprint: inspect the Increment with stakeholders and adapt the Product Backlog.
- Sprint Retrospective – End of Sprint: Scrum Team inspects how they worked and decides on improvements.
- Common PMI-ACP keywords:
- Timebox, Sprint Goal, Sprint Backlog, Increment, Inspect & Adapt, facilitation, servant leadership.
Lối tắt:ECO 2025 · 4 domain
For beginners
If the article feels dense:
- Start with the TL;DR and summary table.
- Then focus on the 5 sections: Sprint, Sprint Planning, Daily, Review, Retro.
- Closer to the exam, revisit the Exam patterns & traps section.
🤭 Fun fact about “Scrum Ceremonies”
- Older Agile books often used the term Scrum Ceremonies for the four core meetings.
- Newer Scrum Guides prefer Scrum Events to avoid the impression of “rituals for ritual’s sake”.
- In practice and in exam questions, you may see both terms – read them as the same underlying 4 meetings + the Sprint as container.
Where does Product Backlog Refinement fit?
- Product Backlog Refinement (clarifying, splitting, estimating, and ordering PBIs) is not an official Scrum Event.
- However, in practice and in PMI-ACP questions, you should remember it as an ongoing activity during the Sprint to keep the top of the Product Backlog ready for future Sprints.
- When you see refinement in exam questions, link it to inspect & adapt + collaboration, not to “a sixth mandatory ceremony”.
1. Big picture: 5 Scrum Activities inside a Sprint
Within one Sprint, the Scrum Team moves through 5 key events:
- Sprint – the fixed timebox containing everything.
- Sprint Planning – opening the Sprint: decide why, what, and how.
- Daily Scrum – 15-minute daily check-in to adjust the plan.
- Sprint Review – inspect the Increment with stakeholders.
- Sprint Retrospective – inspect and adapt how the team works.
- Sprint – the fixed timebox
2.1. What is a Sprint?
- A Sprint is a fixed-length timebox of 1–4 weeks in which the Scrum Team creates a usable Increment.
- All work – planning, development, testing, review, and retrospective – happens inside the Sprint.
Think of the Sprint as a “time-shaped box”: you don’t stretch the box; you adjust the work to fit into it.
2.2. Sprint length – what exams expect
- Scrum Guide: Sprints are 1–4 weeks and have a consistent length.
- Some older sources mention 2–6 weeks, but in modern practice and exams, >4 weeks is rare.
- Too short → meeting overhead. Too long → slow feedback, higher risk.
2.3. What can change during a Sprint?
During a Sprint:
- The Sprint Goal should remain stable once agreed.
- The PO can discuss new ideas or requests, but:
- You don’t randomly throw in extra work that would break the Sprint Goal without Scrum Team agreement.
- New work usually goes into the Product Backlog and is prioritized for future Sprints.
- The Sprint Backlog can be adjusted:
- Developers may add, remove, or re-plan tasks as they learn more, as long as they still work toward the Sprint Goal.
- The Sprint Backlog is owned by Developers, not by a line manager.
- Avoid changing team composition mid-Sprint:
- Capacity and velocity are based on the current team.
- Constantly swapping people in and out makes velocity noisy and predictability poor.
⚠️ In exams, options like “extend the Sprint until work is done” or “add more people mid-Sprint to meet scope” are typically anti-Scrum answers.
2.4. When can a Sprint be canceled?
Sometimes, a Sprint can be canceled – but this is an exception:
- Who can cancel a Sprint?
- The Product Owner is the only person who can cancel a Sprint (usually after consulting the Scrum Team and stakeholders).
- When might cancellation be appropriate?
- The Sprint Goal no longer makes sense (e.g., major business change, product pivot).
- External events make the current Sprint Goal no longer valuable.
- When a Sprint is canceled:
- Completed work that meets the Definition of Done may still be released.
- Remaining items are returned to the Product Backlog for reordering.
Exam hint – Sprint cancellation
If an option contrasts “extend the Sprint 1–2 more weeks to finish the scope” with “end/cancel the current Sprint and plan a new one with a more relevant goal”, PMI-ACP usually favors protecting the timebox and considering ending the Sprint early, not stretching it.
- Sprint Planning – opening the Sprint
3.1. Purpose of Sprint Planning
Sprint Planning answers three core questions:
- Why is this Sprint valuable? → define the Sprint Goal.
- What can be done in the Sprint? → select items into the Sprint Backlog.
- How will the work be done? → create a plan.
Short version: “Why + What + How for this Sprint.”
3.2. Who participates?
- Product Owner – explains Product Goal and clarifies requirements.
- Scrum Master / Agile PM – facilitates and protects timebox and Scrum values.
- Developers – estimate, pull work, create the plan.
This is not a manager assigning tasks meeting; the team pulls work based on capacity and past performance.
3.3. Timebox
- Up to 8 hours for a 1-month Sprint.
- Proportionally shorter for shorter Sprints (e.g., about 4 hours for a 2-week Sprint).
3.4. Inputs and outputs
Inputs:
- Refined items at the top of the Product Backlog.
- Historic velocity / capacity.
Outputs:
- A clear, shared Sprint Goal.
- A Sprint Backlog (selected items + a plan for delivery).
- Shared understanding of constraints and expectations.
🔍 Exam hint
- Who defines the Sprint Goal? → The Scrum Team (with PO guiding value).
- Who decides how much can be done? → Developers, based on capacity and historical data, not a line manager.
- Daily Scrum – 15-minute inspect & adapt
4.1. Purpose
- Daily Scrum helps Developers synchronize and plan the next 24 hours toward the Sprint Goal.
- It is not a status-report meeting for a manager.
4.2. Timebox & frequency
- Timebox: maximum 15 minutes.
- Once per day, same time, same place (or same online room).
4.3. Who speaks?
- Primarily Developers – they talk to each other.
- PO and Scrum Master can attend, but:
- Should not hijack the meeting for reporting.
- Problem-solving should happen after the Daily, in smaller discussions.
4.4. Classic 3 questions
A simple format:
- What did I do since the last Daily to help achieve the Sprint Goal?
- What will I do today to move us closer to the Sprint Goal?
- Are there any impediments in my way?
Important:
- The Daily Scrum is not the time to deeply solve problems.
- Impediments are surfaced here → then handled outside the 15-minute timebox.
Scrum Guide & the 3 questions
- The latest Scrum Guide does not require these exact 3 questions.
- The core requirement is that Daily Scrum enables Developers to inspect progress toward the Sprint Goal and adapt the plan for the next 24 hours.
- In PMI-ACP questions, options that emphasize “inspect & adapt toward the Sprint Goal” are usually better than those focusing only on “answering 3 questions by rote”.
⚠️ Exam trap: answers that turn the Daily Scrum into “a 1-hour detailed problem-solving meeting” or “a manager’s status review” are usually wrong.
- Sprint Review – inspect the Increment with stakeholders
5.1. Purpose
- Show the Increment to stakeholders.
- Gather feedback and discuss what to do next.
- Adapt the Product Backlog accordingly.
It’s a product-focused event, not a blame session.
5.2. Who participates?
- The entire Scrum Team.
- Relevant stakeholders – customers, users, sponsors, etc.
5.3. Timebox
- Up to 1 hour per week of Sprint.
- 2-week Sprint → about 2 hours.
- 4-week Sprint → about 4 hours.
5.4. What happens?
- The team demos working product (the Increment), not just slides.
- Stakeholders ask questions and share feedback.
- PO and the team:
- Update the Product Backlog.
- Discuss likely next steps and possible releases.
Review vs UAT?
- The Sprint Review is a Scrum event for inspect & adapt.
- UAT may be part of the Review or a separate activity, depending on context.
- In PMI-ACP Scrum questions, think in terms of Sprint Review + Increment first.
- Sprint Retrospective – inspect & adapt how we work
6.1. Purpose
- Inspect how the last Sprint went in terms of:
- People, relationships, process, tools, quality…
- Identify and plan improvements to implement in the next Sprint.
Retro = “learn and improve”, not “name and shame”.
6.2. Who participates?
- Only the Scrum Team – PO, Scrum Master / Agile PM, Developers.
- External managers or stakeholders are usually not present unless invited for a very specific reason and in a safe way.
6.3. Timebox
- Up to 3 hours for a 1-month Sprint.
- Shorter Sprints → shorter Retros.
6.4. Typical questions
- What went well and we should do more of?
- What didn’t go so well and we should do less of / stop?
- What experiments or changes do we want to try next Sprint?
Ideal output:
- 1–3 concrete action items added to the next Sprint Backlog.
Retro != blame
PMI-ACP strongly favors system and process improvement over blaming individuals. Answers that focus on “finding who to punish” are almost never correct.
7. Summary table – Scrum Activities & key points
| Event | Purpose | Timebox (guideline) | Key participants |
|---|---|---|---|
| Sprint | 1–4 week timebox containing all work and events to create an Increment. | 1–4 weeks, fixed | Entire Scrum Team |
| Sprint Planning | Define Sprint Goal, select work, and create a plan for the Sprint. | ~8 hours for 1-month Sprint | PO, Scrum Master / Agile PM, Developers |
| Daily Scrum | Inspect progress and plan the next 24 hours toward the Sprint Goal. | 15 minutes daily | Developers (PO & SM may attend) |
| Sprint Review | Inspect the Increment with stakeholders and adapt the Product Backlog. | ~1 hour per week of Sprint | Scrum Team + Stakeholders |
| Sprint Retrospective | Inspect how the team worked and plan improvements for the next Sprint. | ~3 hours for 1-month Sprint | Scrum Team |
8. Exam patterns & traps – Scrum Activities
Advanced – common PMI-ACP traps
-
Daily Scrum as a status meeting
- If the answer says “manager collects status from each team member” → usually wrong.
- Correct view: Developers inspect and adapt toward the Sprint Goal.
-
Confusing Review and Retrospective
- Review: product & stakeholders.
- Retro: team & process.
- Many trick options mix these two.
-
Changing scope mid-Sprint
- PO can reorder the Product Backlog anytime, but the Sprint Backlog is owned by Developers; you shouldn’t disrupt the Sprint Goal.
- Big changes may justify ending/canceling the Sprint, not extending the timebox.
-
Ignoring timeboxes
- Extending Sprints or Daily Scrums to “finish the work” is often an anti-pattern answer in exams.
-
Skipping the Retrospective
- A common wrong option is “skip Retro when there’s nothing to improve”. The better answer is usually that the Scrum Master coaches the team and keeps some form of Retro (possibly shorter), to support continuous improvement.
-
PO missing the Sprint Review
- The Review is about product value and future direction; the PO should be there. Answers that normalize “the PO is always too busy to attend Reviews” are usually poor choices.
9. Checklist & self-reflection
- Re-read the summary table of 5 Scrum Events.
- Map your last Sprint’s meetings to these events.
- Note down 1–2 traps you personally tend to fall into (e.g., mixing Review vs Retro).
Checklist – Scrum Activities (EN)
Tiến độ: 0/5 (0%)
Mini-mock – Scrum Activities
Loading questions…
10. Linking to ECO / Blueprint domains
To connect this article back to ECO / Blueprint:
- Agile Principles & Mindset
- Timeboxing, transparency, and inspect & adapt across all 5 events.
- Servant leadership & facilitation by the Scrum Master in Planning, Daily, Review, Retro.
- Team Performance
- How the team collaborates in Daily and Retro; psychological safety in Retro.
- Self-organization when the team pulls work and creates the plan in Sprint Planning.
- Delivery
- Increment, Sprint Goal, and release discussions in Sprint Review.
- Continuous delivery of value through each Sprint.
- Continuous Improvement / Problem Detection & Resolution
- Retro as a “living ECO tool” for continuous improvement.
- Daily Scrum as a mechanism to surface impediments early.
When you see questions about meetings inside a Sprint, timeboxes, feedback loops, inspect & adapt, they are often testing several of these domains – not just “Scrum theory” in isolation.
Related articles: Scrum Roles and Responsibilities
• coming soon
Scrum Artifacts