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.

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.

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.

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.

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.

Figure 4.1. Two-week Sprint Cycle

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.

The purpose of the sprint planning is to set the agenda for the upcoming sprint. The team gets together with the product owner and the scrum master to get an introduction to the stories that should be completed during the next sprint.

The product owner shows how the stories fit into the vision for the product, and the team estimates the stories the product owner has introduced and commits to completing as many as they believe they're capable of, given their historical velocity—which is determined by the number of points they've been able to complete in an average sprint. At the end of the sprint planning there should be a commitment to a certain set of stories that everyone can agree on. The stories should all be clear, and the amount of work they represent should be within the capacity of the team to complete during the next sprint.

Depending on the number of weeks a team has committed to for each sprint, the sprint planning may take several hours, or it may take an entire day. For a two-week sprint, a team may find that setting aside three or four hours is a good investment for a sprint planning. That might seem like a lot of time, but sprint planning done right is very detailed and explicit about what the team needs to produce. A key value of scrum is the communication it facilitates. Sprint planning exemplifies this.

Most teams will find they're able to accomplish the objectives of these rituals more efficiently as they get more familiar with the process. Having a strong scrum master who maintains a clear time box around the different aspects of the ritual can help make the process go as smoothly as possible.

But there's a lot to get done during the sprint planning, and these rituals need to be given adequate room to accommodate all the issues that will come to the surface. Starting with clear time constraints gives everyone confidence that there's a goal and an end point in mind, and also helps keep people focused.

Sprint planning provides the opportunity for the scrum team to get an introduction to the stories the product owner wants them to work on for the next iteration of the product. During this part of the ritual, the product owner goes over the stories that have been prepared, presenting them to the team for evaluation.

It's important for every member of the team to participate actively during this presentation, because this is their opportunity to question and challenge the completeness and appropriateness of each story. A good product owner will have discussed the stories with experts on the team before this ritual, to make sure that predictable objections have been addressed.

Sprint planning encourages active discussion around each story. The process opens up a dialogue, allowing the product owner and the team to consider the ramifications and feasibility of each story in detail. Although the product owner is authorized to set the priority of the stories on the sprint backlog, the team has the authority to reject stories that it considers impossible, inadequately defined, or technically inappropriate before they're added to the sprint backlog.

This part of the sprint planning ritual is also when the team has the responsibility to present stories that relate to the code itself. If the product owner is responsible for the vision of the product, the development team is responsible for the quality and maintainability of the code. The product-oriented focus of scrum is not an excuse to ignore technical debt.

Often the team will introduce stories around refactoring code, updating code to meet new standards, or making crucial upgrades to the infrastructure. It's important for the team to make a strong case, because the product owner has ultimate authority. Different teams resolve this balance of power in different ways, and it's up to each team to figure out how best to address technical debt while still meeting the expectations of product development.

The next phase of sprint planning is story estimation. During this process, the team will estimate the relative level of effort required to accomplish each story, based on the team's experience with similar stories in the past and their agreed definition of done.

There are many ways that teams estimate stories. The important thing to keep in mind when estimating is that the values assigned to the different stories are arbitrary and relative, and bear no resemblance to actual time. The point of the estimating exercise is to improve the team's ability to look at a new story and figure out how much effort it'll take relative to other stories they've already worked on.

Most teams use a system of points to estimate stories. A smaller, easy story may be estimated at one point, while a large or complex story may be assigned 20 points. Many teams use a modified Fibonacci scale, with the numbers 0, 1, 2, 3, 5, 8, 13, and 20 representing increasing levels of effort. The goal over time is for the team to get a sense of how many points they can accomplish within the single sprint, so they can estimate forward more effectively.

Each team comes up with its own sense of what every point value means for itself. There can be no logical comparison between the points accomplished by one team during the sprint and the points accomplished by a different team during the same sprint. The value of the points is subjective, and relevant only to the participants of a specific team.

Other systems for sizing stories include T-shirt sizing—such as small, medium, large, extra-large. It's completely up to the team what system they choose. Once the team has chosen a system, they should try to stick with it for several sprints, so that they can start to get a sense, over time, of what their velocity is in the metric they've chosen.

Once all the stories that the product owner has presented have been estimated, all the participants in the ritual work together to come up with a backlog that makes sense for the upcoming sprint. This backlog will be sized based on the historical number of points that the team has been able to accomplish in the past, balanced against the point estimates for the new stories.

While the product owner has final authority over the contents of the sprint backlog, as well as the order of the sprint backlog, the team has the opportunity to advocate for certain changes while the backlog is being prepared.

For example, although each story should stand alone, it may make sense to the team to work on particular stories in a certain order. The team may also wish to complete stories that were started but not finished in the previous sprint. Completing stories that are in progress is useful for the development team because it helps them to maintain continuity. While there's a cost to loss of continuity, that cost is the responsibility of the product owner, and the product owner has the authority to make those decisions for the sake of the product.

Once a final sprint backlog has been created, everyone on the team needs to commit to that backlog. This is the last opportunity for the team to object, or raise issues that they think may have an impact on their ability to do the work required. If there's still disagreement, the scrum master needs to step in and facilitate the conversation so that agreement can be reached.

The end product of a sprint planning is a sprint backlog that everyone on the team can agree to. The scrum master should poll the room to make sure everyone agrees that the commitment is realistic, and that they are willing to take it on for the upcoming sprint. Then the new stories should be entered in order of priority into the tracking tools the team has agreed to use for the sprint backlog.

Sprint planning reminds everybody exactly where they are in the process of building the product owner's vision for the product, and what the objectives are for the upcoming increment. At the end of sprint planning, everyone on the team should have a good sense of what they need to do next, and a firm commitment to a set of prioritized stories to complete over the duration of the upcoming sprint.

The purpose of the daily standup is to give everybody on the team an opportunity to share the status of the work they're doing, and get help if anything is blocking their progress. Everyone on the team should pay attention as their teammates report, so they can have a clear picture of the status of the complete iteration they're all working on.

This is also an opportunity for anybody outside the team who's interested in knowing what the team is working on to find out how stories are progressing, and what's likely to be worked on next. Only team members are allowed to present at the daily standup, but anybody in the company may attend, and visitors should be invited to participate as silent observers.

Traditionally, the daily standup is limited to 15 minutes. It's a short ritual, and it's kept short and made as convenient as possible so that everyone can commit to being present, participating actively, and paying attention while other people are speaking. Everyone is expected to stand, both so that they pay attention, and to encourage all participants to play their part in keeping the ritual short and focused. Most teams try to hold the standup away from their desks, and discourage people from using laptops and other devices during the ritual.

Different teams will choose different times of day to hold the stand up. Often first thing in the morning, or right before lunch, can be good times. These are natural breaks in the day that are usually common to most people on the team, so a 15 minute standup won't disrupt the focus needed for longer blocks of programming time.

Finding a time that works for everybody can be challenging for teams that aren't co-located, especially when some members of the team are in different time zones. Nobody should be allowed to miss the standup on a regular basis, but there's always room for flexibility, as long as the objectives of the daily standup are being met. Even if not everybody can make it to a specific standup, the scrum master should keep the ritual for anyone who is there.

Sometimes teams may need to come up with their own systems, and iterate on these reflectively from sprint to sprint. The priority should be on keeping the rituals brief, maintaining them reliably, and making sure they provide the intended value without creating undue interruption.

Every team member should be present and available at the time of the standup. The only preparation necessary is for each team member to think about how to present the work being done at the moment in such a way that it'll be clear and understandable to everybody. if a team member is having blockers that relate to people outside the team, it's reasonable to let those people know to be prepared to discuss the issue immediately after the standup.

There's no special preparation needed by the scrum master before the standup. A good scrum master may check the status of the stories being worked on before the standup, to see if any changes are pending, or may arrange to round up any guests the scrum master thinks should be there who don't normally attend.

The core of the daily standup consists of the scrum master going around the team and asking every person three questions:

It should be as simple as that. Every member of the team answers each one of these questions, and once the last person has finished reporting, the standup is over. Unless the scrum master has urgent announcements that need to be made for the entire team, everyone who doesn't have specific business with another person attending the standup should be free to get back to work.

In answering the questions of the standup, each engineer needs to be prepared with a succinct description of what they've worked on, what they plan to work on next, and whether they have any blockers. This is a skill that takes practice, and the scrum master should be prepared to coach every team member on how to answer these questions in a way that makes the best use of the time available.

If one person's report invites a little bit of back-and-forth discussion, and the conversation has relevance for the entire team, the scrum master may permit it. But this type of interaction must be limited to respect the time box of the standup. If the conversation gets beyond a few sentences, the scrum master should step in and suggest that the conversation be taken off-line. A good scrum master will keep track of what conversations need to happen at the end of the standup, and follow up on their status afterward.

Some teams choose to update the status of their stories on the team's shared scrum board during the daily standup, while others prefer to do it individually as the stories get completed. In either case, the standup should be an opportunity to make sure everybody has updated the status of everything they're working on, and that everybody on the team is aware of what everybody else is working on.

For teams that are doing pair programming, the standup can be an opportunity to switch pairs, or switch stories. Some teams that do pairing prefer that every story have one engineer seeing it through from beginning to end. It can be beneficial for the flexibility of the team to allow multiple people to pair on the same story, particularly if it relates to some core functionality that's worth sharing information about. Different teams will come up with different approaches, but the standup is a good place to make changes on a daily basis.

Standups are also a good opportunity for team members to let each other know if they expect to complete a story before the next standup, and if they have vacation time coming up. Knowing the availability of other people on the team can inspire teammates to plan their work around upcoming stories, and arrange to switch pairs or allocate resources appropriately.

Finally, the scrum master may make announcements that have relevance to the entire team at the end of the standup—once everybody has had a chance to report, and only if there's time left. This shouldn't become a replacement for any organizational team building that may come from company meetings, team lunches, and other gatherings.

The objective of the sprint demo is to get a clear picture of how much work has been completed during the sprint, and to see what the current state of the product will be after integrating the work that was done during the sprint. Based on the stories that get accepted, the team learns more about how many points they can sustainably accomplish in a single sprint, and this improves their ability to estimate stories and sprint backlogs going forward.

The time allocated for sprint planning is contingent on the number of stories completed during the sprint, and the level of intricacy associated with the acceptance criteria. Most teams allocate half a day for the sprint demo if they're using a two-week sprint. Once the team has decided how long they want to devote to the demo, the scrum master should be responsible for making sure that everything that needs to happen fits within that time box.

The sprint demo is the opportunity for the team to show off all of the work they've been doing, and demonstrate that all of the stories they've been working on are done and ready to include in the product (assuming they haven't been already). The demo covers all the work back to the beginning of the sprint that has taken a story to the team's definition of done, whether or not that work has been released. Each person who has worked on any stories that are ready to demo needs to be prepared to explain what they did with those stories.

Often the engineers will get together with the product owner before the demo to make sure everybody is aware of what's going to be presented. This can be a useful last step before the demo, because it ensures the stories presented meet all of the acceptance criteria. It also reminds the engineers to make any preparations necessary to allow unreleased stories to be demonstrated.

The scrum master should meet with all engineers who have stories completed, to make sure these stories are prepared for the demo. It's the responsibility of the scrum master to run the ritual, and see to it that everything that needs to be demonstrated can be presented within the time box allocated. The scrum master's agenda for the ritual should include a list of all the stories to be demonstrated, as well as the people responsible for each of the stories.

The process of demonstrating each story should be consistent. The scrum master should go through each story on the list, and have the engineers set up the demo for the team. Many teams choose to do this using a projector in a conference room, although it's possible to do this by gathering around a large monitor, or even through remote conferencing services, depending on the nature of the story and the preferences of the team.

At this point in the sprint, the description of the story will be familiar to most of the people in the room, but the product owner should read the story—as well as any major acceptance criteria—to the team while the demo is being set up. That way, everybody will know what to look for, and will be aware of issues that might come up.

Once the story is set up and ready to demo, the state of the product is the main focus of attention. Each story should be a complete slice of functionality added to the product, and the demo should show that slice of functionality in context with the actual product. The demo should walk through each of the acceptance criteria, proving that they have been met.

Sometimes during a demo, it's realized that the acceptance criteria as they were originally written were inadequate, and may not have covered all the cases the product owner needed addressed. If this happens, keep in mind that a demo that meets all of the acceptance criteria—as they were specified in a story that was estimated at the sprint planning—should be considered accepted and done. Any further changes that may be needed are new stories. The product owner in this situation should be prepared to create new stories for a future sprint that relate to the additional acceptance criteria that weren't addressed in the original story.

At the end of the demo, a number of stories will have been accepted, and some may have been rejected. The scrum master should add up the number of points completed during the sprint, based solely on the estimated points assigned to stories that were accepted as done. Only stories that were accepted as done, and that were assigned points at the sprint planning, should be included in this total. The total number of points completed in the sprint should be recorded as the team's velocity for that sprint.

Some stories may have been rejected, or may not have been ready to demo despite being included in the sprint backlog. It'll be up to the product owner whether stories that weren't completed will be added to the next sprint, or put on hold pending a possible future sprint. The scrum master needs to keep track of all the stories, both completed and not yet completed, and update their status in any tracking tools that the team may be using.

Often the scrum master will generate a set of reports that are sent out at the end of the sprint demo, updating interested parties about the status of the product. If the team has decided to have both the sprint demo and the sprint retrospective on the same day, the scrum master may want to arrange the schedule so that the necessary data for these reports can be collected between the two rituals, thus making them available for reference.

Releasing is the process that takes completed features and integrates them into the live product, either so the users can have access to them immediately, or so they can be evaluated for inclusion in a future release. The process may be overseen by release engineers, or integrated at the developer level with a set of fail-safes and rollback procedures.

Web and mobile teams have many options when it comes to releasing. For some teams, releasing a story to the customer as soon as it's completed—sometimes several times in a single day—makes perfect sense. For others, the release process is more complicated, and it makes more sense to group stories from a whole sprint, or even multiple sprints, and do larger unified releases.

Continuous integration is an approach that supports releasing stories as they're completed, rather than waiting for the end of the sprint. This usually depends on a robust test suite and an orchestrated set of release scripts. For teams doing continuous integration, the release of the stories into the live product will already have been done as part of completion of the stories themselves, and no further steps will be needed after the demo.

For teams not doing continuous integration, there will be another task needed to release all the stories from the sprint into production. The tasks associated with the release process are usually considered part of the definition of done for a story, but in this case they may need to be completed after the demo.

Some teams regularly schedule releases at the start of each sprint. Others do releases more frequently, or may release only at certain times of the year, or on a schedule to coordinate with certain events related to the needs of the larger organization or the marketplace. Figuring out how to plan and schedule releases is an opportunity for the team to reflect and iterate on their process, finding the rhythm that works best for them and best meets the objectives of the product owner.

A sprint retrospective gathers the team together to consider how the sprint that was just completed went for everybody. During the ritual, everyone in the room will be asked what went well, what didn't go well, and what commitment they're willing to make as a group to improve things in the next sprint. The goal is to come away with a set of modifications to the process that everybody on the team agrees to try for the upcoming sprint.

All the members of the development team, the scrum master, and the product owner are expected to participate in a sprint retrospective. The ritual is led by the scrum master.

Teams may find that the amount of time they spend in the retrospective mirrors the amount of time they might spend in the sprint demo. For a two-week sprint, it's not unusual for the team to devote half a day to the retrospective. When scheduling the retrospective, it's good to err on the side of generosity with the time, to avoid cutting off access to valuable insights from team members.

The amount of time a team dedicates to the sprint retrospective reflects the importance they give to paying attention to their own process, and improving as they go. Some teams may try to limit the amount of time spent in the retrospective. This can come at the expense of communication and improvement. One of the most important aspects of scrum is its emphasis on discussion as a means of enhancing the product development process.

Sprint retrospectives can be highly charged. Everybody involved in the scrum should come to the ritual with some thought in mind about what might have happened during the sprint that they want to comment on. For some people, this can mean creating a long list of issues to raise.

The scrum master should come to the sprint retrospective with an agenda that makes sure both positive and negative feedback is gathered from all participants. It's the responsibility of the scrum master to see to it that everybody has a voice and contributes to the process.

The scrum master should ask everybody in the room what they thought went well during the past sprint. This is usually done by going around the room and having everybody report about one or more things they thought went particularly well during the previous sprint. Unless this sprint was a total disaster, most people should be able to come up with something they thought went well^[2].

Part of the value of getting people to discuss what went well is to bring people together and give them an opportunity to recognize and appreciate the good work they and their teammates were responsible for.

Next the scrum master should go around the room asking people to report what they didn't think went so well during the sprint. This is a more delicate subject, because people may tend to bring up uncomfortable or unpleasant issues.

As before, everyone should be asked to participate. Bringing out honest responses from people about subjects they may feel uncomfortable discussing is part of the skill of a strong scrum master. If somebody really doesn't want to speak, or has something to say that they don't want to bring up in front of the group, they should be encouraged to talk about it independently with the scrum master outside of this ritual.

Saying negative things in front of teammates can feel uncomfortable. Part of the job of the scrum master is to help coach people from sprint to sprint in how to frame their issues so that they can be discussed in a productive way. This ritual isn't about personal attacks, but about finding ways in which the team can work better together.

After everybody has had an opportunity to discuss what they thought went well during the sprint, and what didn't go so well, the floor should be opened for discussion. This is a chance for everybody on the team to say more about the issues they raised, as well as the issues raised by the other teammates, and what they think the team should be doing about them.

For things that went well, the team should try to find ways that the successes can be replicated in future sprints. They might have tried something new this past sprint that turned out to be successful, and that can be integrated into the process going forward.

For things that didn't go so well, the team has the opportunity to discuss what went wrong. Sometimes the issue was that the process was not followed. Other times, the process actually got in the way, and needs to be adjusted. Everybody should be encouraged to give their opinions about changes that might be beneficial.

Eventually, the discussion will circle around to four or five key issues that the team wants to focus on. The scrum master should guide the discussion in such a way that these issues get phrased as revised practices—which the team can then agree to try for the upcoming sprint.

By the end of this ritual, the scrum master should present the team with a short and understandable list of changes to the process. Most importantly, the scrum master should poll the entire room, and make sure everybody is in agreement with this set of changes. Then the scrum master should record the team's commitment to the revisions for the upcoming sprint. A team's ability to reflect and improve is as important to its development as the commitment to a sprint backlog is to the product's development.