By Rahul Dhakate · PMP & PSM I Certified · 19 May 2026 · learnxyz.in
If you are studying for the PMP exam and come from a traditional project management background, Agile ceremonies can feel like a foreign language. Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective — the names are specific, the formats are prescribed, and the exam tests whether you know what happens in each one and why.
But understanding these ceremonies is not just an exam exercise. Because approximately 50% of the current PMP exam is Agile content, and because Agile ceremonies are the operational heartbeat of any Scrum project, getting these right is essential both for passing and for applying what you learn in real project environments.
I have run Scrum ceremonies across multiple teams throughout my career. I want to share not just the textbook definitions but the real experience — which ceremonies teams found genuinely valuable, which ones they resisted, and what a retrospective looked like when it actually changed something.
Contents
Ceremony 2: Daily Scrum (Daily Standup)
Ceremony 4: Sprint Retrospective.
What the PMP Exam Tests About Ceremonies.
What Are Agile Ceremonies?
Agile ceremonies — also called Scrum events or rituals — are the structured, time-boxed meetings that form the rhythm of a Scrum sprint. They exist to create regular opportunities for inspection and adaptation — the two core principles of empirical process control that Scrum is built on.
Every ceremony has a defined purpose, a defined attendee list, and a defined maximum duration (time-box). The time-boxing is not a bureaucratic rule — it is a discipline that keeps teams focused and prevents meetings from expanding indefinitely. A meeting that always runs over its time-box is a signal that preparation is insufficient or the format is being misused.
There are four core Scrum ceremonies, corresponding to the four key events in every sprint:
Ceremony 1: Sprint Planning
| Sprint Planning Duration: Maximum 8 hours for a one-month sprint (proportionally shorter for shorter sprints) Attendees: Product Owner, Scrum Master, entire Development Team Determine what work will be done in the upcoming sprint and how the team will accomplish it |
Sprint Planning is where the sprint begins. The team gathers to answer two questions: what can we deliver in this sprint, and how will we do it?
The Product Owner presents the highest-priority items from the product backlog — the ordered list of all work to be done on the product. The Development Team selects the items they believe they can complete within the sprint, based on their capacity and their understanding of the work. The selected items become the Sprint Backlog — the team’s commitment for the sprint.
In the second part of Sprint Planning, the team breaks the selected backlog items into tasks and discusses the technical approach. The goal is for every team member to leave Sprint Planning with a clear understanding of what they are building and how it connects to the sprint goal.
Sprint Planning is the ceremony I found most valuable in practice. When done properly, it aligns the entire team — developers, QA, BA — around the same understanding of what will be built and why. The effort invested in Sprint Planning pays back throughout the sprint in reduced confusion and fewer mid-sprint surprises.
Ceremony 2: Daily Scrum (Daily Standup)
| Daily Scrum Duration: Maximum 15 minutes — held at the same time and place every day Attendees: Development Team (Scrum Master facilitates; Product Owner optional) Inspect progress toward the Sprint Goal and adapt the daily plan |
The Daily Scrum is a short daily synchronisation meeting for the Development Team. The classic format uses three questions for each team member: what did I do yesterday that helped the team meet the Sprint Goal? What will I do today? Is there anything blocking my progress?
The Daily Scrum is not a status report to the manager. It is a peer coordination meeting — team members talking to each other, not reporting upward. The Scrum Master attends to facilitate and to track impediments, but does not direct the discussion or ask the questions. The conversation belongs to the team.
In my practice, I ran the formal morning Daily Scrum with the core internal team — and then held a second, brief synchronisation meeting at the end of the day, specifically with the onsite or external team. This end-of-day closure meeting was one of the most valuable communication tools I used. It served as a checkpoint — confirming what had been completed during the day, surfacing any blockers that had emerged, and ensuring that any cross-team dependencies were on track before the team signed off for the day.
This is not a standard Scrum practice, but it reflects a real-world adaptation for distributed teams working across time zones. The formal Daily Scrum keeps the internal team aligned. A brief end-of-day sync keeps the broader project aligned across boundaries.
For the PMP exam: the Daily Scrum is time-boxed to 15 minutes. It is not a problem-solving meeting — issues that require detailed discussion are taken offline after the standup ends. If the team starts solving problems during the standup, the Scrum Master’s role is to note the issue and schedule a separate conversation.
Ceremony 3: Sprint Review
| Sprint Review Duration: Maximum 4 hours for a one-month sprint Attendees: Scrum Team (Product Owner, Scrum Master, Development Team) plus invited stakeholders Inspect the increment produced during the sprint and adapt the product backlog based on feedback |
The Sprint Review is a working session, not a formal presentation. The Development Team demonstrates the working software produced during the sprint to stakeholders — the Product Owner, business representatives, and any other relevant parties. Stakeholders interact with the product, ask questions, and provide feedback.
The critical distinction the PMP exam tests: the Sprint Review is about the product. It is not about the process, the team’s performance, or how the sprint was managed. It is an opportunity for stakeholders to see what was built, confirm that it meets their needs, and adjust priorities for the next sprint based on what they observe.
The Product Owner updates the product backlog based on feedback received in the Sprint Review. Items that were completed are marked done. New items surfaced by stakeholder feedback may be added. Priorities may shift. The output of the Sprint Review feeds directly into the next Sprint Planning.
One practical challenge I observed consistently: stakeholders often confuse the Sprint Review with a formal sign-off or acceptance milestone. In Scrum, the Sprint Review is an inspection point — not a formal approval gate. Acceptance happens at the product level over time, not sprint by sprint. Managing this expectation with business stakeholders is a real Scrum Master and Product Owner responsibility.
Ceremony 4: Sprint Retrospective
| Sprint Retrospective Duration: Maximum 3 hours for a one-month sprint Attendees: Scrum Team only — Product Owner, Scrum Master, Development Team (no external stakeholders) Inspect the team’s process, collaboration, and practices — and identify improvements for the next sprint |
The Sprint Retrospective is the ceremony that teams most commonly resist and treat as a formality — and it is also, when done correctly, the ceremony with the highest long-term value for team performance.
In my experience, the resistance is predictable. Retrospectives feel uncomfortable because they require honest self-assessment. Team members are asked to reflect on what went wrong, what could be improved, and what interpersonal or process friction is holding the team back. Many people default to vague positive statements — ‘good teamwork’, ‘nice sprint’ — to avoid the discomfort of genuine critique. The retrospective becomes a ritual box-ticking exercise rather than a real improvement conversation.
The most valuable retrospective I ran was one where we addressed a genuine schedule challenge directly. The project was running behind — specific milestones were slipping. Rather than allowing the team to avoid the topic, we put the timeline pressure on the table explicitly. The onsite team was asked to accelerate their delivery. This created a constructive but frank discussion about what was realistic, what the blockers were, and what the team could actually commit to.
The outcome was a piecemeal delivery approach — breaking the remaining work into smaller, more frequent deliverables rather than one large milestone. This gave the client visible progress, reduced integration risk, and allowed the team to recover the schedule incrementally. That retrospective outcome directly changed how the project was delivered. That is what retrospectives are supposed to do.
A retrospective that produces no action items is a failed retrospective. The point is not to vent or celebrate — it is to identify one to three specific, actionable improvements and commit to implementing them in the next sprint. If the same issues appear in retrospective after retrospective without being resolved, the Scrum Master has work to do.
The Relationship Between Ceremonies and the Sprint
Understanding how the four ceremonies fit together within a sprint cycle is essential for the PMP exam’s Agile situational questions.
| Sprint Phase | Ceremony | Triggers Next |
| Sprint begins | Sprint Planning — defines the Sprint Backlog and Sprint Goal | Daily work begins |
| During sprint — every day | Daily Scrum — inspects progress, adapts the daily plan | Next day’s work |
| Sprint ends — product review | Sprint Review — inspects the increment, updates the backlog | Retrospective |
| Sprint ends — process review | Sprint Retrospective — inspects the team’s process, identifies improvements | Next Sprint Planning |
| New sprint begins | Sprint Planning again — cycle repeats | Sprint execution |
What the PMP Exam Tests About Ceremonies
- Time-box values: Sprint Planning max 8 hours (one-month sprint). Daily Scrum max 15 minutes. Sprint Review max 4 hours. Retrospective max 3 hours. For shorter sprints, time-boxes are proportionally reduced.
- Purpose distinctions: Sprint Review = product inspection. Retrospective = process inspection. These are frequently confused in exam questions. If a question describes the team reflecting on how they worked together, that is a Retrospective — not a Sprint Review.
- Attendee lists: The Retrospective is the only ceremony attended only by the Scrum Team — no external stakeholders. Sprint Review includes invited stakeholders. Daily Scrum is the Development Team’s meeting.
- Ceremony frequency: All four ceremonies occur once per sprint. The Daily Scrum occurs daily. No ceremony is optional — skipping any of them violates the Scrum framework.
- Impediment handling: The Scrum Master’s primary responsibility during the Daily Scrum is to track impediments and remove them. Impediments are not solved during the standup — they are noted and resolved separately.
PMP exam trap: The Sprint Retrospective happens after the Sprint Review but before the next Sprint Planning — not after Sprint Planning. The sequence is always: Sprint Planning → Sprint Execution (with Daily Scrums) → Sprint Review → Sprint Retrospective → next Sprint Planning.
About the Author
Rahul Dhakate is a PMP and PSM I certified project manager and product management leader based in Nagpur, India, with 20 years of experience managing software projects across BFSI, eCommerce, and enterprise software. He has facilitated Scrum ceremonies across multiple teams and organisations, including end-of-day synchronisation meetings with distributed onsite teams and retrospectives that produced concrete schedule recovery strategies on delayed projects. He writes at LearnXYZ.in to help working professionals understand both the theory and the real-world practice of project management.
Good Reads:
