The (Mostly) Straightforward Guide to Sprint Ceremonies
You show up to your first day as a product manager, software engineer, or designer, and you’re welcomed onto your team. Someone tells you that they’ll add all the ceremonies to your calendar. All of a sudden, your calendar is full of meetings like “Sprint Planning” and “Product Backlog Refinement” and “Retro.” You’re not totally sure what these are, but you accept the invitations anyway and hope you’ll learn as you go. But even when you attend these meetings, everyone seems to be speaking the same language—except you.
Sprint ceremonies are a series of regularly conducted rituals that happen over the course of a sprint. Teams will almost always have each of the ceremonies every sprint. These rituals usually occur during meetings, although some teams conduct them asynchronously. During these ceremonies, teams will
- Plan for the current sprint
- Prepare for the following sprint
- Check in daily on progress toward sprint goals
- Review the work completed during the sprint
- Share with other teams and stakeholders new features or functionality achieved
Learning about sprint ceremonies can feel confusing. Most companies base their set of rituals on Agile/Scrum, but because each company tweaks them a little (or a lot), the ceremony may have a different name; it may follow a different format; it may have different attendees; it may have different goals. Even more mystifying, within a company, ceremonies may be different from team to team!
It’s always okay to ask questions about the format and agenda of a ceremony. Because each company and team adapts ceremonies to their own purposes, you’re not expected to know the ins and outs of every ceremony your team performs from day 1. Even if you’ve been a product manager or software engineer before, chances are your new gig will do things at least a little differently.
Have questions about sprint ceremonies but aren’t sure who to ask?Look for another perspective on the way your team does sprint ceremonies. Sign up for Merit and ask mentors from product, engineering, and design about how they and their teams do sprints.
Most sprint ceremonies tend to follow the same patterns across organizations, even if the exact name and details may vary. Different methodologies, like Scrum, Kanban, and lean startup all use specific terminology, phrases, and guidelines for sprint ceremonies. For example, many articles on sprint ceremonies will refer to the “product owner” or “scrum master," but in this article, we refer only to product managers, software engineers, engineering managers, and designers.
Many companies hold two-week sprints, so each of these rituals would repeat on a biweekly cadence. Some companies may have one-week sprints, while others may have three-week sprints.
The details boil down to how your company has decided to apply textbook methodology to their org.
The six sprint ceremonies you should know are
- Sprint planning
- Daily standup
- Backlog grooming
- Sprint review
- Sprint retrospective
- Sprint demo
The sprint begins with planning, followed by refinement. The sprint ends with a review, retro, and demos. Standup happens daily throughout the sprint.
Sprint Planning
Also known as: This is one of the rare examples that is usually only called one thing.
What’s the goal: Decide which tasks (usually organized as “tickets”) will be worked on during the upcoming sprint
Who attends: Product manager, engineering manager, designer, software engineers
How to prepare and contribute: If you’re the product manager, you’ll want a set of well-groomed (see below) and prioritized tickets. If you’re another member of the team, you’ll want to be familiar with the highest prioritized tickets (which will be at the top of the backlog) and come with questions on anything you’d like more information or context about.
How it usually plays out: During sprint planning, the team commits to the body of work (typically, a set of tickets) that they will try to complete by the end of the sprint. The team believes that this set of tickets is achievable within the sprint—usually one to three weeks, depending on the company—and will move them to a specific achievement, goal, or iteration on whatever projects or products are in progress.
Daily Standup
Also known as: Daily scrum
What’s the goal: Review status of each team member’s work for that day and any potential challenges
Who attends: Product manager, engineering manager, designer, software engineers
How to prepare and contribute: Write down briefly everything you did yesterday and everything you plan to do today. Note anything that might stop you from making progress (also called “blockers”).
How it usually plays out: Every day, the members of the team gather for ten to fifteen minutes to review
- what was accomplished yesterday
- what will be worked on today
- if any unforeseen issues (like an urgent bug or someone being out sick) will lead to adjustments to the sprint scope
Some teams may review the board of tickets (sometimes called "walking the wall") or go round robin where each person takes a turn providing updates.
If any blockers come up, the engineering manager, tech lead, or product manager will help figure out how to get you “unblocked.”
If your team is remote, you may do standup asynchronously, where everyone posts their updates in a centralized location, like a Slack channel, and people can follow up and ask questions in that place.
Backlog Grooming
Also known as: Product backlog grooming, product backlog refinement (PBR), backlog refinement
What’s the goal: Review the top backlog items to prepare them for the coming sprint
Who attends: Product manager, engineering manager, designer, tech lead, and software engineers
How to prepare and contribute: Preparation depends on your role:
- If you’re a software engineer, review the top items in the backlog. Come with any questions you have.
- If you’re a product manager, ensure you’re maintaining a well-prioritized backlog that can be groomed in the meeting.
- If you’re a designer, be prepared to answer any questions on the user experience or interactions for any upcoming front end work.
How it usually plays out: The idea of “grooming” tickets basically means to ensure that each ticket has enough information that a software engineer can begin working on the ticket. This means the team
- reviews the requirements on the ticket
- discusses the coding implementation
- possibly “points” the tickets to estimate level of effort
- checks the ordering of tickets to make sure they are prioritized correctly
Sometimes, backlogs are organized into user stories written by the product manager, and during grooming, the engineering team breaks the user story down into smaller, more manageable engineering tasks.
Sprint Review
Also known as: Iteration review
What’s the goal: Answer the question: “Did we achieve the goal we set out in sprint planning?” and ask for feedback from stakeholders
Who attends: Team stakeholders, product manager, engineering manager, software engineers, designer (sometimes only the product manager, engineering manager, and stakeholders attend this meeting)
How to prepare and contribute: Like backlog grooming, your prep work will depend on your role:
- If you’re the product manager, be prepared to answer any questions about the work completed and update any metrics you’re responsible for tracking.
- If you’re a software engineer, be ready to demo your work in front of an audience—who might ask questions about how or why you did something.
- If you’re an engineering manager, think about any challenges your team faced or might face in the coming sprint and be able to explain how that affects the team’s velocity.
- If you’re a designer, be familiar with how the engineering team implemented your designs.
How it usually plays out: The product manager will review what the team completed during the sprint, and engineers may take turns performing demos. The stakeholders will ask questions and provide feedback, which will allow the team to make iterative changes the following sprint. Stakeholders and leadership may also ask for progress updates on longer-term initiatives and to review any metrics the team is responsible for, like usage, adoption, or engagement.
Sprint Demos
Also known as: Like sprint planning, this one is typically only called “demos.”
What’s the goal: Share, company-wide, any significant milestones, updates, or changes to the product
Who attends: All software teams (that is, all product managers, engineers, and designers) and external teams like members of the sales, marketing, account management, and customer success teams
How to prepare and contribute: Make sure you’ve documented and shared your progress for the sprint with the rest of the team. If you’re a software engineer and your code is still living in a developer environment, make sure that other people can access it in case they need to demo your work.
How it usually plays out: Teams will often designate one "presenter" to represent the team’s progress for the sprint. Each team then takes a turn demo-ing their progress over the previous sprint. These demos can help most external teams plan and execute their work by letting
- support teams know to update their documentation
- sales teams to know what features are available to sell
- marketing teams to know which features might be launching soon
- account management teams to know which new features to highlight with customers
Sprint Retrospective
Also known as: Retro
What’s the goal: Reflect on the sprint and discuss what went well, what could have gone better, and what to do differently in the next sprint. Retros include feedback on topics like
- How work was completed
- Any problems that cropped up
- Concerns or questions about strategy, direction, or priorities
Who attends: Product manager, engineering manager, designer, software engineers
How to prepare and contribute: Think about the past sprint. You may want to look through your calendar, any messages over Slack or Teams, and tickets you worked on.
How it usually plays out: Each team member either says out loud or writes down (often using software like Miro or Easyretro) what they liked, learned, disliked, and had questions about. The team will
- say each item out loud
- vote on which they’d like to discuss
- allocate 5-10 minutes to discussing the highest voted items
Each discussion should culminate with an assigned action item that should be completed by the end of the next sprint. The purpose of retros is to focus on continuous improvement, not to assign blame, complain, or air grievances. At the end of retros, teams should feel like they’ve come closer together as a team and know how to be even better next sprint.
If you’re still curious about sprint ceremonies, it’s helpful to ask a variety of people in tech; since each company adapts these rituals, no two companies conduct them exactly like. When you sign up for Merit, you can ask multiple mentors—for free—about their experiences.