Mandatory agile sprint meetings – Scrum ceremonies – part 1

The corner stones of every successful organisation are tailored processes that empower teams to make decisions and increases visibility and communication across the organisation. Even the most basic process relies on keeping everyone in the loop and the most effective way to do this is to have efficient meetings with everyone needed. This meetings will allow teams to plan their work in line with the company strategy, to report their successes and to learn from the challenges they faced and to keep team members and stakeholders aware of the work in progress.

I will start by describing in this article the meetings that should happen in a development team that uses the SCRUM methodology and for ease of use I’ve split the meetings in two categories: Mandatory and Recommended. While I feel that all teams should set in place the mandatory meetings the one ones in the recommended pile should only be used if needed. It’s always important to keep in mind that every meeting has a resource cost and that no one enjoys spending most of their time in meetings no matter how productive they might seem. Also it’s important to only invite to meetings peers that can bring value to the meeting.

My list of meetings that should be mandatory in a SCRUM environment:

• Morning stand up
• Sprint planning
• Sprint review (includes demo)
• Sprint retrospective
• Feature refinement session
• Defect triage meeting

My list of recommended meetings:

• Afternoon review
• Major retrospective
• Example mapping
• Design sprint
• Scrum of scrums
• Ready for development
• Ready for test

The morning stand up meeting is a daily meeting and as it’s name says it should be scheduled in the morning and the peers will have to stand. This is so people can pay attention and to focus on finishing the meeting as soon as possible. The attendance will be composed of: development team, scrum master and product owner (I’ve seen companies that also involved business analysts). The goal of this meeting is to give the team unity and to make everyone aware of the work being done as well as any issues that might occur. The goal can be achieved by having each peer answer 3 questions in no more than 2 minutes:

• What have you done since last meeting?
• What will you do until the next meeting?
• Is anything stopping you from achieving your goal?

Without this meeting in place you risk developers adding scope creep or not raising issues and wasting time.

The sprint planning session should happen on the first day of each sprint and in attendance should be the development team, the scrum master, product owner/manager and business analyst. The main goal of this meeting is to select the items that the developers will work on during the next iteration in line with their velocity. This is very important because what the team commits to has to be delivered by the end of the sprint. When the meeting ends the team will have a clear picture of what stories are expected to be completed as well as their priority. It is extremely important that the stories which will be discussed in this meeting will have complete specifications as well as estimates. If this isn’t the case the meeting might take a lot longer than planned and the goal might not be met since the team will have to complete the stories there and to provide ad hoc estimates. This meeting should be kept to no more than one hour for each week of sprint (e.g. if the sprint has two weeks the meeting should be two hours long).

The sprint review meeting will be scheduled at the end of each sprint and can be split in two parts – one that will focus on the team overall performance and one that allows the development team to present their completed work and receive feedback. In attendance for this meeting will be the product owner, scrum master, development team, business architect as well as representatives from the Customer Success, Support and Sales departments. It’s not uncommon in some organisations for the CEO to join the demo part of the meeting.

The first part of the meeting will focus on performance indicators and this is when the scrum master reports if the sprint goal was met as well as a review of the team’s velocity (how many story points they completed) as well as volatility (how they compare to other sprints). This is also a good chance for the team to raise any impediments that they faced as well as any suggestions they might have.

The second part of the meeting enables the development team to take ownership of their work and demo to stakeholders the items which have been completed. This is considered a final quality gate prior of release and will enable everyone to provide feedback. The stories should be presented exactly as they would be demoed to a new prospect customer. If a story fails the demo than that story will be pushed to the next sprint and will not be released. The scrum master has to update the velocity based on this.

To keep everything simple I’ve created a sample agenda for this meeting:

• Sprint release health status – what was commited vs. what was achieved
• Sprint indicators – velocity, volatility
• Discuss key occurrences and impediments during sprint.
• Demo of new functionality
• Conclusions

The retrospective meeting will happen at the end of each sprint after the sprint review meeting and will have in attendance just the development team and scrum master. This is an internal meeting where the team can analyze their performance as well as raise any concerns. The scrum master has to harbor a safe environment and to provide the team with an anonymous way of submitting topics for discussion (I’ve always used an empty sealed box placed either in a meeting room or in a discreet corner of the office. The aim here is to empower developers to raise any issues that impact their work (from inside or outside the team).

Based on the number of items that have been submitted the team can decide if they want to go over each or to vote on the most important. No matter how many tickets are discussed it is important that the scrum master sets a goal in place for each and action points. At the start of each meeting the action points from the previous meeting will be covered and see if the problem was resolved.

There are many ways in which a meeting can be run but I’ve seen that the following works best:

• Each peer can submit as many items as they want prior of the meeting
• At the start of the meeting the scrum master will allow peers to submit extra tickets
• The action points and goals from the previous meetings are discussed and the team will decide if the tickets can be closed. If not new action points will be created.
• The scrum master reads each new ticket one by one and places them on the board.
• Each team member gets two votes.
• The most voted 3 – 5 tickets get discussed in detail and a timeline and action points are created.
• The rest of the tickets go back into the box.
• If a ticket is not voted in 5 consecutive meetings it can be discarded.

This post has been published on www.productschool.com communities.

‍