Sprint Planning, Review, and Retrospective: What PMP Candidates Must Know

The Three Sprint Events That Drive Agile Delivery

Sprint Planning, Sprint Review, and Sprint Retrospective are the three Scrum events (beyond the Daily Scrum and the Sprint itself) that PMP candidates must understand deeply. Each serves a distinct purpose, involves specific participants, and produces defined outputs. PMI tests not just your knowledge of what these events are, but your judgment about how to handle problems that arise within them.

Sprint Planning: Setting the Sprint Up for Success

Purpose

Sprint Planning answers two questions: What can be delivered in this Sprint? and How will the chosen work get done? The entire Scrum Team participates — Product Owner, Scrum Master, and Development Team.

How It Works

The Product Owner presents the highest-priority items from the Product Backlog. The Development Team discusses each item, asks clarifying questions, and forecasts how many items they can complete. The team then crafts a Sprint Goal — a concise statement of what the sprint will achieve.

The Development Team decomposes selected backlog items into tasks and estimates the effort. This becomes the Sprint Backlog. The Product Owner does not dictate how much work goes into the sprint — the team pulls based on their capacity and historical velocity.

Time-Box

Sprint Planning is time-boxed to a maximum of 8 hours for a one-month sprint. Shorter sprints typically have shorter planning sessions — roughly 2 hours for a two-week sprint.

PMP Exam Tips

If a question describes the Product Owner pressuring the team to take on more work than they believe they can complete, the correct answer almost always involves the team maintaining their commitment based on capacity. The team owns the "how much" decision.

Sprint Review: Inspecting the Increment

Purpose

The Sprint Review is held at the end of the sprint to inspect the Increment and adapt the Product Backlog. This is not a status meeting — it's a collaborative working session where the team demonstrates what they built and stakeholders provide feedback.

Participants

The Scrum Team and key stakeholders attend. The Product Owner explains which backlog items have been completed (meet the Definition of Done) and which have not. The Development Team demonstrates the work and answers questions.

Outputs

The primary output is a revised Product Backlog. Based on stakeholder feedback and market changes, the Product Owner may reorder, add, or remove items. The team may also update release projections.

Time-Box

Maximum 4 hours for a one-month sprint.

Sprint Retrospective: Improving the Process

Purpose

The Sprint Retrospective is the team's opportunity to inspect itself and create a plan for improvement. It focuses on people, relationships, process, and tools.

Structure

A common retrospective format asks three questions:

1. What went well during this sprint?
2. What could be improved?
3. What will we commit to improving in the next sprint?

The team identifies the most important improvements and creates actionable items. These may be added to the Sprint Backlog for the next sprint.

Key Distinctions

The Sprint Review inspects the product. The Sprint Retrospective inspects the process. The exam may try to confuse these. Remember: Review = what we built. Retrospective = how we worked.

PMP Exam Scenario

If a question asks what a project manager should do when the team's velocity is declining and morale is low, the retrospective is almost always the right forum. This is where the team identifies root causes and owns the solution — not a top-down management directive.

Connecting These Events to PMP Domains

Sprint events touch multiple PMP domains. Sprint Planning relates to the Process domain (planning work, managing scope). Sprint Review connects to the People domain (stakeholder engagement, feedback). Sprint Retrospective ties to both People (team dynamics, conflict resolution) and Process (continuous improvement).

Practice answering scenario questions about sprint events with PMPprep's exam simulator. Knowing the theory is only half the battle — you need to build the judgment to apply it under exam pressure.