Agile Delivery

Scrum Ceremonies

October 31, 2020
4 mins read
Ben Willmott

This post has been created to provide a simple overview of the five key Scrum ceremonies.

The time for each ceremony is a guide as this really depends on the size of the team or project type. There is plenty of further reading on the techniques for running these ceremonies as they’re standard across any project using Scrum.

Sprint Planning 

Daily Stand-ups 

Story Refinement 

Sprint Demo

Sprint Retrospective 

Sprint Planning

When: Day one of the sprint 

Team members required: The full team, so typically the Scrum Master, Engineers, QA, Product Owner, UX & Product Designers (The development team)

Duration: Typically an hour if the correct preparation has happened in the previous sprint 

Purpose: Sprint planning sets the vision or goal for the sprint so the full team are aligned from day 1. So what do we want to achieve by the end of this sprint?

Prior to this meeting, the backlog of stories will be updated into the current priority order by the Product Owner and the high priority stories already refined to an agreed definition of ready.

The development team then discuss each story in more detail so they can collectively estimate it or assign complexity (Story points). You can add the required subtasks to the story.

The team continues to assign the stories until they’re at capacity. These chosen users stories then become the sprint backlog

Things to note: It’s the doers who decided on the stories effort or complexity and what they can commit to within a sprint, not the Product Owner or Scrum Master.

This is an opportunity for any final questions before sprint backlog is agreed. Make the most of it, so sketch out ideas, push back if don’t have what you need.

Daily Stand-Ups

When: Every day of the sprint apart from day 1 where you do sprint planning. Usually first thing in the morning.

Team members required: Development team and typically the Scrum Master. Product Owner being present is advised.

Duration: 15 minutes, but sometimes adjusted if agreed by the team

Purpose: Quick updates from the Development team to share progress, plans, and any issues or help needed. Used to keep the team all in sync on everyone’s progress, encourage transparency and a time to ask for help!

Things to Note: If you’ve agreed at the start of the project the stand up will be 15 minutes, then stick to 15 minutes.

It’s not a status meeting, so should be brief and ideally a little fun to start the day in a good frame of mind! If a team member can’t join (late in) start without them.

The stand-up time should never move unless agreed by the whole team.

The stand up is run by the development team, not the Scrum Master. The Scrum Master is there to hear of any impediments and support the team and Scrum process

Story Refinement

When: Once mid-sprint 

Team members required: Scrum Master, Product Owner and Development team 

Duration: Typically an hour

Purpose: A chance for the team to come together and review the highest priority items in the backlog not yet worked on.

The Product Owner presents the latest stories and explains the reasons why they’re top of the backlog and what they expect the new items will need to achieve.

Things to Notes: Refinement isn’t just the Product Owner speaking, this is a chance for the team to ask questions, potentially adjust the item in terms of how it could be built.

Use this time to draw up potential solutions and make sure there is lots of discussion on the need and approach.

Sprint Demo

When: Last day of the sprint 

Team members required: Scrum Master, Product Owner, Development team and project stakeholders

Duration: Typically 1 hour

Purpose: Sprint review is a time to showcase the work of the team. They can be in a casual format like “demo Fridays”, or in a more formal meeting structure.

This is the time for the team to celebrate their accomplishments, demonstrate work finished within the iteration, and get immediate feedback from project stakeholders.

Remember, work should be fully demonstrable and meet the team’s Definition of Done to be considered complete and ready to showcase in the review.

Things to Note:Agree early with the client and then team the format of the sprint demo. It can be a round table demo if that’s suitable, or some clients it has to be a more formal presentation.

Check early to avoid any last-minute rushes.

If it takes the team longer than 30 minutes to an hour to prepare for the demo, there is probably something wrong.

The works completed should always be in a ready state so if this is not the case, discuss why in the retrospective.

Sprint Retrospective

When: Last day of the sprint 

Team members required: The development team, Scrum Master and Product Owner

Duration: Typically 1hr

Purpose: A chance for the team to review what went well, what didn’t in the last sprint and what should they start doing in the next sprint.

The retrospective is critical for continuous improvements and ongoing engagement of the team.

Things to Notes: This should be the team only, so no management or stakeholders. This is to allow the team to speak freely and focus on how they can improve.

Take turns to facilitate the ceremony, so don’t just rely on the Scrum Master. Keep it fresh by trying different retrospective approaches.

It’s fundamental that the learnings from the retrospective are implemented. Not doing so will result in the team quickly losing faith and the improvements curve will decline.

Ben Willmott
Ben is Head of Agile Practices at the London based creative agency Karmarama where he creates bespoke ways or working for his clients and teams. Ben is also the founder of The PPM Academy specializing in coaching Project Management, Agile Delivery and how to be more productive at home and work.

More Blog Posts

Project Management

Dealing With Change as a Project Manager

Change is going to happen whether you’re working with the Waterfall approach, Agile or any other delivery methodology. It just comes in different forms. But change shouldn’t be seen as a negative; change is about improvements, doing what’s right and what’s needed for the business and its users.

Read Article
Agile Delivery

An Introduction into Story Points

Story Points are often misunderstood and misused by teams and in some cases render them useless. In this post, we look at how you can educate the team on what Story Points are and how to use them.

Read Article
Agile Delivery

Waterfall vs Agile: What to Choose?

The Waterfall methodology or model is the traditional approach to project management. It breaks down the stages of a project into sequential phases.

Read Article

Register your interest in the PPM Course for early offers and updates