Agile Delivery

Scrum Ceremonies

Reading Time:
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 the founder of the PPM Academy, which provides training and coaching for project managers at all levels of experience.

More Blog Posts

Project Management

Repeatable processes and approaches to accelerate your performance.

Project Managers, Do you have repeatable processes and approaches?Do you know what's challenging and frustrating, having to start again for something you know you've done before?Trying to remember how you did it or where that file you created a few months back was stored can waste a lot of time.

Read Article
Project Management

Using neutral thinking to increase performance”

There have been so many times when I wished I had used neutral thinking as a Project Manager. ⁠⁠The most obvious is getting a crappy email from a client or a not particularly helpful teammate or manager, and I’ve sent an angry or defensive reply straight away.

Read Article
Project Management

How to turn a problem into a solution and keep your client happy simultaneously.

No one likes a problem, and in some cases, the fix needed cannot be done for some time but with a client demanding change, this can be difficult to manage.Whether you work in an agency or client side, it doesn’t matter. Managing expectations is problematic as to get the expected solution; you might be held back by a lack of knowledge/skills, capacity in the team or just the budget or approval to do it.

Read Article

Interested in the coaching programme? Book a FREE 1-2-1 Consultation With Ben Willmott, (subject to application)