Agile Scrum Ceremonies Tutorial

4.1 Scrum Ceremonies

Welcome to lesson-4 of Simplilearn’s Agile-Scrum training program. In this lesson, we shall talk about the various ceremonies and rituals that are associated with Scrum. Proper understanding of the reason behind the ceremonies, expected outcomes and ways to conduct will help us get the most out of the methodology. Let us first look into the agenda in the next slide.

4.2 Agenda

Let us now look at the detailed agenda for this lesson. We shall start off by looking at the principle of time-boxing. Time-boxing is a key theme in the Scrum guide. Scrum operates on the principle of time-boxing and preserving the sanctity of the time-box is critical to the success of Scrum. One of these time-boxes is the Sprint (in other words) iteration. We understand what is meant by the Sprint, what the ideal duration of a Sprint is and how you work within the sprint. Then we look at the Daily Scrum or Daily stand-up meeting, which is one of the most well-known rituals of Scrum. At the end of the Sprint there are two rituals, viz. the Sprint review and the Sprint retrospective. Both of these are very important for the orderly closure of the Sprint. Firstly, we will get introduce with time boxing.

4.3 Time boxing

As the name suggests, time-boxing involves limiting the amount of time you devote to any particular activity. It could be a meeting, a fixed duration of doing development or test activity, or practically anything. The thing about time-boxing is that the time available is limited and this limit is sacrosanct. You can adjust the other parameters (how much you get done, which items you prioritize, etc.), but the deadline cannot move. Scrum relies heavily on the principle of time-boxing, all the projects, iterations, meetings and ceremonies must be time-boxed and the time limits must be respected. This is a very important and non-negotiable aspect of Scrum. Let’s continue with time-boxing in the next slide.

4.4 Time boxing

Let us look at how time-boxing actually works. A time-box can be of any duration (hours, weeks, months). It is essentially a control mechanism that allows you to determine how much time you wish to devote to a certain activity. Time-boxing is done at the lowest level, so that we can achieve control at the right level. If it so happens that the activity cannot be completed within the time-box available, the remaining items get deferred to subsequent time-boxes. For example, the way we plan work in the iterations is to limit the time available and then figure out how much functionality can be delivered within that time frame. Time-boxing may be useful even outside of just project related activities in the interest of improving personal productivity and time hygiene. For example, a person may find that he/she is spending too much time on social networking. One way to control this would be to “time-box” the social networking activity, i.e. limit the amount of time you devote to it (say half hour a day). It is natural that initially the time-box might seem restrictive, i.e. you may not achieve everything that you wanted to get done. But that then automatically turns the focus on what are the MOST IMPORTANT things to do within that time-box. This focus will help you speed up your process and help accomplish more important things quickly and at higher priority. In the next slide, we will focus on Advantages of time-boxing.

4.5 Advantages of time boxing

Time-boxing is a very simple principle and it WORKS. Here are some of the reasons why time-boxing is so effective. -Focus: It helps you sharpen focus on what is most important. Because time is limited, you are forced to prioritize. -Increased productivity: Productivity increases because you end up working smarter to make the most of the time available. It helps defeat the Parkinson’s Law (work expands to occupy the time available) and the student syndrome (tendency to delay studies till the last possible minute). -Realization of time spent: Because time limits are decided up-front, you know exactly how much time is being spent on an activity. -Time available: It helps you become more acutely aware about the time available to complete an activity. -Let us now look into the diagram in the next slide which describes more about the time-boxing.

4.6 Time boxing

This diagram illustrates how the time-boxing principle helps you make more reliable plans. In any given time-box, you must plan a combination of must, should and could activities. Within the time-box itself, you should plan the work in such a way that must’s get completed at any cost. If anything does need to be deferred to the next time-box, it better be the could’s and (less preferable) should’s. Now, we will learn about release in the next slide.

4.7 Release

Let us understand the concept of a “release” or a project. Let us state up-front that the 2011 version of the Scrum guide. The idea is that Scrum requires the code to be in releasable condition every iteration or Sprint. Therefore, each Sprint is in effect a release. Whether the Product owner decides to actually (officially) release the product or not, that must be the team’s goal. However, the concept of a release may still be required or useful, because: -The customer needs to know what they can expect and when. -The process of release planning gives the product owner some idea about milestones in the project that they can use for communicating externally about the plan. -However, it is important for the team to understand that they must be in “releasable state” at the end of any iteration and that the customer may demand a release at any time. Therefore the release plan itself is a flexible plan, and has no particular sanctity attached to it. Therefore, the release planning process is an important part of the planning activities. However it must be understood that in the spirit of the Agile manifesto and principles, the plan should be flexible. The product owner should be able to release the product at any time they feel sufficient “value” has been generated. Further, the plan should be modified in response to customer requests and changes in priority. In the next slide, we will discuss on the high level view of a release.

4.8 High level view of a release

With this background in mind, let us look at the diagram that shows the life-cycle of a release. It all starts off with the release planning process where the idea is to generate a high-level milestone plan for what is likely to be accomplished by which timeframe. Along with the high-level planning, it is important to have some high-level idea about the design, framework, model or architecture. The key word here is “high level”. The model should be just enough for the team to make a start in building it. The details of the design get finalized within the development iterations as the features start getting built. The process of actual implementation happens through multiple Sprints. Each sprint is a microcosm of a release, wherein a subset of the requirements are worked upon, and completed. Completed here means that they are developed, tested and the product is brought to a “near releasable” condition. The product is then reviewed by the Product owner along with other stakeholders and the Sprint is closed. This process of working in Sprints continues until the Product owner (representing the customers and other stakeholders) determine that sufficient “value” has been generated and the product can be officially “released”. Next we get to understand about Sprints

4.9 Sprints

Let us get back to our favorite Sprint life-cycle diagram to focus attention on the Sprint. Sprints are short duration milestones that help the team accomplish a part of the project’s work in a time-boxed manner. Sprint does not mean that you are expected to run at breakneck speed. It should be understood that the pace of the project should be fast enough as well as “sustainable”.

4.10 Sprints

Let us now understand the important characteristics of Sprints. -A Sprint is a time-box. This means the duration of the Sprint is fixed up-front and once it is fixed. -The goal of each Sprint is to produce an increment of the product with added features with all the features complete. Complete here means coded, tested and in near releasable condition. -The typical duration of a Sprint is 1 to 4 weeks. The team determines the duration that is most suitable for its work. -The Sprint deadline cannot then be changed, irrespective of whether the planned work got completed or not. -The team can change the duration of a Sprint if they so wish. It need not be constant over the life of the project. Let us now go through the Factors in selecting Sprint duration.

4.11 Factors in selecting a Sprint duration

Obviously, selecting Sprint duration would be among the first decisions that a team will end up taking. There are many factors that govern this choice. -The length of the release being worked on.The shorter the overall release cycle, the shorter each Sprint should be. -The amount of uncertainty. If there is too much uncertainty in the work involved, you would typically want longer Sprints -The frequency at which it is convenient for the customer to provide feedback -The length of time that the priorities will remain reasonably static. Remember that once the items are prioritized for a given Sprint, the Sprint backlog cannot be changed – in effect the customer has to wait until the beginning of the next Sprint for their amended priorities to reflect in the plan. -The length of time for which the team can go without feedback -The overheads involved in iterating. The overheads include planning, review and retrospective -A feeling of urgency should be maintained. Excessively long Sprints may again cause Parkinson’s Law symptoms to surface. -In the next slide, we will focus on Intensity of work.

4.12 Intensity of work

The purpose of this diagram is to show you how Sprints help spread the workload evenly over the project’s duration. In a typical traditional life-cycle, the intensity of work would be low to begin with and would gradually increase, ultimately resulting in a crescendo towards the end. Dividing up the work into Sprints would cause the workload intensity to be also divided over a number of time-boxes. Within each time-box too, it is natural to expect workload to peak towards the end of a Sprint, but hopefully the peak workload of the Sprint would be less stressful than the peak workload of the release. Let us move on to the next slide now.

4.13 No changes in a Sprint

Some important principles about how work is organized during a Sprint. -Once the team has committed to doing a certain amount of work at the beginning of the Sprint, the Sprint backlog cannot then be changed, i.e. the work load or work content cannot be changed -Substantial changes to be the committed stories are not allowed -Also, the Sprint deadline cannot be changed -In the event of a change request coming in, the product owner can do one of the following things. oThey can add the change to the product backlog ask the customer to wait until the start of the next sprint to prioritize the request. This would typically be no more than a week or two. It is extremely rare that a change is so urgent that cannot even wait for that long. oIf the customer is adamant that the change needs to be worked on immediately, the product owner can “cancel” a Sprint, i.e. terminate and begin a new Sprint planning session. This should only be used in the rarest of rare circumstances, because it is a clear loss of productivity for the team to drop what they are doing and start working on something different. Now, we will look into the daily scrum in the next slide.

4.14 Daily Scrum

Let us go back to the Scrum life-cycle to turn our attention to the Daily Scrum or Daily stand-up meeting. It is one of the most well-known of the Scrum rituals and depending upon the participants; they may either love it or hate it! Let us continue this on the next slide.

4.15 Daily Scrum

The daily scrum is a short (no more than 15 minutes) meeting in which the entire team gets together and each team member provides a very short description that answers the following questions. -What I did yesterday (or since the last meeting) -What I plan to do today (or until the next meeting) -What is in my way (or what is blocking my progress) Remember these are NOT status meetings or the team members reporting into some higher authority. These are team members providing information to each other and making commitments to each other. If it becomes a status meeting, it would boil down to micro-management and the team would lose its self-managing character. Next we continue with the daily scrum.

4.16 Daily Scrum

The daily scrum is a very simple (almost primitive) but highly effective way to get the whole team in sync and keep them focused on the work. Why does it work? -It gets the team together -It results in information getting shared within the team -It helps focus attention on what is most important at any point in time -It builds the team To make the daily stand-up meetings most effective, some of the best practices to observe are: -It should not last too long (no more than 15 minutes) -The whole team should stand (this helps keep the meeting short!) -Even if there are remote participants, they should participate in the meeting and they should stand as well -No side conversation or discussion is allowed till the meeting ends Let us now learn about the sprint review in the next slide.

4.17 Sprint Review

Let us go back to the Scrum life-cycle to understand the Sprint review. The review is a very important Scrum ritual that helps the team to showcase the work they got done during the Sprint and gather feedback about the progress being made.

4.18 Sprint Review

Let us understand the Sprint review in detail. The mandatory attendees to this meeting are the team, the Scrum master and the product owner. It is a good idea to invite management, customers, end users, subject matter experts – anybody who is interested in what is getting built and can provide important feedback about the work. In this meeting, the team provides a demo of the working software that the team has built. It should not be a power-point or document – just a quick, live demonstration that shows how the requirements were implemented in reality. It is normal for the participants of the meeting to have a lot of feedback to offer. Some of it could be positive, and some could be negative or some of it could be change requests. It is important to record all the feedback and use it to fine-tune the product backlog. The Sprint review is important because it helps the team validate that they are on the right track. Feedback helps them get closer to the customer’s expectations. It also confirms whether the team is making enough progress as per the release plan or not. After all, the Agile principles do state that working software is the primary measure of progress. Let us look into few important points which should also check during a review.

4.19 Also check during a review

Here are some other things that might be worth checking or discussing during the Sprint review. -It is normal for the team to find that some items that were on the Sprint backlog (i.e. planned to be done during the Sprint), were not actually completed. Such items are carried back to the Product backlog and prioritized again before the next Sprint. -The product owner might triage the feedback received and quickly add to the backlog and assess priorities (while the stakeholders are in attendance). -If the customer or a stakeholder wants to start using a feature or play around with it (for training or marketing purposes for example), then the product owner can take a call about making an official or unofficial release of the product or component. -It is a good practice to record the demo and make it available to those participants who were not able to join the meeting. -The team then proceeds to formally close the Sprint and go into the retrospective meeting. Now, we will discuss on Sprint retrospective.

4.20 Sprint Retrospective

Let us go back to the Scrum life-cycle to understand the Sprint retrospective. The retrospective is the ritual in Scrum which brings in the iterative character of the methodology. This means, the team reflects upon the previous time box with a view to learn some lessons and then adjusts the behavior or the environment in order to improve their experience. Let us first understand what a Sprint retrospective is.

4.21 What is a Sprint Retrospective

The retrospective is a 1-2 hour meeting at the end of the Sprint (typically after the review) that helps the team to review what is working and what is not. The team can then take actions to improve things going forward. The mandatory attendees for this meeting are the Scrum Master and the team. Sometimes you may invite the product owner too. The team may decided to bring in a neutral facilitator (for example, the scrum master of another team) to help manage the discussions. It is important to understand that the sprint retrospective is a meeting of the team, by the team and for the team. It is not a performance review for senior management where the team’s performance is being assessed by the senior management. Nor is it a post-mortem meeting where the goal is to assign blame. The retrospectives are important because it gives the team visibility into the issues and helps them to take control of actions needed to correct course and make their work environment more efficient and more productive. Next we get to understand how to make retrospectives effective.

4.22 Making retrospectives effective

The retrospective is not an easy meeting to conduct or to keep on track. Depending upon the personalities within the team, the tendency may be to keep the meeting too “smug”, i.e. only focus on good things, while brushing all the dysfunction under the carpet. Alternately, it may turn out to be a virtual slanging match, where team members blame each other. Some good practices in conducting effective retrospectives are as follows. -Start by creating 3 lists: What is Working, What is not working well and What we could try (to change or to introduce) in the next Sprint -Collect inputs from everybody in the team, keeping focus on these questions -Prioritize the inputs received and arrive at a prioritized list of actions. Try only a few things at a time – do NOT try to boil the ocean -Assign actions to specific people for what needs to be done -Agree on what the penalty would be if the actions are not taken. These penalties have to be friendly penalties – not threats, because threats can be counter-productive -Find ways to make the meeting “fun” – use humor, bring in some food and snacks, etc.

4.23 Quiz

Let us quickly test our understanding of this lesson through this quiz. A team member wants to discuss a potential change to the design review process to avoid mistakes. What could be the best forum to discuss this? A-Daily Scrum B-Sprint Review C-Sprint Retrospective D-Sprint Planning Answer is C: The retrospective is the best forum to discuss process changes. Which of the following is NOT true about daily scrum meetings? A-Attending these meetings is useful for managers to get status B-The whole team stands C-The meeting can last no more than 15 minutes D-Side conversations are not allowed Answer is A: The daily scrums are not status meetings and it is usually not advisable for managers to attend. What is the BEST forum for inviting external stakeholders? A-Sprint review B-Daily Scrum C-Sprint retrospective D-Sprint planning Answer is A: Sprint review is the best forum for inviting the external stakeholders to showcase what the team is building and to gather their feedback. Who is BEST suited to facilitate a Scrum retrospective? A-Product owner B-Scrum master C-Customer D-Manager Answer is B: The scrum master is best suited to conduct a Sprint retrospective We thus end this lesson on Scrum Ceremonies. We hope that this has been a pleasant experience for you. Let us move on to the next lesson. The next part covers the fifth lesson of this course which is about Scrum Artifacts. Happy learning!

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Work Email*
Phone Number*
Job Title*