Scrum Meeting Template
Updated: Mar 2, 2022
In this article, I want to share a list of templates you can use to increase the management, control, and monitoring activities related to scrum meetings. These templates are very simple to use and work great when your team is new to scrum or when your meetings are less effective. When using these templates, it is important that you share them with your team and assignee an owner that will heled the responsibility to manage, share and monitor the progress over time.
credit: Marija Hajnal
The Retrospective meeting
The retrospective meeting has been around since the beginning. It is one of the core principles described in the Agile manifesto "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." The retrospective meeting is the platform that allows the team to discuss and understand how they can improve the current process and increase the effectiveness of their work.
In addition, the retrospective meeting allows the team to achieve other goals:
It creates a blameless space for team members to share their valuable feedback.
Promotes self-organization and a sense of ownership.
Determines new ways to improve the process.
Identifies system constraints and waste.
Provides a clear definition of impediments, allowing the team to create a mitigation plan and monitor progress.
Shows what does work, so the team can keep using good methods.
Template:
You will use this template to manage all items raised by the team and share it with relevant stockholders (e.g. Scrum Team, specific manager, etc.) and review its progress) at the start of the next retrospective meeting.
Impediment – What is the problem/concern raised during the meeting?
Mitigation Plan – how do you intend to remove this impediment?
Owner – Who is responsible to mitigate this item?
Eta – Estimated time until resolution.
Status - On-hold, in-progress, blocked, or Done.
Refrainment (AKA: Grooming) Meeting
As part of the refinement meeting, the team (usually the PO, SM, and selected members of the development team) collaborate to prepare the product backlog for future sprints. This usually includes adding and modifying product backlog items (features, epics, and stories) to make sure they are ready for work. Otherwise, the team will spend hours doing this during the planning meeting itself, making it less efficient. In my teams, there is at least one refinement meeting per sprint. This is used to ensure that the team is familiar with the stories and their acceptance criteria, and to provide a rough estimation for the stories that are candidates for the next sprint.
The refinement process includes several activities that the team should follow to ensure they achieve the expected benefits:
Splitting large or complex stories into smaller stories that the team can deliver within a single sprint.
Estimating stories and updating old estimates based on new information.
Removing dependencies between stories.
Adding new customer requirements (stories) or updating existing stories.
Removing any product backlog items that are irrelevant or have become obsolete due to changes in the requirements.
Adding new technical stories that support the delivery of functional stories.
Reviewing and updating stories with DoDs, acceptance criteria, test criteria, and technical information.
Focusing on specific areas of the product backlog to enable long-term technical, testing, and project planning.
Item Name – The name and unique ID of the item in the backlog.
Type of Action – specify the type of action (Newly Added, Modified, Story Removal, and Change in prioritization).
Description – Add a High-level description of the change.
Planning Meeting
The sprint planning meeting is one of the most important meetings in the Scrum framework. It allows the Scrum team to plan the work for the next sprint. The plan is created by the whole Scrum team, including the Product Owner, Scrum Master, and the Scrum development team. Like all other activities in the Scrum framework, the sprint planning meeting is time-boxed to two hours, multiplied by the number of weeks of your sprint (range of 2-8 hours). During the sprint planning meeting, the Product Owner provides a quick overview of the highest prioritized backlog items. The team can ask any questions they have, so they can start breaking down stories to tasks and estimating the work required to complete them.
Story Name/ID– The name and unique ID of the item in the backlog
Priority – The priority the team should follow during the sprint.
Hard Vs Soft Commitment – Hard commitment defines the stories that the team believes they can deliver, while soft commitments define the stories that the team will add to the sprint in case of completion of all stories.
The Sprint Review Meeting (AKA Demo)
In the Scrum framework, each sprint is the sum of the commitments made by the Scrum team, which amounts to a potentially shippable product increment. For the product to be considered ready at the end of each sprint, the team commitments must cover aspects such as gathering requirements, designing, coding, and the various quality activities that guarantee the feature’s readiness. The review meeting is held at the end of each sprint (on the last day) and is facilitated by the PO. The meeting allows the Scrum team to demonstrate to relevant stakeholders what they accomplished during the sprint and to get feedback on their work.
The main objective of the meeting is to allow the team to share their accomplishments and get feedback about their work. The meeting also has some additional objectives:
Building internal confidence by celebrating achievements.
Reviewing key decisions made during the sprint.
Demonstrating completed stories, but also sharing problems encountered (high-level description of stories that were not completed).
Reviewing the project’s progress (the Product Owner leads a discussion on the product backlog as it currently stands) and anticipating work needed for future product releases.
Story Name – The name and unique ID of the item in the backlog.
Feedback – What is the generated feedback as it was described/questioned during the meeting.
Following actions – Based on the received feedback what should you do in your next iteration?
Owner – who is responsible to perform this action (Team member or any other stakeholder)?