You can also listen Scrum Institute’s Podcast from Apple, Spotify, Castbox and Google Play.
Listen to Scrum Institute Podcast on Apple
Listen to Scrum Institute Podcast on Google Play
Listen to Scrum Institute Podcast on Spotify
Listen to Scrum Institute Podcast on Listen Notes
Listen to Scrum Institute Podcast on Castbox
During the Sprint Planning Meeting, the Scrum Team builds a viable Sprint Backlog, which determines the user stories and tasks the team is going to implement until the end of this Sprint (Product Increment).
A Sprint Planning Meeting constitutes two parts, namely the WHAT-Meeting, and the HOW-Meeting. As those names imply, the WHAT-Meeting focuses on the scope of a Sprint, whereas the HOW-Meeting focuses on how this scope will be implemented.
During Sprint Planning Meetings, the presence of the Scrum Product Owner is mandatory. So she can answer questions from the Scrum Team and bring clarifications for the requirements and their acceptance criteria.
Stakeholders such as end-users or line managers can join Sprint Planning Meetings as view-only audiences. They’re not allowed to influence the flow of the Sprint Planning Meeting.
The Scrum Product Owner defines the Sprint Goal. It is a concise and realistic description of what the Sprint will attempt to achieve for business, end-users, and IT systems.
The total capacity of the Scrum Team might change from Sprint to Sprint. To make realistic commitments, the Scrum Team needs to know its capacity for the upcoming Sprint.
The team needs to take vacations, public holidays, time spent on Scrum Rituals, and a small contingency for unforeseen issues into account to propose a reasonable capacity.
A Sprint Planning Meeting starts with a WHAT-Meeting. It requires some preparation:
The duties of various Scrum roles during the course of the WHAT-Meeting part of Sprint Planning Meetings are the following:
The goal of HOW-Meeting is to fill the Sprint Backlog by identifying the concrete tasks needed to implement committed user stories for the Sprint. These tasks usually (but not limited to) include activities such as analysis, design, development, testing, software build packaging, and documentation.
The HOW-Meeting can be done in a separate session after the WHAT-Meeting, or it may follow the WHAT-Meeting without a pause.
After identifying the tasks to be completed, the Scrum Team estimates these tasks. The unit for this estimation can be person-hours. Based on these estimates, the team has now its baseline about how long each user story will take them to deliver.
The Daily Scrum Meeting is a maximum of 15 minutes meeting.These meetings take place every working at the same time in the same place.
It’s best to conduct Daily Scrum Meetings with direct access to the Sprint Backlog and Sprint Burndown Chart. So the Scrum Team can direct the Daily Scrum Meeting based on the facts and progress which are visible to everyone in the team.
Daily Scrum Meeting aims to support the self-organization of the Scrum Team and identify impediments systematically.
All members of the Scrum Team, the Scrum Master and the Scrum Product Owner need to join Daily Scrums. Other stakeholders can also join these meetings, but only as a view-only audience.
Daily Scrum Meetings are structured in the following way. Every member of the Scrum Team answers three questions.
The Scrum Master has to moderate Daily Scrum Meetings.
She needs to ensure disciplined and fast-pacing progress so that all team members can answer these three questions in at most 15 minutes.
The goal of Daily Scrum Meetings does not include to give time-consuming decisions or solve problems.
On the other hand, no issues or concerns from any Scrum Team member should be ignored or undermined due to the time constraint of the Daily Scrum Meeting. Concerns associated with specific user stories must be clearly articulated, discussed, and resolved after the meeting with the Scrum Team members related to these user stories.
To align on decisions and solve problems, the Scrum team can organize separate on demand basis meetings. These separate meetings to focus on decisions or issues take usually place subsequently after Daily Scrum Meetings.
The Scrum Master documents the identified impediments and its dates in a separate log, ﬂip chart or report which is accessible to the team. We ﬁnd it very beneficial to quickly update the status of all known impediments at the very end of Daily Scrum Meetings.
The Sprint Review Meeting happens at the end of the Sprint.Regardless of the duration of the Sprint, it usually takes one to two hours. Depending on the type of software and available infrastructure, the Sprint Review Meetings take place in a meeting room, in a lab or in the room of the Scrum team.
The goal of the Sprint Review Meeting is to review the shippable product increment built during the Sprint and bring transparency to the product development process.
The Scrum Team members do not need to prepare a Powerpoint or Keynote presentation to show in the Sprint Review Meetings. They should instead spend their energy on the successful completion and demonstration of the Sprint outcome, which we call the shippable product increment.
The Scrum team demonstrates its work results. The Product Owner controls whether the Scrum team delivered the requirements they had committed during the Sprint Planned Meeting accurately or not.
The Sprint Review Meeting enables the Product Owner to inspect the current status of the product and adapt the goals of the subsequent Sprint. Therefore, Sprint Review Meetings are another way of formal and practical application of “inspect and adapt”.
Participants of the Sprint Review Meeting are the Scrum Team, the Scrum Product Owner, the Scrum Master. Optionally all other stakeholders such as end-users, clients, business representatives can join Sprint Review Meetings.
In Sprint Review Meetings, everyone is allowed to deliver their feedback about the demonstrated product increment.
In this way, the Scrum team has the opportunity to get unfiltered and direct input from stakeholders for whom they’re building the software.
The goal of the Sprint Retrospective Meetings is to improve the teamwork of Scrum Team members and the application of the Scrum process.
The Sprint Retrospective Meeting happens directly after the Sprint Review Meeting, and it closes the Sprint.
Therefore, Sprint Retrospective Meetings lead to an increase in productivity, the performance of Scrum Team members, and the quality of engineered software.
The Sprint Retrospective is an integral part of the “inspect and adapt” process. Without this meeting, the Scrum Team will never be able to improve its overall throughput, and they cannot focus on the improvement of team performance.
Remember this: What you focus on is what becomes better!
A Sprint Retrospective Meeting is virtually a mini postmortem to define improvement potentials and remove process-related obstacles. Some examples of such improvement potentials that we frequently see in our project are:
Without exception, the Scrum team conducts Sprint Retrospective Meetings at the end of every Sprint.
Only in this way, these meetings enable the Scrum Team to systematically adapt and improve their use of the Scrum process to the specifics of their project.
Scrum Backlog Refinement (Grooming) Meetings aim to keep the Product Backlog up to date. So the Product Backlog reflects the best know-how and understanding of the Scrum team about the ongoing Scrum project.
Scrum Backlog Refinement meetings can happen on-demand or scheduled basis up to two times a week, 30 minutes each session. The Scrum Team, the Scrum Product Owner, and the Scrum Master participate in these meetings.
During Scrum Backlog Refinement (Grooming) meetings, the participants ﬁne-tune the Product Backlog with the following actions:
Here are our other suggestions to improve the outcomes of Backlog Refinement Meetings: