The scrum framework is a set of principles that help teams adapt to changing conditions and requirements. It helps learn and improve by taking into account the various factors that affect their work environment. So far, good project management and communication are two of the most critical areas that go hand in hand. It is important because in Scrum usually there is always a cross-functional team, and everyone is needed to be informed about the project from the idea to its implementation. Therefore, meetings or calls are essential.
In this post, we’ll break down the various types of Scrum meetings and explain why they are so vital to the success of the process.
The term "Scrum" was originally used by Hirotaka Takeuchi & Ikujiro Nonaka for their ground-breaking paper in 1986 in Harvard review. They borrowed the name from the game of rugby to stress the importance of teams in complex product development. Actually, scrum (short for scrummage) is a type of restart technique used in rugby where players gather around the ball and try to get possession.
The name from the game of rugby.
According to Takeuchi and Nonaka, scrum is “the whole process is performed by one cross-functional team across multiple overlapping phases, where the team “tries to go the distance as a unit, passing the ball back and forth”.
But there is a simple definition in The scrum guide:
Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.
So, we can surely say it is not an acronym.
At Mad Devs, we successfully implement Scrum for a long time with the help of, for example, boards in Jira and holding special meetings. In this article, you can find the instructions on how to create a scrum board. And about the meetings, we are going to tell you more further.
In order to get started, we should first identify the three artifacts in the scrum. These three constants are the artifacts that keep the team focused on the work and the overtime that's coming our way: product backlog, sprint backlog, and sprint goal.
The product backlog is the list of work that the product owner or the product manager needs to get done. It contains features, requirements, and fixes that are prioritized and maintained by the team.
The sprint backlog is the list of items that the team selects for the next sprint. These are the items that the team will work on during the sprint based on the current iteration of the product backlog. It can be flexible as it can evolve during a sprint, but the team's core sprint goal remains the same. The team selects these items before the planning meeting, and the sprint planning session begins.
The sprint goal is the usable end-product of a sprint. Some teams define it as "Done", something that's ready for release at the end of a sprint. It may be unrealistic to expect something to be ready for shipment every quarter. But work that's finished in 2-week sprints may be labeled "done", but it's still not ideal to expect that something will be ready for shipment immediately.
To monitor these artifacts, you have to set sequential events, ceremonies, or meetings that scrum teams perform on a regular basis.
A meeting in Scrum is a scheduled event that helps product groups improve their work processes. Each team member provides an overview of the current state of the project, and the other team members try to share their thoughts. Examples of Scrum meetings include daily standups, sprint planning sessions, and sprint retrospectives. It can be held online or offline.
In addition to team members, there are also important players that participate in the meeting.
Scrum defines three roles: the product owner, the Scrum Master, and the development team.
Sometimes it happens that the role of a scrum master or product manager is taken over by a project manager, or even both of these roles at the same time. But in order to easily and efficiently build a system for your company, let's review the basics and talk about the responsibilities and tasks of the main players.
The product owner is the person who decides what the product should be, what its purpose should be, and how it should perform. They have the final word on all of the details.
The product owner is also responsible for ensuring that the product is creating value for the users and the business. This includes meeting with customers and other stakeholder groups, as well as knowing when to say "no".
Product owner tasks are:
- Set product goals
- Responsible for product discovery and strategy work
- Ensure that the product backlog is stocked with clearly expressed items that help reach the product goal
- Order the backlog
- Regularly update and refine the backlog together with the developers
- Agree on sprint goals with the developers.
Ideally, a development team should be between 3 and 9 people, though this should not include the product owner. The team composition depends on the complexity of the product. For example, may include developers, project manager, designers, tester, etc.
The development team works together to get the work done according to the owner's expectations. They are organized and have a defined goal, which they check in with each other at least daily.
Their scrum tasks are:
- Manage the sprint backlog
- Inspect and adapt through a daily scrum
- Contribute to the sprint goal
- Adherence to deadlines and commitments
Scrum masters are responsible for guiding teams through the various phases of the scrum methodology. They coordinate with the product owner to draft actionable tasks that developers can use during the sprint.
The goal of a scrum master is to ensure that the team’s work is aligned with the company’s goals and the schedule.
The term “master” does not imply that the person has the authority to make significant decisions on the project. Instead, a scrum master is more about guiding the team through the entire project lifecycle, he or she is only there to manage the process and make sure that the work is completed successfully.
Scrum master tasks are:
- Coach employees and clients understand scrum
- Plan scrum implementations within the company
- Ensure that the goals, scope, and product domain are understood by everyone on the scrum team
- Adopt techniques for effective product backlog management
- Help the scrum team understand product backlog items
- Ensure the product owner knows how to arrange the product backlog to maximize value
- Facilitate scrum events as requested or needed
The responsibilities of scrum masters are considerable, but you can always invite them to teach their skills to the DMs and PMs in your company. Because their responsibilities may actually overlap in future projects and partly it is these employees who can take over the role of the scrum master.
Now let’s break types of scrum meetings.
Here are the most common types:
The daily scrum is a meeting that's designed to help the team plan out their work for the day. It allows them to identify any obstacles that could prevent them from reaching their goals.
Usually, these meetings are held in the morning and are typically only for 10 to 15 minutes.
A scrum daily meeting is focused on keeping the team's expectations aligned with the current state of the company. It should be short and do not include discussions about new ideas.
At Mad Devs as in many other companies, we used to call it standup. In the classic sense, such standups are held offline, each employee is given time, in turn, to tell the team about tasks and plans. With the new realities, this format has lost its relevance and asynchronous communication becomes a priority. That's why instead of face-to-face meetings or calls use a specific chatbot – Comedian to write daily standups in Jira. You can check Comedian on our GitHub and test it right now.
How to run a daily scrum meeting?
The core of this event is answering the three main questions:
- What did you do yesterday?
- What will you do today?
- Do you have any blockers impacting your progress? - things to bring up here might be technical limitations, team constraints, or personal limitations.
The questions that are asked during a standup meeting are usually focused on the team's current work and how they're contributing to the overall project development. Also, it helps Scrum master to improve the efficiency of the work based on the collected information.
Who all participate in the daily scrum meeting? Product owner, development team, scrum master.
Other important artifacts in scrum are sprints. A sprint is a set of tasks that team members work on in a short time frame to complete. Getting this right will help your agile team get the most out of its work. Each project is broken into time blocks known as sprints, which are usually carried out in 2-week intervals.
The team meetings are organized to determine which tasks will be handled during the next sprint.
Sprint planning agenda
Before the meeting begins, the product manager and the Scrum Master should review the team's current capabilities and the timeline of the project.
The sprint planning meeting should start with a discussion about the team's capacity and ultimate objective. It should also include a discussion about the backlog before the team begins working on the tasks.
It is a team meeting held before the next agile sprint. The product owner's list of prioritized features is presented to the team during the planning meeting. The team then asks questions to turn the discussion into a more detailed look at the product's backlog. So the team reviews its backlog and decides what items to prioritize for the next sprint.
During the planning meeting, the team will review the progress of the project and decide what should be done next to keep the project on track.
Some of the non-core items that were not completed during the previous sprints may be moved to the backlog.
Once you have a list of all the items that need to be completed, it's important to estimate the time it will take to complete each of them.
It’s also important to take into account the effort rating of each team member. Doing so can help gather valuable insights on how each team member can improve the task's complexity.
By estimating the items, you can determine which combination will fit into your sprint's constraints.
This scrum meeting template:
Remember that each sprint has its own specific goal, under which all team members commit and only then begin their work on the sprint.
After planning, all tasks should be evaluated and possibly broken down into sub-tasks. Then the team should be sent a meeting note with all the commitments - the goal and a list of the main sub-tasks or goals and deadlines for their fulfillment.
A sprint review, also called a demo, is a meeting that the team holds after a sprint, where they show what was done during the period. It's usually focused on demonstrating new features and improving collaboration. Generally, after the sprint, the team members are expected to review the work that was done and answer any questions that they might have.
Read how to organize software demo sessions to develop better solutions, build more trustful relationships with clients, boost the team’s motivation, and collect feedback.
The sprint review is usually conducted by the team, scrum master, the product owner, and the external and internal stakeholders. It typically lasts for an hour for each sprint. Participants in the sprint review typically include the product owner, the Scrum team, the Scrum Master, management, customers, and developers from other projects.
The Scrum Master should start by defining the time allotted to each item on the agenda so that the team can focus on the schedule. The product owner then explains the backlog items that were not completed during the sprint. The development team members then discuss the work that was done and provide feedback about their performance.
A sprint review is a great way to celebrate the team's achievements and to gather feedback on how the team performed. It also allows the team to reflect on the previous sprints.
The sprint retrospective is a regular meeting that the team holds at the end of a sprint to reflect on how well they performed during the previous sprint. It is usually the last thing done in a sprint.
So, the sprint review is an opportunity for the team to thoroughly inspect and adapt the product's development. During the meeting, the team members identify ways to improve the quality of their work. Everything that touches the product life cycle is also open for discussion and improvement. This allows the team to make changes and implement them before they get lost in the rush of new work. Even if the team's work is going well, retrospectives are still a great way to keep things going.
How to run a sprint retrospective?
There are many ways to conduct a sprint retrospective. One way is to use a simple table in Google doc and share it with team members before retro. But you can always add some creativity.
At Mad Devs, we prefer using Miro, a visual software, where you can add stickers on colorful dashboards. The retrospective takes place in an online format. At the meeting, each participant chooses a sticker and writes his or her insights, and then pins them on the board in the appropriate category - what was done, what was bad, suggestions for improvement, and gratitude. Sometimes we include interactive games and practical tasks.
The format is up to your collective choice and functionality.
Unlike sprint reviews that are conducted by the product owner or other external influencers, retrospective meetings are usually focused on the team members and team performance. The meeting should be facilitated by a Scrum Master. Everyone who is involved in the development of the product should also attend. Yes, the product owner is a part of the Scrum process, but he/she should attend only if he feels that his participation is needed.
Mainly, the development team meets and analyzes the work on the following issues that are divided into 4 parts. Here is an example:
After brainstorming ideas, the teams vote on which items to focus on during the next sprint. The list is then reviewed once the retrospective is finished.
Setting a positive tone for the meeting is very important to ensure that the positive moments from the previous sprint can be replicated in the future.
Among other things, retrospectives are also a field for inspiration. They can be themed or, for example, can include games and interactive activities. After all, this is a great way to assess the psycho-emotional state of a team, and games contribute to distracting from routine and generally help to reboot and connect with each other.
In addition to the above, we at Mad Devs use retrospectives also to thank each other for work or help in some processes. And simple “thank you” is wonderful. It really unites the team and motivates for new successful deeds.
One important thing is to remember - while the sprint review provides the team with an opportunity to improve the product, the sprint retrospective allows them to identify ways to improve their performance and coherence.
That's actually all! But we thought you were a little confused about who and where is participating. So you get a little bonus.
Sometimes people hate Scrum meetings, they think they’re not worth doing and are a waste of time. But it is only because they don’t know the following points.
A good meeting should always have a clear objective and purpose. Having a goal and a clear purpose helps avoid meeting off the rails.
Most of the time, team members dread a meeting due to them not being informed what the meeting is all about. Before a meeting, identify the type of meeting that’s going to happen and tell the team about it. This ensures that they come prepared and are not rushed. Having this practice helps minimize waste of time.
This is a simple but effective practice that will help increase the effectiveness of a meeting. Before the meeting, prepare a meeting agenda.
The agenda can help identify the various elements that will need to be discussed during the meeting. It can also help avoid wandering off from the intended topic.
A good practice before a meeting is to have the meeting’s agenda distributed among the team members. It helps them contribute effectively during the meeting.
Getting started and ending a meeting on time can put a stop to many negative outcomes. Follow the meeting schedule no matter who is present. Set a schedule for everyone regardless of who is at the meeting. Doing so will allow everyone to get to the meeting on time. One of the biggest no-nos when it comes to meetings is trying to fit in every team member’s needs. It only makes it harder to manage the meetings.
Avoid the situation when a team is constantly working on their own goals without having an alignment with the broader Sprint goals.
A good Scrum meeting should have goals aligned with the company’s overall goals. Doing so will make the meeting more productive and avoid adding extra costs.
Daily standups and frequent meetings are great ways to keep track of the team members' progress. They can also help you keep the vision alive if they get distracted.
One of the most important things to remember when it comes to planning a successful meeting is to look back at your previous sessions and try to improve. Doing so will help you develop the skills needed to excel in Scrum meetings. Actually, it is one of the most essential tips to have a successful scrum meeting.
Scrum is a framework that encourages teams to work together. It helps them develop self-organization and improve their skills by focusing on specific problems.
Scrum is the name given for a rugby team play, therefore it encourages teams to work together and develop self-organization. It also helps them improve by reflecting on their previous performances.
The practice of holding scrum meetings to synchronize the work of the team is probably the most useful of all agile development practices. Scrum meetings happen at particular points in the sprint cycle. In order for these meetings to really be useful, it is important to understand their goals, rules for conducting and take into account the specifics of the type of meeting.
Mad Devs probably already have a black belt in scrum meetings. When you work with us, you can have confidence in the product development process. Contact us to see for yourself.
Previously published at maddevs.io/blog.