Purpose
Sprint ceremonies are where planning meets execution and reflection. Done well, they ensure the right work is chosen, the team understands commitments, and clients see progress transparently. Done poorly, they become repetitive status meetings that waste time and erode trust.
The purpose of this document is to provide a clear, repeatable method for conducting two key Agile ceremonies within Service Delivery: Sprint Planning and Sprint Review. Together, these sessions establish clarity on what will be done, validate progress against commitments, and identify adjustments for the next cycle.
This how-to is not an Agile textbook; it is a practical guide tailored to the realities of Service Delivery teams that manage diverse projects (design, development, QA, integrations). It ensures that sessions are structured, time-bound, and value-adding, with outputs that feed directly into execution.
Ultimately, this guide ensures that planning is about making commitments the team can keep, and reviews are about demonstrating progress with accountability. By following this structure, every sprint cycle builds client confidence and internal discipline.
Scope
This guide applies to all Service Delivery projects that follow sprint-based execution. Whether a project is software development, QA validation, or design iterations, sprint planning and review sessions are mandatory whenever tasks are organized into time-boxed delivery cycles.
Sprint Planning must be conducted at the start of every sprint cycle, typically lasting one or two weeks. It ensures the team aligns on scope, priorities, capacity, and commitments. Sprint Review must be conducted at the end of each sprint, providing the client and stakeholders with a transparent view of what was delivered, what remains pending, and what improvements are needed.
The guide applies to the following roles:
- Project Manager (PM): Facilitates the sessions, manages agenda, captures outputs.
- Technical Leads (Dev, QA, Design): Provide effort estimates, validate feasibility, and commit on behalf of their teams.
- Delivery Manager (DM): Observes adherence to framework and ensures discipline.
- Client Success Manager (CSM): Shares client-facing outcomes and captures feedback.
- Client Stakeholders (optional in reviews): Participate to validate delivered features and provide feedback.
This how-to does not apply to:
- Ad hoc support tickets or one-off bug fixes under 8 hours.
- Non-sprint project phases (e.g., sales, discovery workshops).
By defining scope clearly, this guide ensures that sprint ceremonies are used where they add the most value—structured delivery cycles—without burdening smaller engagements.
Sprint Planning – Step-by-Step Process
Sprint Planning sets the foundation for the sprint. The goal is to agree on what will be delivered and how it will be achieved, with realistic commitments based on capacity and priorities. This session must be structured, time-bound (max 2 hours for a 2-week sprint), and outcome-focused.
| Step | Action | Owner(s) | Output / Deliverable | Checkpoint |
| 1. Preparation | PM circulates agenda, reviews backlog, and confirms availability of team members. | PM | Agenda + groomed backlog | Sent 24 hrs before session. |
| 2. Review Prior Sprint | Quick review of what was completed vs. carried forward. | PM + Leads | Sprint completion % | Documented in MoM. |
| 3. Backlog Prioritization | Apply prioritization framework (VURD) to backlog items. | PM + Tech Leads | Ranked backlog | Visible on Jira/ClickUp. |
| 4. Capacity Check | Confirm availability of each team member (vacations, other commitments). | PM + DM | Capacity plan | Validated before task allocation. |
| 5. Task Selection | Select top-priority items that fit team capacity. | PM + Leads | Draft sprint backlog | Reviewed against baseline. |
| 6. Effort Estimation | Team estimates tasks (story points or hours). | Tech Leads + Team | Effort estimates recorded | Estimates logged in Jira/ClickUp. |
| 7. Commitment Confirmation | Team confirms commitments; DM validates realism. | PM + DM | Final sprint backlog | Agreed upon and documented. |
| 8. Documentation & Communication | PM shares finalized sprint backlog, goals, and definitions of done. | PM | Sprint plan doc | Circulated within 12 hrs. |
Sprint Planning is complete only when every task has a clear owner, deadline, and definition of done. Anything left vague becomes a risk during execution.
Sprint Review – Step-by-Step Process
The Sprint Review is not just a demo — it is a structured checkpoint where the team validates progress, gathers feedback, and aligns on next steps. The goal is transparency: the client should leave with a clear picture of what was achieved, what is pending, and how the plan will be adjusted.
| Step | Action | Owner(s) | Output / Deliverable | Checkpoint |
| 1. Preparation | PM circulates agenda and ensures all completed work is ready for demo. | PM + Tech Leads | Agenda + demo environment | Shared 24 hrs before session. |
| 2. Welcome & Agenda Recap | Briefly outline purpose and topics. | PM | Call agenda alignment | Client acknowledges. |
| 3. Demonstration of Deliverables | Show completed features, designs, or test results in live environment. | Tech Leads + Team | Demo of sprint deliverables | Client validates functionality. |
| 4. Review of Sprint Outcomes | Compare planned vs. completed items, note carried-forward tasks. | PM | Sprint completion % | Logged in MoM. |
| 5. Risk & Issue Discussion | Highlight blockers faced, unresolved issues, and mitigations. | PM + QA Lead | Risk/issue log | Updated in Jira/Confluence. |
| 6. Client Feedback | Invite client stakeholders to share feedback or new requests. | CSM + Client | Feedback notes | Captured in MoM. |
| 7. Next Steps & Alignment | Outline priorities for next sprint and confirm handover actions. | PM | Draft backlog for next sprint | Client aligned. |
| 8. Documentation & Closure | PM shares MoM within 12 hrs, including decisions and action items. | PM | MoM + updated backlog | DM reviews completeness. |
Sprint Review is complete only when the client has confirmed understanding of what was delivered, and all feedback has been documented for prioritization.
Closing Note & Cross-References
Sprint Planning and Sprint Review are the two anchor points of every delivery cycle. Planning ensures that commitments are realistic and aligned with capacity, while the review guarantees accountability and transparency. Together, they create a feedback loop that strengthens trust, reduces risk, and keeps delivery predictable.
This how-to guide ensures that both sessions are conducted with discipline: agendas circulated on time, outcomes documented, and client feedback integrated into the backlog. By following the structured steps, Service Delivery teams avoid common pitfalls such as vague commitments, missed handovers, or unstructured demos.
Cross-References in MIC:
- Guide – Task Prioritization & Work Allocation Guide (feeds into Sprint Planning for task selection).
- Framework – Service Execution Excellence Framework (provides the operational pillars applied during ceremonies).
- SOP – Escalation & Issue Resolution Workflow (applies when risks or blockers identified in reviews cannot be resolved internally).
Closing Rule: No sprint may begin without a documented Sprint Planning session, and no sprint may close without a documented Sprint Review session. These ceremonies are mandatory, not optional, for all Service Delivery projects that run in sprints.