Scrum Institute, Scrum Framework Episode #13 has been proudly brought to you by International Scrum Institute, https://www.scrum-institute.org

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

What Is A Sprint Planning Meeting? This Might Surprise You!

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 Sprint Goal

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 Team Capacity

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.

The WHAT-Meeting 

A Sprint Planning Meeting starts with a WHAT-Meeting. It requires some preparation:

• The Scrum Product Owner defines the Sprint Goal.
• Based on this goal, the Scrum Product Owner chooses the candidate user stories for the Sprint from the Scrum Product Backlog.
• These user stories are edited and broken into smaller user stories when necessary so that they can be processed within one Sprint.
• The user stories are estimated and prioritized.
• The Scrum Team plans its capacity for the upcoming Sprint.

The duties of various Scrum roles during the course of the WHAT-Meeting part of Sprint Planning Meetings are the following:

• The Product Owner introduces the Sprint goal and her preselection of requirements, which should go into the product increment.
• The Scrum Team identifies the required tasks and their estimations. It’s the role of the Scrum Team to decide which and how many requirements preselected by the product owner they can confidently deliver in this Sprint.
• The Scrum Master moderates the meeting. She ensures that the self-organization and autonomous decision-making capability of the Scrum Team remain intact.

The HOW-Meeting

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.

What Is A Daily Scrum/Stand-Up Meeting? This Might Surprise You!

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. 

• Daily Scrum Meeting – Question #1: What activities have I performed since the last Daily Scrum Meeting? 
• Daily Scrum Meeting – Question #2: What activities am I planning to perform until the next Daily Scrum Meeting? What is my action plan? 
• Daily Scrum Meeting – Question #3: Did I encounter or am I expecting any impediment which may slow down or block the progress of my work? 

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, flip chart or report which is accessible to the team. We find it very beneficial to quickly update the status of all known impediments at the very end of Daily Scrum Meetings.

What Is A Sprint Review Meeting? This Might Surprise You!

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.

What Is A Sprint Retrospective Meeting? This Might Surprise You!

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: 

• Adoption of agile software development practices such as extreme programming (XP) or test-driven development (TDD), 
• Identification of new team norms and principles, or
• Increased availability of the Scrum Product Owner.

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.

What Is A Scrum Grooming (Backlog Refinement) Meeting? This Might Surprise You!

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 fine-tune the Product Backlog with the following actions:

• Add new user stories based on newly discovered requirements.
• Remove user stories which are no longer required for the product.
• Fine-tune estimates of user stories.
• Update priorities of user stories.
• Split giant user stories into digestible smaller user stories, and prioritize them accordingly.

Here are our other suggestions to improve the outcomes of Backlog Refinement Meetings: 

• Ensure Cross Team Participation, which means you identify the dependencies as early as it is possible, 
• Size User Stories Correctly, which means all user stories can result in a shippable product increment within one single Sprint,
• Prioritize User Stories, which means you deliver immediate value to end-users, enable quick wins, and make them happy,
• Estimate Like a Pro, which means you obtain actionable inputs for reliable release planning,
• Identify Dependencies, which means you pull required teams and resources on board to make your project a success,
• Uncover Risks, which means you avoid tedious surprises during the later stages of your project.