The agile philosophy helped to revolutionize how work is done, from software development and beyond. An essential part of putting agile into practice is meetings, or “ceremonies”. In scrum – the most popular agile practice – scrum meetings provide transparency and regular communication with the team.
What are scrum ceremonies?
Scrum meetings are when the scrum master, product owner, and development team meet to plan work, discuss work in progress, gather feedback, and more. Not every agile scrum team needs to practice all scrum meetings, and a team doesn’t necessarily have to be a scrum team to practice scrum meetings. The following are some agile scrum meetings that help to empower teams of all sorts.
Note: A number of these ceremonies come from the practice of scrum, which is an iterative, time-boxed approach to implementing agile. The concepts behind these ceremonies can be applied to other forms of agile like kanban or lean. A "sprint" is a scrum-specific term that is, typically, a fixed-length event of one month or less to create consistency. Other forms of agile use the more generic term "iteration" to indicate a time-boxed period of development. Ceremonies often vary in duration depending on the length of the sprint or iteration.
Sprint planning
When practicing scrum, the sprint planning meeting is held at the beginning of the sprint and is where teams identify what can be delivered in the sprint and how that work will be achieved. At the end of the planning meeting, every scrum member needs to be clear on what can be delivered in the sprint and how the increment can be delivered.
Attendees: Development team, scrum master, product owner
When: At the beginning of a sprint.
Duration: Usually around one hour per week of iteration. e.g. a two-week sprint kicks off with a two-hour planning meeting.
Agile framework: Scrum. (Kanban teams also plan, of course, but they are not on a fixed iteration schedule with formal sprint planning)
Purpose: Sprint planning sets up the entire team for success throughout the sprint. Coming into the scrum meeting, the product owner will have a prioritized product backlog. They discuss each item with the development team, and the group collectively estimates the effort involved. The development team will then make a sprint forecast outlining how much work the team can complete from the product backlog. That body of work then becomes the sprint backlog.
Use the sprint planning meeting to flesh out intimate details of the work that needs to get done. Encourage team members to sketch out tasks for all stories, bugs, and tasks that come into the sprint. Foster discussions and gather consensus on the plan of action. Effective planning significantly increases the team's chances of success by meeting the commitments of the sprint.
Daily stand-up
The daily stand-up – a.k.a. daily scrum – is a short, 15-minute (or less) daily meeting to discuss progress and identify blockers. Attendees are urged to participate while standing to help keep the meeting short.
Here’s a daily stand-up template to help your team start.
Attendees: Development team, scrum master, product owner
When: Once per day, typically in the morning.
Duration: No more than 15 minutes. Don't book a conference room and conduct the stand-up sitting down. Standing up helps keep the meeting short!
Agile framework: Scrum and kanban.
Purpose: A daily stand-up is designed to quickly inform everyone of what's going on across the team. It's not a detailed status meeting. The tone should be light and fun, but informative. Have each team member answers the following questions:
- What did I complete yesterday?
- What will I work on today?
- Am I blocked by anything?
There's implicit accountability in reporting what work you completed yesterday in front of your peers. No one wants to be the person who is constantly doing the same thing and not making progress.
Some teams use timers to keep everyone on track. Others toss a ball across the team to make sure everyone's paying attention. Many distributed teams use videoconferencing or group chat to close the distance gap. Your team is unique. Your stand-up should be, too!
Sprint review
The sprint review, also called an iteration review, is where the scrum team meets to reveal what was accomplished during the sprint. A development team shows which backlog items are “Done” to stakeholders and teammates, who can then give feedback.
Attendees: Development team, scrum master, product owner
When: At the end of a sprint.
Duration: Typically 45 minutes per week of iteration - e.g. a 90-minute retrospective after a two-week sprint.
Agile framework: Scrum and kanban. Scrum teams do sprint retrospectives based on a fixed cadence. Kanban teams can benefit from occasional retrospectives, too.
Purpose: A 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 scrum 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 quality bar to be considered complete and ready to showcase in the review.
At Atlassian, we take a casual approach to sprint reviews and give them a celebratory feel. We gather around a team member's desk and watch them demo their new feature. It's not uncommon to hear clapping throughout the office!
Sprint retrospective
A sprint retrospective is a meeting to review what was successful during the sprint and what can be improved upon. Agile teams can specifically review team dynamics, processes, and tools, then create plans to improve the way the team works.
Here’s a team playbook on how to run retrospectives.
Attendees: Development team, scrum master, product owner
When: At the end of a sprint.
Duration: Typically 45 minutes per week of iteration-e.g. a 90-minute retrospective after a two-week sprint.
Agile framework: Scrum and kanban. Scrum teams do sprint retrospectives based on a fixed cadence. Kanban teams can benefit from occasional retrospectives, too.
Purpose: Agile is about getting rapid feedback to make the product and development culture better. Retrospectives help the team understand what worked well and what didn't.
Retrospectives aren't just a time for complaints without action. Use retrospectives to find out what's working so the team can continue to focus on those areas. Also, find out what's not working and use the time to find creative solutions and develop an action plan. Continuous improvement is what sustains and drives development within an agile team, and retrospectives are a key part of that.
Even if things are going well across the team, don't stop doing retrospectives. Retrospectives provide ongoing guidance for the team to keep things going well.
In conclusion…
Some people think agile ceremonies magically make a team agile. They're wrong. A team's agility is built on solid engineering practices, a tactical and strategic approach to change, and great team collaboration. Agile ceremonies simply facilitate communication across the team.
Ready to start? Learn how to use sprints in Jira