SCRUM Ceremonies

There are primarily four SCRUM ceremonies that we can go through in chronological order.

Video: SCRUM Ceremonies

Sprint Planning

First in order comes Sprint Planning. Now typically this comes on the first day of the Sprint and typically lasts for two hours for a two-week Sprint. Some teams also do it on the last day of the previous Sprint. SO! What happens in this meeting? Well. The team looks at the Product Backlog. The Product Owner would have already set the priorities in the Backlog. And the team would pick up Stories that they can do in the Sprint. Not only will they pick up stories, but they will also create tasks underneath the stories that are required to implement the requirement.

NOW! How would the team know how many stories they can pick up for the Sprint? We will look at it in the article about Sprint Planning in detail along with Story Point Estimation.

Daily SCRUM

And then we have the Daily SCRUM ceremony (a.k.a Daily Stand-ups) and is not supposed to last more than 10-15 minutes. Here the SCRUM master runs the meeting with the SCRUM team and Product Owner as participants. Other stakeholders can join optionally based on the need. Now in this meeting, every team member updates the others with the following three points

• What he did work on yesterday
• What he will be working on today
• Is he facing any blockers or impediments

NOW! I told you that this meeting is not supposed to last more than 10-15 minutes. What happens if there is a blocker for one of the team members or if there is any dependency that needs a lengthy discussion? Well. If the blocker or dependency is not resolvable in the stand-up within a few minutes. It is taken offline in another meeting with only the concerned parties involved. That way it would save time for other team members.

Sprint Review

Sprint Review is one of the SCRUM ceremonies that happens at the end of Sprint. Typically on the last day of the sprint. Some teams do it on the first day of the next Sprint. For two week Sprint, this nearly lasts for One and a half to two hours. Here the story owners demonstrate the work they have done in the Sprint to the Product Owner and the business.

Retrospective

And then at last we have the Retrospective which as the name suggests allows the team to introspect. The team discusses and identifies three things at a high level

• What went well during the Sprint
• What did not go well during the Sprint
• Action items

Other Ceremonies

We discussed four primary ceremonies. There are a few other SCRUM ceremonies that are worth discussing.

Backlog Grooming

Backlog grooming a.k.a refinement. Remember we said that in Sprint Planning the team picks up prioritized stories from the backlog. But when exactly is the backlog prioritized and when exactly are the requirements in backlog refined?

• The requirements need to be crystal clear. All possible questions need to be answered by the Product Owner and business before the team picks the stories. When do all these happen? “Backlog Grooming”
• Here stories or picked up in the decreasing order of priority and then the team discusses the requirement and gets any pending questions clarified
• Typically this ceremony lasts for 2 hours for a two-week sprint. And happens right in the middle of the Sprint

Roadmap Briefing

Roadmap briefing happens typically anywhere between once a quarter to once a year. Here the Product Management briefs the entire organization on what is the roadmap that is planned for the year ahead. Keep in mind it is this road map that gets translated into requirements that get arranged into Backlog.

Release Planning

Keep in mind feature releases may take more than one Sprint to get released. So it is important for an Engineering Organization to have a release cadence defined. Each release cadence has a certain set of a fixed number of Sprints allocated and the team plans on how many features do we deliver as a part of the upcoming release.

Bug Triaging

Bug triaging is where the Dev and QA come together to discuss the bugs identified. PO moderates the discussion and has the final say on the Bug. Remember! It is not always the QA who raises the Bug.