Mandatory agile sprint meetings – Scrum ceremonies – part 2

In the previous post I’ve covered the meetings deemed necessary by the Scrum manifesto, however I always felt that two more meetings should be mandatory. As I mentioned before, in order to have a successful sprint planning session each team has to make sure that all stories are properly defined and estimated. All of this can be covered in a feature refinement session. Although this meeting can be encountered under many names: feature grooming session, backlog refinement session or backlog management meeting, the goal is the same – to have fully defined and estimated stories, ready to be picked up by the development teams. This meeting can cover all aspects of a story, from validating the story to writing acceptance criteria and validating requirements to proving an estimate. Depending on what the team wants to cover in this meeting in attendance should be at least the product manager, business analyst, development team lead or product architect and a QA representative. I highly recommend that all stories covered in this meeting should undergo a proper product ideation and validation process and to only cover here the final aspects like validating the acceptance criteria, dependencies, technical constraints, priority and estimate.

I would also encourage any team that takes agile serious to have a separate session for estimates and to use a proper process like planning poker. This way the estimates will be more accurate and all team members will be fully aware of what has to be accomplished through each story. Each team is different and the new story frequency varies a lot from company to company and team to team but in terms of frequency I’ve seen that having the session twice per week and timeboxing it to one hour works best.

Since the previous meeting only covered features each team requires a similar meeting in order to review defects, make sure that they contain all necessary data and their priority is set accurately. This defect is called the defect triage meeting and depending on how many defects are raised every sprint, how critical they are and how the teams are structured it can be scheduled with a varying frequency from daily to once per sprint. In attendance it is mandatory to have a QA engineer, a customer success team representative (or support team depending on how each organisation is structured) who is familiar with the defects that will be discussed – usually the lead and the product owner or if the team has a dedicated role the QA product manager. Main outcome of this meeting is to have every defect reviewed, prioritized and ready to be picked up by the development team. In order to keep the meeting as effective as possible it is important to have all defects validated prior to the meeting.

If a team schedules all mandatory meetings it will end up with the following structure:

• Sprint planning – once per sprint – lead by the product owner
• Sprint review – once per sprint – lead by the scrum master
• Sprint retrospective – once per sprint – lead by the scrum master / development lead
• Morning stand up – every day – lead by the product owner, scrum master or development lead
• Feature refinement session- twice per week – lead by product owner
• Defect triage meeting – daily / twice per week – lead by QA product manager

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

‍