The guide to Agile Ceremonias for Scrum
Ceremonies are regular events held by Scrum teams. ‘Agile’ is a broad word describing a different way of working with shorter, time-boxed cycles for releases.
Under the broad umbrella of agile, Scrum is one of the most popular approaches that teams use to organise their work and releases.
Each short iteration of work in Scrum is referred to as a sprint. A sprint is normally a 2 week period where the team focuses on a small slice of work.
The idea is that everyone focuses on 1 slice of work. And that slice is to be completed and shipped to the customer within that same sprint.
Scrum can be broken down into a few important elements:
This post will focus on the Scrum Ceremonies.
All of the 4 Scrum ceremonies help ensure the Scrum team stay focused on the slice of work they agreed to focus on in that sprint.
It helps the team with transparency about progress on the work they committed to finish and to raise any issues early before they become blockers.
Let’s have a look at each of the four agile ceremonies in Scrum:
1. Stand up (or daily Scrum)
Goal of the stand up: a brief check-in where the team can raise issues or communicate with the whole team face to face.
Who joins the daily stand up: Developers, Scrum Master, Product Owner
Outcome of daily stand up: the team raises any blockers, but doesn’t have to solve them. Ensure each team member is clear about what they are working on. Each team member should be able to answer these three questions:
- What did I complete yesterday?
- What will I work on today?
- Am I blocked by anything?
When to hold a stand up: daily
Tip: stand ups can be done by business teams and don’t always have to be face-to-face. Here’s a photo of Australian bank ANZ’s executive stand up in action:
fortnightly stand up mtg driving real change solving customer & staff pain points. #Agile in action & I learn a lot each mtg. Mostly that our @ANZ_AU team are committed, talented, customer obsessed & overall pretty awesome. We don’t get it all right but are committed to change. pic.twitter.com/LW9S48DhBE— Shayne Elliott (@ElliottShayne) March 8, 2018
And another pic from InsideIT’s stand up:
2. Sprint Planning
Goal of sprint planning: sprint planning helps the team prepare for what work is coming up next. The team discusses each item of work which has been prioritised by the Product Owner.
Who does sprint planning: Developers, Product Owner, Scrum Master
Outcome of sprint planning: that everyone knows what the sprint goal is and how they are going to achieve it. Make sure everyone understands what’s the overall vision or objective of the work.
The team will be comfortable with what work is available to be picked up in the next sprint. The team will discuss any impediments or opportunities and how they can optimise the way the work will be completed.
The team will also estimate the work and draw a line when it is estimated that the effort to complete the work exceeds the team’s capacity or historical velocity.
When to hold sprint planning: at the end of a sprint or very beginning of a new sprint.
Bonus: sometimes in sprint planning you will find things you won’t do, and that’s valuable too.
3. Sprint review
Goal of the sprint review: showcase the work completed and receive feedback from the Product Owner and relevant stakeholders.
Who joins the sprint review: Executive Sponsors, Developers, Scrum Master, Product Owner
Outcome of the sprint review: each team member feels empowered by showcasing their work to the team. The team can celebrate their achievements. Executive team can ask questions. Product owner can provide feedback and check the work is of high quality and satisfies the user story. Works best with drinks and cake.
When to hold a sprint review: at the end of each sprint.
Goal of the retrospective: honest discussion about what worked well and didn’t work well. Encourage self-improvement and transparency.
Who joins the retrospective: Developers, Scrum Master, Product Owner
Outcome of a retrospective: receive feedback from the team and seek to improve in the following sprint. The beauty of agile and Scrum is the fast feedback loop.
If something isn’t working well, it only hurts the team for a maximum of 2 weeks. It can then be addressed at the retrospective and action can be taken to address the issue before it gets out of hand.
The outcome should be a commitment from the team to focus on addressing areas that need improvement or continuing behaviours that benefit team health and/or velocity.
When to hold a retrospective: at the beginning of a new sprint, reflecting on a sprint that has just ended.
The common theme across these Scrum ceremonies is that they encourage team collaboration, transparency and communication.
In my experience, this is what truly makes agile a better way of working.
It’s not the story points or even the way the backlog is prioritised that makes a difference. The true game-changer of agile is that it helps teams with open and honest communication.
These agile/Scrum ceremonies won’t always work the same for every team.
However, they are a great way to facilitate conversation and encourage continuous improvement.