🗓️Scrum Meetings
Video Version
Scrum "Meeting Cadence"
Meetings are often called "cadences" in Scrum, implying that they always keep happening. They become a part of the operating rhythm of the Scrum team. Every sprint, there are meeting "cadences" that always happen no matter what.
The Scrum Framework has the following meeting cadences
Sprint backlog refinement
Level of effort estimation
Sprint planning
During the sprint
Daily standups
Sprint demo / Sprint review
Sprint retrospectives
Here's a visual of what Scrum meeting cadences look like:
Scrum Meeting Breakdown
Backlog Refinement Meetings
Backlog Refinement
What is it?
During backlog refinement, teams get together and discuss the work that's being documented before it starts. They discuss:
The scope of tasks
Whether the work is feasible
What the design members and development members think need to be considered or included
How complex is the work
Who owns it?
The Product Owner duty owns this in the Scrum method.
The Product strategy function owns this work in Tech Fleet.
When does it happen?
Backlog refinement should be a daily task for product teams.
What are the outcomes?
The result should be tasks for the team that are ready to be taken on in sprints. This could be for research, design, or development.
Sprint Planning Meeting
Sprint Planning
What is it?
Sprint Planning meeting is a meeting where the entire team gets together and plans their next upcoming sprint. Product Strategy teams should rely on the team to consult in priorities based on current and previous work, and the entire team should align together in the goals.
Who owns it?
The Product Owner duty owns this in the Scrum method.
The Product strategy function owns this work in Tech Fleet.
When does it happen?
Teams do this before every sprint begins.
What are the deliverables and outcomes?
Level of Effort Estimation
Level of Effort Estimation
What is it?
Level of effort estimation is an activity where teams estimate the complexity of upcoming work.
WLevel of effort should be measured for all kinds of work: research, design, and development alike. Teams should gauge level of effort for their work so that they have an idea of what's too much work for a given iteration, and can track the changes over time.
Measuring level of effort changes team-to-team. The overarching goal of an Agile team each iteration is to finish what they commit to. IF they have committed to too much work and can't finish, they should reduce the scope of the iteration's work itself; this is important to continually progress in delivery of the work and avoid work that is in progress for too long without delivering.
In order to do this successfully, teams must measure the effort levels of tasks in their backlog. This helps to holistically understand how much work is "too much" for the team in one iteration. Depending on the Agile method, teams may plan entire iterations (like Scrum method) or pick up one-off tasks as they are ready for the work (like Kanban method). All methods of Agile require teams to measure their effort; this may lead to breaking down tasks or splitting them out into separate tickets, and will save teams from unfinished work at the end of iterations.
Each team is highly unique in the case of how much work they can get done in one iteration. It depends on their skills, their availability, and a lot of other things. The methods of measuring level of effort remain the same, but the number of stories each team can get done in one iteration is highly variable and changes team to team. Learn how to measure level of effort in the next lesson.
Velocity is measured in story points per sprint. For instance, you'd describe the velocity of the team by saying "The team's velocity is 20 story points per sprint; the team can finish 20 story points of work on average every sprint".
Who owns it?
The Scrum Master duty owns this in the Scrum method.
The Product strategy function owns this work in Tech Fleet.
When does it happen?
Tickets in the backlog should be estimated with their level of effort before they get planned for sprints. This helps the team measure their speed.
What are the outcomes?
Estimated tickets ready for sprints
Planning poker results
Activities During the Sprint (AKA "In-Sprint")
During the Sprint
What is it?
Everyday during the sprint, the team doing the work needs to rally around the work. Tasks could be any kind of work: research, design, product management, development, or other kinds of work. The team needs to reflect and take action on adjustments during the sprint so that they can achieve their shared outcomes together.
Who owns it?
The entire team is responsible and accountable for successful sprint outcomes.
When does it happen?
Everyday in the sprint.
What are the outcomes?
Finished work
Daily Standups (AKA Daily Scrum)
Daily Standups (AKA Daily Scrum)
What is it?
A daily standup is a full-team touch base for visibility. Everyone on the team needs to attend standup everyday to report on their progress:
What did you do yesterday?
What are you doing / did you do today?
What blockers do you have?
The most important aspect of this meeting is identifying blockers for the team, things that prevent team members from succeeding in their work. Together the team should discuss what they should do to remove the blockers together.
Who owns it?
The entire team is accountable to run standup.
The Product Owner and Scrum Master should not be attending these meetings. As a self-organized team, the team itself should run and hold these meetings.
When does it happen?
Everyday
A live or asynchronous 15 minute meeting
What are the outcomes?
Full team visibility into progress.
Unblocked blockers.
Sprint Demo / Sprint Review
Sprint Demo / Sprint Review
What is it?
The sprint demo is a key moment in the sprint lifecycle. The team gets together at the end of their sprint and shows their work in progress. Whatever is half finished or fully finished is shown. They collect feedback from clients and teammates so that they can determine the direction they need to head for the next round of sprint planning.
Who owns it?
Scrum Master duty owns this in the Scrum method.
The Product strategy function owns this work in Tech Fleet.
When does it happen?
This happens at the end of every sprint increment.
What are the outcomes?
Sprint Retrospective
Sprint Retrospective
What is it?
The Sprint Retrospective is a time for the team to get together and reflect. They reflect on their work process and their teamwork together. They discuss:
What they liked that they want to continue
What they learned in hindsight that they want to change
What they lacked that they want to change
What they longed for that they want to change
Who owns it?
Scrum Master duty owns this in the Scrum method.
The Product strategy function owns this work in Tech Fleet.
When does it happen?
This meeting should happen during each sprint increment.
What are the outcomes?
Updated Working Agreements
One-Week Sprint Example
This is what daily work looks like when teams operate one-week sprints.
Before the sprint:
Sprint planning
Refinement
Level of effort estimation
During the sprint:
Daily standups
Do the work that was planned
Sprint demo at the end
Sprint retro for previous sprint
Two-Week Sprint Example
This is what daily work looks like when teams operate two-week sprints.
Before the sprint:
Sprint planning
Refinement
Level of effort estimation
During the sprint:
Daily standups
Do the work that was planned
Sprint demo at the end
Sprint retro for previous sprint
Head to the Next Lesson
Last updated