Some meetings are necessary. Others…aren’t.
You’ve probably attended both kinds of meetings at one time or another – eagerly participating in the former and suffering through the latter. Yet even effective meetings often devolve into repetition, circular discussion, and chit-chat.
Scrum ceremonies were designed to avoid all that. Since a Scrum team’s goal is to produce the highest business value in the shortest time, unnecessarily long meetings can kill their efficiency. For this reason, Scrum replaces “meetings” with highly effective and structured “ceremonies.”
Read a recent interview our VP of Marketing held with one of our team members. They discussed Meeting Your Business Goals with Scrum Ceremonies.
These Scrum ceremonies are:
- Sprint planning
- Daily standup
- Sprint review
- Retrospective
Each Scrum ceremony is designed to facilitate communication and planning while maintaining the team’s focus on productivity and efficiency. In this post, we’ll look at these ceremonies and how they keep your development team locked in and on track.
Sprint Planning
A sprint planning session is a Scrum ceremony occurring at the beginning of each sprint. Its purpose is to accomplish two things:
- Create a detailed plan for how the team will complete high-priority product backlog items
- Decide how much work they’ll commit to during the upcoming sprint
During sprint planning, user stories are discussed by the team in detail. These user stories are broken down into sub-tasks representing the work that needs to be done, with each one typically no more than a day’s worth of work.
From this discussion, the development team decides how they’ll complete each individual sub-task and estimate the time for the sub-task in hours, meeting any acceptance criteria determined through discussion with the product owner.
The team also decides how much work to commit to based on the total time they have available to focus on the project for the duration of the sprint. Then they start adding the highest priority user stories from the product backlog, counting the total sub-task hours they’ve estimated until they feel they’ve taken on as much work as they believe they can drive completely to “done” during the sprint. Typically the team will take on less work than their total available capacity, leaving room for some things they might not have thought of or sub-tasks they might have under-estimated.
How long should a sprint planning session last? Here’s a good rule of thumb I’ve found useful over the years:
Treat this time as a time-box. Do as much detailed planning as you can, but don’t try to make it perfect. It’s much more important to get started on the sprint than to identify every possible fifteen-minute sub-task.
The Daily Standup
The daily standup is a Scrum ceremony designed to keep the development team on the same page during a sprint. Once per day, the team gets together to share their progress and coordinate their plans. This is important, since the team is collectively accountable for the overall success of the project. The daily standup lets everyone know where each member of the team stands, whether they’re tracking to meet their goals, and why.
The agenda for this daily Scrum ceremony is guided by three questions:
- What did you do since the last standup to help meet the commitment of the development team?
- What will you do between now and the next standup to help meet the commitment?
- What impediments are getting in the way of you and/or the development team making progress toward meeting the commitment?
The ScrumMaster is in charge of making sure the daily standup takes place, that it follows the conventions of Scrum, and that all development team members attend and participate. When members can’t participate in person, they should do so remotely whenever possible. If they have a conflict, they should get their update to the ScrumMaster, who will convey it to the rest of the team during the standup.
The ScrumMaster is also charged with following up on any impediments noted, either directly or through the intervention of a project champion or sponsor.
Each daily standup should be time boxed to just fifteen minutes. Only development team members may participate in this Scrum ceremony – others may attend the meeting but are not allowed to speak.
The Sprint Review
A sprint review is a Scrum ceremony held at the conclusion of each sprint. This is when stakeholders inspect – and oftentimes demonstrate – the development team’s work.
The ScrumMaster is responsible for facilitating the sprint review and making sure that all the relevant stakeholders are invited. This ceremony provides an opportunity for the Scrum team and stakeholders to collaborate and reach understandings that will prove helpful for future planning sessions. It also identifies those rare occasions when something crucial is missed in the planning stages. But whether the fault lies with the stakeholders, the product owner, or the development team doesn’t matter – a Scrum ceremony is for resolving issues, not blaming others for them.
The sprint review includes discussions around each of the following topics
- What the development team committed to completing at the start of the sprint
- Whether everything was completed and, if not, why?
- What went well during the sprint, and what problems were encountered
- A demonstration of stories that were driven to “done” by the development team
- What is coming next on the product backlog, including a discussion about any missing items or any re-prioritization that should occur prior to the next sprint planning
- The projected completion timeline (typically discussed only after two or three sprints have been completed)
The sprint review should include demonstrations only of those stories completed during the sprint. Any user stories that remain unfinished will be returned to the product backlog for work in the next sprint, assuming the story is still prioritized to the top of the list.
The most important goal of a sprint review is to enable open and honest conversation between business stakeholders and the Scrum team, driving for total transparency and understanding about the real status of the work.
The Retrospective
The retrospective is another Scrum ceremony that takes place at the end of each sprint (and after the sprint review). The agenda of the retrospective is to reflect on the Scrum process and evaluate the team’s implementation of it.
Specific formats and topics during a retrospective may vary, but typically will include discussions about:
- What went well during the sprint
- What did not go well during the sprint
- What could be improved during the next sprint
- A plan of action to implement the identified improvements
This last point – creating a plan of action to improve the next sprint – is the most important output of the retrospective.
The ScrumMaster is responsible for scheduling the retrospective and ensuring the team engages in a productive discussion. The resulting plan of action should be clearly identified, and the team should be just as committed to improving their process as they are to the work during a sprint.
Backlog Refinement
Though not technically one of the Scrum ceremonies, many teams get together for “backlog refinement” before heading into their next sprint planning, and I feel it’s important enough to mention here.
Although the product owner is responsible for the product backlog, there is no set procedure for maintaining it. And while the product owner should be well qualified to represent the business team and prioritize user stories, she is not always the most skilled at writing, editing, and splitting them. This process is called refining the backlog.
Backlog refinement should take place during the sprint – so it’s not sandwiched so tightly between sprint planning and the retrospective. The product owner will come prepared to discuss the user stories at the top of the backlog, as well as any newly-added stories regardless of their position in the list.
The development team asks questions until they are satisfied they understand the user story. The product owner takes notes from the discussion to help the team remember the answers and key points later on.
Any un-estimated stories should be estimated by the development team during backlog refinement.
I recommend the following tips when scheduling backlog refinement :
- Avoid scheduling it at the very start of a sprint, when the team is focused on getting off to a good start and building momentum
- Limit the duration to two hours or less
- Two refinement get-togethers during a sprint are not uncommon, depending on the state of your product backlog, but I suggest avoid scheduling three or more
- Immediately following one of your daily standups seems to be the best, most efficient time to hold the backlog refinement for our teams
Scrum Ceremonies Set the Tone
All five of these Scrum ceremonies play a huge role in your development team’s success. They provide the communication structure the team needs to stay focused and on task. They also complement the Scrum processes, help monitor the team’s progress, and set the tone for striving for continuous improvement. And, perhaps most importantly, they eliminate the need for unnecessary meetings that waste your development team’s time.
If your Scrum ceremonies aren’t living up to expectations, don’t worry – Ascendle has Scrum teams that are eager to help. Contact us today and we’ll help you deliver Scrum ceremonies exactly as they’re designed.
