What Are Scrum Rituals?
The following is an extract from our book, Scrum: Novice to Ninja, written by M. David Green. Copies are sold in stores worldwide, or you can buy it in ebook form here.
The practice of working on a scrum team is organized into a series of rituals. The rituals mark key events in the process of carrying out the work of a sprint. It’s the responsibility of the scrum master to host each of the rituals, and make sure that they focus on their objectives, and produce the desired results for the benefit of the entire team.
Each ritual is a face-to-face gathering in real time, which takes people away from the work they’re doing, and offers them the opportunity to have targeted communication with each other about the context of that work. Scrum favors communication over documentation, which is why it provides regular and clearly defined opportunities for various types of useful face-to-face communication.
Not Another Meeting!
Many people who work in companies are allergic to meetings, and for good reason. They may have been overwhelmed by too many meetings, taking up too much of their time, and not producing any results. They may be used to having meetings called to address every little issue, without any one person being responsible for making sure the issue gets resolved. Meetings can take people away from the work they’re doing, and interrupt their focus, often without providing much value in return.
Let’s face it, most companies are terrible at meetings.
Unlike the usual meeting, every ritual in scrum has a specific objective, addresses a particular audience, has a defined time frame within which to accomplish its goals, and has a predictable set of outcomes. Everyone attending a ritual knows before the ritual starts what to expect, how to behave, and what the result of the commitment is supposed to be. The rituals of scrum are mindful of their overall purpose, and respect the time and attention of the participants.
Time Boxing
One of the most important concepts in scrum rituals is that of the time box. It’s the responsibility of the scrum master who hosts the rituals to keep everybody aware of exactly how long they have committed for this ritual, and how far along they are at any point within it.
Often scrum masters will write the time up on the whiteboard in front of the room, or keep a large clock visible so everybody can keep track of the time. (I have been known to bring a small cube-shaped clock labeled “Time Box” to rituals, and display it where everyone can see it.) The concept of time boxing empowers all the active participants in a ritual to encourage each other to get to the point when necessary, and remain focused on the objectives of the ritual.
Note: How long should each time box be?
The length of time the team will spend on each ritual usually depends on the number of weeks allocated per sprint. The only ritual that must stay within a 15 minute time box is the daily standup. Teams come to an agreement on the time box for each ritual as part of the process of iterating and improving how they organize themselves for scrum. I’ve provided a few suggestions below for teams to start with.
Scrum shows its respect for the time and commitment of every participant by establishing at the beginning of each ritual what the time box is, and how that time will be allocated for the different aspects of the ritual. All participants are expected to remain engaged and participate during the time box of the ritual, with the promise that the ritual won’t be extended without a good and practical reason, and not unless all participants agree to the extension.
If a ritual appears to be about to exceed its time box, the scrum master should ask everybody for their permission to continue the ritual for a specific length of time. That way everybody knows up front how much time to budget, and everybody has to agree if the budget needs to be extended.
Of course, we are all human, and side issues will come up during rituals that feel as if they need to be discussed right then and there. Keeping the focus on the ritual at hand is the responsibility of the scrum master, as well as the rest of the team. A good scrum master needs to keep track of these issues, and maintain respect for the time box of the ritual in progress for the sake of everyone involved.
Making sure that important side discussions don’t get lost is a shared responsibility, but the scrum master needs to be prepared to take an active role in that process. People will more willingly set aside an off-topic discussion if confident that they’ll be able to pick it up again later.
The Length of the Sprint
Teams have some choices to make when it comes to choosing the length of the sprint. Sprint length should allow the types of stories the team expects to work on to be completed, according to the team’s own definition of done, within a single sprint. For many teams, a short sprint of just one week matches well with short stories that are easy to finish in a week. Some teams prefer to work with more complex stories that couldn’t be completed within a one week sprint, so they opt for two-week, three-week, or even four-week or longer sprints.
The length of the sprint is another factor that can be modified based on feedback received from the team, but it’s important for a team to choose a length and stick with it for several sprints. Otherwise, the team may never benefit from the regularity so they can learn how to size stories consistently and estimate them correctly from one sprint to the next. Often the option to change sprint length can be addressed just by improving the way stories are written, so they can be completed within a sprint.
Note: Two Weeks is a Good Starting Point
For web and mobile teams, a two-week sprint is a good place to start. Two weeks is long enough to complete most stories that relate to web and mobile projects, including the release process in most cases. If your web or mobile team is just starting out with scrum, it’s worth trying a two-week sprint cycle first, to see how well it suits you.
Even if your stories tend to be short and finite, there are disadvantages to one-week sprints that are worth considering. Some of the longer rituals are repeated once every sprint. Having a one-week sprint means that repeating these rituals so frequently may start to get in the way of productivity. Some rituals, such as the retrospective, could even end up being short-changed or bypassed some weeks, and that can lead to a breakdown in the iterative improvement aspect of scrum.
A team that tends to produce more complex stories may prefer longer sprints. Keep in mind that sprints longer than two weeks mean that issues will take longer to surface, and adjustments to the backlog will need to be delayed until a sprint has been completed. Longer sprints also encourage the creation of more complex stories. The goal of scrum for web and mobile teams should be to create stories that are simple and distinct.
This diagram represents a two-week cycle for a typical web or mobile development sprint. Each smaller circle represents a single workday, and the rituals are marked out assuming that the sprint starts at the top and loops around every two weeks.
In the next few pages, we’re going to do a deep dive into each of these rituals, making sure you understand how they work, and how they can be applied to web and mobile development.
