May 07, 2017

5 Types of Scrum Meetings with 11 Best Practices

Scrum is probably the most popular application of Agile, where sprints (an iteration, a repeatable work cycle) are used to improve teamwork, communications, and speed on a project. Scrum gained much popularity due to the concept of daily stand-up meetings but many other types of meetings are recommended as part of a Scrum approach, such as reviews, retrospectives, planning, etc.




Scrum Meetings
Scrum Meetings

Sprint Planning Meeting 

Why: The purpose of the Sprint Planning meeting is to agree (and commit to) what can be delivered in the upcoming sprint as well as how will the team work to achieve it, based on the team’s velocity, capacity and the duration of the sprint. In short, its purpose is to plan and prepare for the upcoming sprint. The key outputs of the meeting are a spring goal (what does the team want to achieve by the end of the sprint) and a sprint backlog (list of the product backlog items and related tasks to be completed in the sprint).

What: The agenda of the Sprint Planning should include reviewing the sprint duration, defining the sprint goal, reviewing the team’s capacity and velocity, defining the sprint backlog.

Who: The meeting is facilitated by the Scrum Master, where the Product Owner confirms the priority and details of the product backlog items, and the entire Development team, who determines the effort required to complete the sprint.


Daily Stand-up Meeting

Why: The Daily Stand-up meeting, also known as Daily Scrum, is used to share information between the team, preventing critical knowledge or updates from falling through the cracks. By being a daily meeting, usually in the mornings and limited to 15 minutes, where all participants stand up, it also contributes to team cohesion and focus. While theory recommends daily meetings, in practice, depending on the nature of the project, frequency can be reduced, to be decided by the Scrum Master.

What: The agenda of the Daily Stand-up involves each participant answering 3 questions: a) what did you do yesterday, b) what will you do today, c) are there any obstacles in your way. Any follow-up discussions, like problem-solving, are taken offline.

Who: Only the Development Team and Scrum Master attend this meeting. While the Product Owner can join, s/he is not expected to contribute to the meeting, only observe. 


Sprint Review Meeting

Why: While the Sprint Planning meeting is held at the beginning of a new sprint, the sprint review meeting is held at the end of a sprint, with the purpose of assessing the project against the sprint goal and allowing the team to show what has been accomplished, usually as a demo of the new features. The meeting is intended to gather feedback and promote collaboration, resulting in an updated product backlog that will be used for the next sprint.

What: The agenda for a Sprint Review Meeting includes setting the scene by highlighting what was the sprint goal, present what is going to be demonstrated, demo the new features, close the meeting with the updated product backlog.

Who: Participants in this meeting typically include the Development Team, the Product Owner, the Scrum Master, and any key stakeholders invited by the Product Owner, such as management or customers.

Sprint Retrospective Meeting

Why: The Sprint Retrospective meeting is held at the very end of a sprint and enables a period of critical reflection by the team on how did the sprint go and what can be done to improve the way of working to make the next sprint more productive. While the focus of the sprint review is on what the team is building, the retrospective looks at how the team is building it and what lessons can be gathered from it.

What: The agenda of a Sprint Retrospective covers three questions to be answered by each participant: a) what went well during the sprint and we should continue doing, b) what went wrong doing the sprint and we should stop doing, and c) what could we start doing differently to improve. Finally, a list of commitments to the next sprint is defined.

Who: Attendees of this meeting are the entire team, including the Product Owner and the Scrum Master, who puts together a list of prioritized and actionable commitments to the next sprint as result of the retrospective.


Backlog Grooming/Refinement Meeting

Why: The Backlog Refinement, also known as grooming, is actually an ongoing activity that should be led by the Product Owner with the purpose of better clarifying what is entailed in each of the product backlog items, as these are usually too large or poorly defined. However, for large sprints, it may be beneficial to have a separate time-boxed Backlog Refinement Meeting near the end of the sprint to ensure the backlog is ready for the next sprint. By having this additional checkpoint meeting, the Product Owner can work with the team to clarify assumptions and answer questions in advance of the Sprint Planning meeting, enabling the Sprint Planning to later be kept focused and using as much information as possible.

What: The agenda of a Backlog Refinement meeting includes a review of the product backlog, and questions and answers for each product backlog item in preparation for the Sprint Planning meeting.

Who: This meeting is led by the Product Owner, who can invite whoever in the Development team is relevant to the decomposition of the product backlog items in discussion for the sprint.


Scrum Meetings Best Practices
Scrum Meetings Best Practices

Daily Stand-ups / Scrum Meetings Best Practices

Daily stand-ups can be very effective in managing a project but can also be very challenging at times to manage. If the stand-ups are not planned and managed well they could lead to people wasting time. If the team feels it is a waste of time attending these meetings then will stop coming to these meetings. Here are 11 best practices which will help a Scrum Master effectively manage this meeting.

1. Fixed Talking Points

The first question and the second question are about the the project related tasks that were done yesterday and what will be done today. This gives everyone an idea about what that team is working on. Impediments are nothing but road blocks or issues that a particular team member is facing. Examples of impediments are " Server access not setup", " unplanned environment outages", " functionality not working" etc.

2. Scrum Master In Control

It is important that the scrum master is in control of the meeting through out the time. If anybody deviates from the above talking points then the scrum master should bring the discussion back on track.

3. Same time and same place everyday

It is important that meeting is conducted at the same place and time everyday. The meeting has to be done on a daily basis to be effective. Ensure that you send out a recurring meeting invite with the talking points, time and place. The first few times people will come a bit late or will be disorganized but once the meeting is running for a couple of weeks people will turn up without reminders. Also choose a wall or board which is visible to other in the office or floor so that they know things are really moving.

4. Always stick to 15 Minutes Meeting

The daily scrum meeting should be wrapped up in 15 mins max everyday. Any detailed discussions should be take  on the side. It is important that the scrum master enforces these rules so that people don't waste others time.

5. Meeting Rules Notice

It is a good idea to have all the basic rules displayed near the meeting area. It  can be a simple print out with the rules listed as simple bullet points.

6. Full Team must attend

It is important that all the people from the project team attend. Generally, it takes a day or two for people to get used to the meeting so be patient. If someone is not attending then it is good to remind them by calling them or giving them a tap on the shoulder by going to their desk. If the someone is missing the stand-up regularly then it is better to escalate the issue. Full team includes the product owner.

7. Only One Conversation or No side conversations

From time to time there will be people with the nasty habit of starting side conversations during stand-ups. The scrum needs to remind everyone from time to time that only one conversion needs to happen at a time.

8. Always move cards /statues during the meeting

Team members should move cards or update statues only during the meeting so everyone is aware.
This will also ensure the scrum master is aware of what task is actually progressing. If a scrum master sees that team member does not move the statues for a few days then he or she can check with the team member to to see if everything is alright.  

9. Review the backlog everyday

The scrum master should review the backlog every single day with the team. It is also a good practice to make any updates in the front on the backlog so that the team is aware of changes to the backlog.

10. Done is actually done

A scrum master must define what does completing task include. Depending on the type of task the documentation and process that needs to be followed will vary.  For example if we are talking about a Test Case execution then the team member should ensure that with the actual execution of the test even the documentation and relevant sign off are completed.  Similarly for a UI Design it is important that with actual design completion the documentation, review and sign offs are complete as well. So it is important that the scrum master ensures all the required checks are complete before the item is marked as complete.

11. Leaving items / cards in the done column

This is a major moral booster for the team. When you move items to done column it is a good idea to leave them there for at least a few days. Everyone gets a sense of achievements when they see many done items on the scrum board. You can leave the items as long as you can but necessary to leave it there forever. Many time people who pass by also notice the progress and always keen on items in the done column. It gives a clear picture to everyone what the project team has achieved.

Daily Stand-up Best Practices
Daily Stand-up Best Practices

No comments:

Post a Comment