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.
