Introduction to Scrum Events:
In our earlier tutorials, we discussed Scrum and how is it structured.
And our previous tutorial explained all about Scrum Artifacts in detail.
We know who forms the Scrum Team and what different artifacts are developed throughout the process. We have established a strong background now. Hence, let us take a step ahead on Scrum and discuss the key events/ceremonies that constitute the Scrum Process.
In this tutorial, we will try to understand what each of the Scrum Event means, what are the essential features and how do we organize them in detail.
What You Will Learn:
While working on a Scrum-based project, the scrum team goes through a series of Scrum Ceremonies.
Some may call them Scrum ceremonies or events and others may call them for rituals or meetings. Irrespective of the different terminologies being used here, the goal of each Scrum event remains the same. Each of the Scrum events, in essence, helps in accomplishing and monitoring the Sprint work.
Types of Scrum Events
Each Scrum ceremony is an in-person affair/gathering organized by the Scrum Master for the dedicated groups. Apart from the core team, some of the meetings can involve stakeholders, delivery managers or even the customer himself. These meetings are time boxed and thus have to be completed within the stipulated time frame.
The objective of each of the meeting is to gather the participants and let them discuss the work at hand. The expectation from every participant is to stay focused, engaged and participative.
It is considered as an opportunity to converse, examine and retrieve the feedback of the work done. Unlike the ordinary meetings, the Scrum events are result oriented, time-boxed, target audience based and have specific objective aligned with each one of them.
What is Time Boxing?
Timeboxing is one of the key feature attached to every Scrum Event. Participants are expected to be cognizant and respectful of the time allocated to each of the events. The events cannot be extended but can be shortened if the goals of the meeting have already been achieved.
Scrum Master who is also a facilitator for all the Scrum Events makes sure that everyone understands the importance of time boxing and also keeps reminding them to focus on the objective of the meeting to derive the best results and in time outcomes with deviations.
The Timebox for an event should not ideally be extended but as we know that the Scrum is not about the rules, the time can be extended to a particular length if every participant agrees.
How do we decide the time box for each of the Scrum event?
The time box for Scrum Events is directly proportional to the length of the Sprint. However, the only exception to this rule is Daily Standup which has a fixed time box of 15 minutes regardless of the Sprint Length.
There are standard time frames for each event based on the Sprint length. Yet, the team has the liberty to decide on the time frames for these events based on their requirement.
Let’s understand more of these concepts by discussing each Scrum event in detail.
The Sprint Planning
As a pre-requisite to this ceremony, the Product Owner should have a stable prioritized Product Backlog of user stories prepared before coming to the meeting. The user stories should be well-formed and clear enough for the team to understand.
The Product Owner can seek help from the Stakeholders, Customer, Designer and the Scrum Master to develop the Product Backlog.
It is mandatory to have an Acceptance Criteria in a User Story. The team is authorized to reject a user story without the Acceptance criteria.
Sprint Planning is the initial ceremony while starting a Sprint. The purpose of the Sprint Planning meeting is to create a Sprint Goal, select user stories from the Product Backlog to Sprint Backlog and discuss them in detail.
The team gets together in a meeting room along with the Product Owner and the Scrum Master where the Product Owner presents the user stories that should be selected for the next sprint.
The team may ask as many questions as they like to know more about the story and it is the Product Owner’s responsibility to address the queries. The team might also challenge the story for its completeness and suitability.
If additional information is required within the story or has an uncompleted dependency or is found to be incomplete, the team has the power to reject that story.
After all, the doubts have been cleared and the team knows the exact amount of the work that needs to be done in order to complete a story, the team then estimates and gives the Story Points to each of the User Story.
In a similar way, the other stories are discussed and estimated. The team now selects the Stories from the top of the Prioritized Product Backlog into the Sprint Backlog which they think they will be able to commit and complete in the Sprint given their past velocity.
Velocity is determined by the total number of story points completed in an average sprint. The velocity is calculated based on the historical Sprints and by averaging them out. The more sprints we complete the more stable the velocity for a team is.
Many teams use Planning Poker cards for Story Estimation. The most common estimation technique is story pointing using the Fibonacci series. Fibonacci series is a series of numbers where each next number in the series is constituted by adding up the previous two numbers.
Fibonacci Series – 1, 1, 2, 3, 5, 8, 13 and so on.
The user stories estimated beyond 13 story points are considered very big to be completed in a single sprint and are therefore decomposed into smaller logical user stories which can be estimated individually.
During a Sprint Planning Meeting, the team will also create tasks under the user stories which have been selected for the Sprint. The team is not expected to task all the user stories during the Sprint Planning but it is just enough to get them started. The rest of the tasking can be done during the sprint.
The key outcome of a Sprint Planning meeting is the Sprint Goal and Sprint Backlog which consists of the user stories to which the team has committed to complete.
Apart from the User Stories, there can be some other type of items that can become a part of the Sprint Backlog.
- Technical Debts
Spikes are the research tasks for finding a solution i.e the need for which is triggered by the User Story itself. Some of the stories may not be straightforward or are not in the technical capability and hence would require more analysis and research around them. Therefore a spike is created. It may also include a POC if the need arises.
Technical Debts are the refactoring of the existing code. Many a time there are situations when the team has to rework on the code that was developed earlier to accommodate the new requirements.
Bugs in Scrum are usually the missed or new requirements that come out from the accepted user stories but is relevant to the current work items. If not a requirement, it can actually be a bug in the system that was unearthed during the previous sprints but was not fixed and has been prioritized in this sprint.
Everyone in the Scrum Team is a part of the Sprint Planning meeting. No one else other than the core team is invited to attend the meeting.
The Sprint Planning meeting is organized and facilitated by the Scrum Master but the Product Owner steals the show.
The Sprint Planning meeting may take as long as half a day for a two weeks Sprint. The time box for a Sprint Planning meeting depends directly on the length of the Sprint. Shorter for a short Sprint and longer for a long Sprint.
Sprint Planning meeting holds a very crucial role in the overall Scrum Architecture and directly affects the product that is being developed. Therefore the team should invest as much time as they think is required to discuss all the user stories in detail and can propose an alternative time box that suits them.
Once the time-box is decided and agreed upon, it is the Scrum Master’s responsibility to keep the team focused on the goal and at the same time keep a track of the time.
The Daily Standup
Daily Standup is a meeting which gives an opportunity to illustrate an overall view of the Sprint’s health. It is also a platform to discuss what the other team members are working on and if there is something stopping in achieving the Sprint’s goal.
During a daily standup meeting, every team member shares the status of his/her progress on the work items they are working on. They would also share and seek help from the other team members if there are any roadblocks blocking their progress.
During a daily standup meeting, every team member around the table answers the following three key questions one by one:
‘What have you done since the last Daily Standup Meeting?’
‘What do you plan to do today?’
‘Is there any impediment blocking your work?’
The other team members are expected to pay attention when someone is sharing the status and offer for help if the need arises. As soon as the last team member has answered all the three questions, the meeting ends there.
Daily Standup meeting gives an overall picture as to what is the current and overall completion status of the iteration they are currently working on. Scrum Master plays a very important role in keeping the Daily Standup meeting focused and time boxed. He is also responsible for resolving the impediments blocking the team from progressing with their User Stories.
Scrum Master also has to make sure that nobody other than the core team is asking questions and presenting status. He may allow quick discussions around the user stories if required but has to remain cognizant of the time all along and can anytime step in and ask the team members to have a discussion offline.
Anyone can attend a Daily Standup meeting. However, it is mandatory for the core team to attend the meeting and present the status of their work.
Anybody else even from the outside the team who is interested in knowing about the Sprint progress can attend the Daily Standup Meeting but is not allowed to present the status of his work or question the Development Team members on their work.
Only the core team members are allowed to share their work progress and everyone else is expected to listen silently.
The Daily Standup meeting should be conducted even if there is a single team member is present.
The team can conduct the Daily Standup Meeting on their own or can ask the Scrum Master to facilitate it for them.
As the name suggests, a daily standup meeting happens daily and the participants are expected to stand as it is a short meeting of 15 minutes only. The idea is to stick to the agenda and not to deviate the focus, therefore the meeting is kept short. Keeping the meeting also helps the people to easily commit to it as it demands only 15 minutes.
Daily Standup meeting is also kept at the same time and at the same location daily to reduce the confusion amongst the participants and overhead to book the meeting rooms daily. The use of laptops, desktops or mobile phones is highly discouraged during the meeting.
The teams can decide when to have the Daily Standup meeting and stick to it. However, the normal tendency is to keep the meetings the first thing in the morning. For the teams working in different time zones, the morning call may not work and thus they can have the call in the afternoon or whatever suits them the best.
The Scrum Master might also share the important news or updates at the end of the meeting with the team if time permits but is not allowed to extend the meeting at any cost.
The Sprint Review
Sprint Review Meeting is all about demonstrating the work done and gather the feedback and buy-in. At some places, the Sprint Review meeting is also known as Sprint Demo. Sprint Review Meeting is usually done at the end of the sprint but before the Sprint Retrospective meeting.
The chosen representative(s) from the team demonstrates the current sprint work items. Usually, the Developer working on the user story demonstrates the work and responds to the queries raised by anyone in the audience.
The user stories which are done based on the Definition of Done are the only candidates for the demonstration at the Sprint Review Meeting.
The Product Owner plays a very important role during the Sprint Review Meeting. He is the one responsible to evaluate each of the user story being demonstrated against its acceptance criteria and accepts or rejects the story.
The accepted stories are then integrated with the Done Increment which is a potentially shippable deliverable. Where would a rejected or uncompleted story go is the call of the Product Owner. The rejected stories can become a part of the next sprint or can move to the Product Backlog from where they will be prioritized again.
The key outcome of the Sprint Review meeting is an overall picture of the Project completion date. The Product Owner accepts/rejects the story and the accepted stories are then integrated with the Increment (created during previous sprints) as a whole to give a better picture as to where we stand in completing the entire product.
Another key outcome of the Sprint Review meeting is that the team members learn a thing about estimation. The number of user stories accepted determines the number of story points achieved in a sprint.
Thus gradually sprint by sprint, the team can develop the ability to estimate correctly and make an informed decision regarding the story points that are feasible to achieve.
It is often observed that such meetings shed light on the incomplete Acceptance Criteria or the` new requirements popping out. The best way to deal out of this situation is to close the stories and mark them done if they meet all the Acceptance Criteria that was initially agreed upon during the Sprint Planning Meeting.
Anything over and above that is to be considered as a new requirement and the Product Owner is responsible for those requirements for the future sprint.
Sprint Review Meeting is attended by the Team Members including the Scrum Master and the Product Owner. Other participants in the Sprint Review Meeting are the stakeholders, delivery managers, customers/end users or anyone who is interested in being a part of Sprint Review.
In an ideal scenario for a two weeks sprint, we spend approximately 2 hours in the Sprint Review meeting. This may vary based on the length of the Sprint. For a shorter sprint shorter Sprint Review and for a longer sprint longer Sprint Review.
Like other meetings, the Scrum Master is responsible to keep the momentum of the meeting and make sure the activities (demonstrating the stories, answering the queries, accepting the stories, feedback noted etc.) fits within the stipulated time frame.
The Sprint Retrospective
Sprint Retrospective is all about embodying what Agile says – ‘Regular reflections on how to become more effective’. Sprint Retrospective gives an opportunity for the entire team to reflect and contemplate as to how did the sprint go and what needs to be done to improvise the processes? Sprint Retrospective is performed at the end of each sprint.
During a Sprint Retrospective meeting, the entire team gets together and discusses the Sprint that was just completed. The team is expected to be transparent and give honest opinions but no blame games are around.
Remember the objective of the meeting to take a step ahead in the area of improvisation and not to hold the team by increasing the tension amongst the members.
Everyone in the team is expected to answer the four basic questions:
The Scrum Master asks the team members to write their points for each of the quadrants as displayed above in sticky notes. In some places, tools are used for the same purpose.
What went well?
The team members give one or more points on what went well in the last Sprint. This section can also be taken as an opportunity to appreciate and acknowledge the other team members for their good work.
What have you learned?
Scrum is considered as an opportunity to learn something new in every sprint. This area of a quadrant is to discuss the key takeaways and learnings from the last Sprint.
What didn’t go well?
Under this section, the team discusses the issues and obstacles they had faced during the last sprint. This part of the meeting tends to be the most fragile one as people might raise issues which may make the others uncomfortable.
It is the Scrum Master’s responsibility to tranquilize the atmosphere if the need is and teach people to raise their issues in a constructive way instead of going through the rounds of personal attacks.
If any of the members are uncomfortable in confronting the issues in front of the other teammates, he can go to the Scrum Master later on and discuss the issues.
What could be done better?
This part of the meeting gives an opportunity to all the team members to discuss all the issues raised earlier and find the ways to resolve them. Everyone in the team is welcomed to propose solutions to the problem at hand. The team then in unity decides over the best suitable solutions.
The team should also consider sticking to the things that were discussed under what went well section for the future sprints as well and going forward those things can be added as an integral part of the process.
The outcome of the Sprint Retrospective meeting is a list of action items agreed upon by the participants to improve the process for the upcoming sprint.
The entire Scrum Team including the Scrum Master and the Product Owner. But unlike a daily standup meeting, the Scrum Master and the Product also participates in providing their inputs and retrospective points.
Like Daily Standup meeting, Sprint Retrospective meeting is also facilitated by the Scrum Master. Scrum Master makes sure that everyone in the team including himself is given an opportunity to open up and speak both the positives and the negatives.
Take a note that participants outside the team are not invited to Sprint Retrospective Meeting. Sprint Retrospective is considered a little personal and emotional environment that allows the team members to open up without hesitation and discuss the issues they have faced during the last sprint.
It is rightly said that all the Scrum Ceremonies are time boxed and their time box depends on the length of the Sprint. Having said that, for a two weeks sprint, it is ideal to have a Sprint Retrospective meeting for 2 hours.
However, if we look at the Sprint Retrospective as an opportunity to communicate, retrospect and commit toward the improvements, it is very much justified to give enough time for the meeting to avoid losing on the important points of views and insights.
Thus it is good to time box the meeting but shouldn’t be done at the cost of communication and progression. Another very important event in Scrum is Backlog Refinement. Let us just a take a quick moment to shed some light on it.
Backlog Refinement which is also known as Backlog grooming is a meeting to discuss the user stories in the Product Backlog that might be a part of the next Sprint. In a backlog refinement meeting, the entire team sits together and discusses the user stories thereby providing their inputs.
The overall idea is to prepare the Product Backlog for the upcoming Sprint and to make sure that the user stories are ready to be picked. The Backlog Refinement meeting is organized during the ‘n-1’ sprint to prepare for the items to be picked in ‘n’ sprint.
With this, we have come to the end of this tutorial on ‘Scrum Events’ which is a must to read one. Scrum Events is by far the most important and significant topic of the Scrum Series.
In this tutorial, we have discussed all five Scrum Events i.e Sprint, Sprint Planning, Daily Standup, Sprint Review and Sprint Retrospective. Each event other than the daily standup has a regular cycle per sprint i.e. performed once in every sprint.
The events give an insight on how the tasks are accomplished in a Scrum environment. All the Scrum events are opportunities for improvement, adaptation, and inspection.
Coming up next is tutorial on ‘Defect Triaging’ which is a formal meeting where all of the defects of the current Sprint are discussed and triaged i.e. prioritized.