The 5 Scrum Ceremonies Explained for Remote Teams

Scrum is one of the most popular agile frameworks for product development. In fact, 68% of teams self-identifying as agile say they practice some form of Scrum, which means there are thousands of teams around the world practising the five Scrum ceremonies week in, week out.

Scrum teams are a bit different from regular teams because their work is organized around a series of sprints – 2-4 week periods of work – during which they work on small and discrete increments of work to get quick feedback from stakeholders. Within each sprint are a number of Scrum ceremonies or Scrum meetings that add structure to a team’s work.

Sprints include Scrum ceremonies – for inspecting and adapting the product. And each Scrum team may include a Scrum Master, a Product Owner and numerous developers or designers. Typically, a Scrum team consists of three to nine people in total.

In this guide we cover the five Scrum ceremonies that make up a Sprint:

👥 Participants: Developers, Scrum Master, Product Owner
⏰ Timing: The Sprint Planning meeting occurs at the start of the sprint. It can last anywhere from one to two hours for a two-week sprint. According to the Scrum Guide, the maximum length of Sprint Planning is eight hours if you run the rare one-month sprint. In reality, how long sprint planning takes may vary based on the complexity of your product backlog.

During Sprint Planning, the Scrum team commits to the tasks they will complete in the upcoming sprint. They do so by moving items one at a time from the Product Backlog—a collection of all tasks that could be done—to the Sprint Backlog or simply the Todo list for that sprint.

The Product Backlog is a prioritized list of all the things a team could do. These tasks are often referred to as User Stories or simply ‘Stories’. Sprint planning keeps the team focused on what the team should do during the next sprint, by pulling the highest priority stories into the Sprint Backlog.

As the team selects tasks for the sprint, they clarify what each item means and who owns it. Sprint Planning finishes when the team is happy that the amount of work selected is roughly equivalent to the length of their sprint. From then on, the tasks in the Todo column become known as the Sprint Goal.

The product owner’s task is to prioritize the Backlog column before this ceremony starts, with the most critical and urgent tasks appearing at the top.

Sprint Planning only works when everybody can see the Product Backlog and the Scrum Board or Sprint Board. For a remote team, this means you will probably need to use a virtual Kanban tool like Trello, Jira, GitHub, or Confluence. Your Sprint Planning meeting might involve the Product Owner sharing their screen so everyone can follow along with the tasks under review.

Consider breaking longer meetings into two to avoid unbearable lengths of time at the screen. Hold one ceremony to review stories on the backlog and another to agree on which ones to pick for the next sprint.

Lastly, try to get people prepared in advance by asking them to read through the top of the Product Backlog and leave their initial feedback on items. This approach ensures you can use the time spent together for discussions and decisions instead of information exchange.

👥 Participants: Developers, Scrum Master, Product Owner
⏰ Timing: Same time and place every working day of the Sprint, no longer than 15 minutes.

The Daily Scrum is a short, daily ceremony that helps team members share progress, unblock each other, and sync-up on work. Because it brings the whole team together every day, you can share and remove obstacles quickly so everyone can continue in flow toward the Sprint Goal.

Having a dedicated time to remove blockers, the Daily Scrum minimizes distractions throughout the day so team members have more time for deep work.

During the Daily Scrum, every developer typically answers some version of these three standup questions:

To make sure the ceremony doesn’t run over 15 minutes, the Scrum Master cuts short topics that trigger a discussion. Sometimes the Daily Scrum is also referred to as a Daily Standup. The idea being that if everyone is standing up for the meeting, it keeps it short, sweet, and task-oriented.

💡 Funfact: While most people think the three Daily Scrum questions are official practice, the Scrum Guide (of 2020) doesn’t mention them—nor any other questions. Its only mandate is that developers can “select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.”

🤔 Looking for a different way to run your meeting? Try Parabol’s Online Standup Tool or discover 14 formats for better daily standups.

Remote teams might need to take an asynchronous approach to the Daily Scrum if employees are scattered across the world. Real-time gatherings on video chat might be impractical, requiring some team members to switch to night shifts. Technology might help you make the transition to async Daily Scrum meetings. You could do this manually in Slack or Microsoft Teams, or use a bot to help you out.

If timezones are no issue, we recommend getting together on a video call and interacting in real-time. The drawback of going fully asynchronous is that you can easily lose sight of the human side of working together, but a video call lets you really feel part of the team.

McKinsey consultants suggested actually making the Daily Scrum LONGER by reserving the first half for questions and the second half for problem-solving. But we recommend keeping it short and action-oriented. Think of the Daily Scrum like checking the pulse of your work together rather than deeply inspecting it, because that’s what retrospectives are for.

👥 Participants: Developers, Scrum Master, Product Owner, Project Stakeholders
⏰ Timing: The Sprint Review meeting occurs at the end of your sprint. It usually lasts 30–60 minutes. According to the Scrum Guide, the recommended maximum is four hours for a one-month sprint.

During the Sprint Review, the Scrum team shows what they accomplished during the sprint to get feedback from project stakeholders. You’ll determine if you met the Sprint Goal you set in the Sprint Planning meeting and discuss how to improve the product further in future sprints. By the time the Sprint Review comes around, teams should have a working piece of software or product to show off. That’s why the Sprint Review is also sometimes known as the Sprint Demo.

Sprint Reviews let stakeholders can give feedback early and often, instead of rarely and late. When the latter happens, it’s harder to pivot, or only at great cost – in resources and developer goodwill.

The heart of this ceremony is a demonstration of actual product functionality based on the tasks from the sprint, followed by a discussion of any significant problems encountered by the team. This makes Sprint Reviews qualitatively different to Sprint Retrospectives.

The feedback from this ceremony gets converted into new items in the Product Backlog which you can prioritize and discuss during the next Sprint Planning meeting.

Zoom fatigue is real, so do as much asynchronous preparation as you realistically can. In a remote team, nobody will complain about less time spent in a virtual meeting. 

Before getting together in real-time, team members can asynchronously document the product increment by recording a Loom video demonstrating the working features. Then host a synchronous team meeting for further discussion of everyone’s feedback. This saves valuable synchronous time for discussion rather than show-and-tell, and helps you to create a library of product increment demos that other team members can refer back to if they need to.

Also, think of new ways to keep stakeholders engaged during the demos without generating extra work for the team. For example, if you have clips of user feedback or video of people trying the increment out, use excerpts from those during the demo to add variety.

👥 Participants: Developers, Scrum Master, Product Owner (optional)
⏰ Timing: As a general rule, take 30–45 minutes for each week of your sprint. The retrospective of a two-week sprint should last roughly one hour.

The Sprint Retrospective helps teams build a habit of continuous process improvement. During this ceremony, the Scrum team figures out what they can improve by inspecting how the last sprint went. Individuals, interactions, processes, tools – anything is up for review and discussion. Also, take time to celebrate what went well – give kudos to a colleague, and discuss how to replicate successes in the future. Like the Sprint Review, it takes place at the end of the Sprint, but its focus is on processes, not the product.

During a Retrospective, all team members first suggest topics for discussion, usually by writing their thoughts down on reflection cards. You then group these into common themes and the whole team votes on which ones they want to discuss. This process determines which items to discuss in detail and in what order.

Ideally, the reflecting and voting part happens anonymously so that people feel comfortable sharing their ideas and feedback. That’s much easier to achieve when working remotely because there are tools that have those features built right in.

Online tools can inject a lot more structure into the process of running Sprint Retrospectives. Traditionally, a Retrospective might have been run using a whiteboard and sticky notes. At the end of your meeting, all your reflections would go straight into the trash can. But tools like Parabol give teams structure, ensure follow-up tasks are documented, and automatically summarize your meetings so you can spot recurring trends.

Remote teams can also try running Sprint Retrospectives entirely asynchronously. This is great when you’re stretched across time zones and gives more time for reflection and thoughtful responses.

Here’s how you can run this ceremony asynchronously with Parabol:

This is what a Sprint Retrospective looks like asynchronously, spread across one sprint.

Before you go all-in on an asynchronous Retrospective, we recommend you try a hybrid version first. Collect reflections asynchronously, then run the grouping, voting, and discussion parts of the ceremony synchronously.

👥 Participants: Product Owner, Developers
⏰ Timing: It’s complicated…

During Backlog Refinement, you add more and more details to your Backlog items so that they’re in great shape when you pick candidates for the next sprint during Sprint Planning. Those details may include a clear User Story, Acceptance Criteria and estimated effort.

Unlike the other four ceremonies, there’s no strictly defined time and place for Backlog Refinement. It’s meant to happen continuously throughout the sprint, but some teams opt for a weekly refinement meeting, while others do it several times per week. As a rule of thumb: The less experienced your team or the less time you’ve worked together, the higher the frequency of backlog refinement should be.

During this ceremony, you take items from the top of the ordered Product Backlog and turn them into user stories—an explanation of a product feature written from the end-user’s perspective.

You continue doing this until you have enough stories ready for your next sprint. You can also use this meeting’s time to break down large bugs into smaller elements that fit into a sprint.

Some teams also run Sprint Poker estimation meetings where they take items from the Product Backlog and estimate the effort they will require to complete. This helps teams to understand how large or small an item is during Sprint Planning. Having clear estimates helps to make sure the Sprint Goal is realistic and prevent over-shooting or under-achieving on goals.

Because of the virtual collaboration tools remote teams use, you can easily allow everyone to add to the Product Backlog throughout the sprint, not just during the official ceremonies. This practice helps to keep the Backlog up to date. You can also let bots help with this task by automatically reporting – through Slack or other messengers – when items in the Backlog are going “stale” because they haven’t been updated for a long time.

There are tools on the market that can help you running Sprint Poker estimation if that’s something your team does as part of your backlog refinement.

When working remotely, make sure to have an established template for entering items into the Backlog to keep it from descending into chaos.

Two recommendations from us:

Remote teams need to have the same understanding of their Scrum ceremonies as teams working in an office. And it’s not just the Scrum Master who is responsible for making Scrum ceremonies a success.

Scrum teams are self-managing, meaning the team is collectively responsible for enhancing and improving Scrum ceremonies.

The Scrum Guide wasn’t written with remote teams in mind, so some of the advice included is broad and generic. Remember that Scrum is a framework. It gives you a blueprint for how to help your team rapidly improve and work better together. But it’s not prescriptive.

It’s up to you and your team to evolve your own ways of running these ceremonies – remotely or in-person – that work best for you.

If you found this article helpful, why not bookmark it or share it with other team members to ensure everyone’s aligned on the why, how, and when of your virtual Scrum ceremonies.