GSA/christopher

---
title: Agile Meetings - Goals and Benefits
category: Agile
audiences:
  - Developers
  - Designers
  - Project Managers
---

<style>
  table {
    width: 100%;
    table-layout: fixed;
  }
</style>

### Scrum Meetings AKA Ceremonies

<a name="sprint-planning"></a>**1. <a href="{{ site.baseurl }}/guides/conducting_sprint_planning">Sprint Planning</a>**

|**The Meeting** | **Tips and Benefits**
|---------------|---------------|
| **Purpose:** To define a realistic Sprint goal and backlog containing all items that could be fully implemented until the end of the Sprint by the Scrum team. The sprint planning meeting results in two Scrum Artifacts, the Sprint goal and Sprint backlog.|**Who should attend:** The Product Owner, Scrum Master and the entire Scrum Team.|
|**How it is conducted:** {::nomarkdown}<ul><li> The Product Owner defines the Sprint Goal - a short description of what the sprint will attempt to achieve, clarifies the details on backlog items and their respective acceptance criteria.</li> <li>These entries are updated and broken into smaller stories by the team so that they can be completed within one Sprint.</li> <li>The stories are estimated, prioritized and tasked.</li> <li>The Scrum Team defines their capacity for the upcoming Sprint - the total capacity of the Scrum Team might change from sprint to sprint. In order to provide realistic commitments, it is necessary to know the total capacity of the team for the upcoming Sprint, with consideration of vacations, public holidays, etc.</li> <li>Tasks are assigned amongst the team members based on their experience levels and expertise.</li> <li>The team is ready to start with the daily sprints.</li></ul>{:/} |**Useful Tips:** {::nomarkdown}<ul><li>Timebox the meeting. Stop when you reach time. </li> <li>The Product Owner should have the Product Backlog prioritized and ready before the meeting. Only review stories that are ‘ready,' i.e. meets the Definition of Ready (DoR). </li> <li>Review and agree on the acceptance criteria that says when a given work is considered ‘done,' i.e. meets the Definition of Done (DoD).</li><li>The Scrum Team selects how much work they can do in the coming sprint based on their capacity and should not be influenced by the Product Owner.</li><li>The Product Owner should clarify with stakeholders on any unclear requirements for the team.</li> <li>Plan for collaboration of team members and NOT for optimal ‘resource utilization.'</li></ul> {:/}|
|**Benefits:** Below are some of the benefits of running a successful Sprint Planning meeting: {::nomarkdown}<ul><li>Enables the Team to agree on the sprint goal and commitment.</li> <li>Creates the platform to communicate dependencies and identify team capacity to set and commit to an achievable sprint goal.</li> <li>Ensures that daily sprints remain productive.</li></ul> {:/}

<a name="daily-scrum-standup"></a>**2. <a href="{{ site.baseurl }}/guides/conducting_daily_standup">Daily Scrum / Stand-up</a>**

|**The Meeting**  | **Tips and Benefits** 
|---------------|---------------|
|**Purpose:** To provide a platform for a Scrum team to get together and review progress toward their Sprint goal and assess any risks to their Sprint commitment.| **Who should attend:** The Scrum Master and the entire Scrum team, Product Owner (optional), and Outside stakeholders may attend by invitation of the team | 
| **How it is conducted:** {::nomarkdown}<ul><li>During the daily scrum, each team member answers the following three questions</li> <li> What did the team do yesterday?</li>  <li> What will the team do today?</li>  <li>Are there any impediments in the way?</li> <li>By focusing on what each person accomplished yesterday and will accomplish today, the team gains an understanding of what work has been done and what work remains.</li></ul> {:/} | **Useful Tips:** {::nomarkdown}<ul><li>The daily stand-up should be time-boxed</li> <li>Should be held at the same place or location and time every day</li> <li> Each member of the team should participate, and own/share responsibility of the full sprint backlog</li> <li> The Scrum Master facilitates  regular daily meeting times.</li> <li> Don't update the sprint backlog during this meeting.</li> <li> The goal should be to resolve impediments.</li> <li> Ensure that each team member remains present till the end of the meeting.</li> <li> Make sure it is understood this meeting is not a status update meeting in which a boss is collecting information about who is on schedule or behind schedule. Rather, it is a meeting in which team members make commitments to each other.</li></ul> {:/} |
| **Benefits:** Below are some of the benefits of running a successful Sprint daily Scrum meeting: {::nomarkdown}<ul><li> Enables the team to be in sync on how things are going</li><li> Allows for identification and solution of impediments</li><li> Provides an opportunity for small course corrections within the sprint </li><li> Building trust between team members </li> <li> High visibility of progress</li> <li> Promotes self-organization in team: team members hold each other accountable for achieving their daily commitments.</li></ul> {:/}|

<a name="sprint-review-demo"></a>**3. <a href="{{ site.baseurl }}/guides/conducting_sprint_review">Sprint Review (Demo)</a>** 

|**The Meeting**  | **Tips and Benefits** 
|---------------|---------------|
|**Purpose:** To provide the platform for the Scrum Team to showcase what they accomplished during the sprint while creating the opportunity to stakeholders to inspect and adapt the product as it emerges, and iteratively refine everyone’s understanding of the requirements. |**Who should attend:** Product Owner, the Scrum team, the Scrum Master, management/ stakeholders, customers and developers from other projects. | 
|**How it is conducted:** {::nomarkdown}<ul><li>The Scrum Master makes administrative arrangements for the review -- reserving the conference rooms, arranging for refreshments, getting additional presentation aids (projectors, whiteboards, flip charts, etc.).</li> <li> The Product Owner makes sure key business stakeholders are available to attend and confirm and assess the product or product increment.</li><li> The Product Owner provides a demonstration of features completed and reviews the commitments made at the Sprint Planning Meeting, and declares which items are accepted and considered done.</li> <li> Product Owner answers questions and gathers feedback from Stakeholders.</li> <li> The Scrum Master helps the Product Owner and stakeholders convert their feedback to new Product Backlog Items for prioritization by the Product Owner.</li></ul> {:/}|**Useful Tips:** {::nomarkdown}<ul><li> Timebox to one hour per week of Sprint length.</li> <li> Focus on acceptance criteria that has met the Definition of Done (DoD).</li> <li> Prepare and practice before the meeting.</li><li> Center the demo around a realistic user experience and business value (not just proving functionality).</li></ul> {:/}|
|**Benefits:** Below are some of the benefits of running a successful Sprint Review meeting: {::nomarkdown}<ul><li>Stakeholder engagement (early and frequent feedback).</li> <li> Maximizing Responsiveness to Customers.</li> <li> Team building and collaboration.</li> <li> Maximizing quality.</li></ul> {:/}|


<a name="backlog-refine-groom"></a>**4. <a href="{{ site.baseurl }}/guides/conducting_backlog_refinement">Backlog Refinement (Grooming)</a>**

|**The Meeting**  | **Tips and Benefits**
|---------------|---------------|
|**Purpose:** To review items on the backlog to ensure the backlog contains the appropriate items, that are prioritized, and items that are at the top of the backlog are ready for delivery.| **Who should attend:** Scrum Team, Scrum Master, Product Owner |
|**How it is conducted:** Occurs on a regular basis and may be an officially scheduled meeting or an ongoing activity. Some of the activities that occur during this refinement of the backlog include: {::nomarkdown}<ul><li> Refining and removing user stories that no longer appear relevant.</li> <li> Creating new user stories in response to newly discovered needs.</li> <li> Re-assessing the relative priority of stories.</li> <li> Assigning estimates to stories.</li> <li> Correcting estimates in light of newly discovered information.</li> <li> Splitting user stories which are high priority but too coarse grained to fit in an upcoming iteration/sprint.</li></ul> {:/} | **Useful Tips:** {::nomarkdown}<ul><li> Set a goal for the meeting.</li> <li> Treat the backlog refinement meeting just like the first part of the Sprint Planning Meeting.</li> <li> Ensure everyone understands that estimates are not final until Sprint backlog items have been accepted into a sprint.</li> <li> Consider doing some informal backlog refinement with SMEs before the full team backlog refinement.</li> <li> Assign action items for questions and any big risks or unknown items.</li></ul> {:/} |
|**Benefits:** Below are some of the benefits of running a successful Backlog Grooming meeting: {::nomarkdown}<ul><li> Helps ensure that the backlog remains populated with items that are relevant, detailed and estimated to a degree appropriate with their priority.</li> <li> Enables the Team to ask questions and have requirements cleared before sprint planning.</li> <li> Helps the team understand the project or product and its objectives.</li> <li> Helps the team break down larger stories into a more manageable, smaller stories, which makes for easier estimating, and saves time during sprint planning session.</li></ul> {:/}|

<a name="sprint-retrospective"></a> **5. <a href="{{ site.baseurl }}/guides/conducting_sprint_retrospective">Sprint Retrospective</a>**

|**The Meeting**  | **Tips and Benefits**
|---------------|---------------|
|**Purpose:** A meeting where the team discusses the just-concluded sprint and determines any changes to improve the next sprint. Looks at the “how” or team delivery process.| **Who should attend:** Scrum Team, Scrum master, Product Owner (optional) and Note: ideally no management.|
|**How it is conducted:** {::nomarkdown}<ul><li> Retrospective activities try to address three main questions/points through discussion: </li> <li> <i>What went well during the sprint cycle?</i></li> <li> <i>What went wrong during the sprint cycle?</i></li><li> <i>What could we do differently to improve?</i> </li> Example Topics include: <li> Milestones, dependencies, motivations, misunderstandings, processes, etc. </li><li> Process and way of working  </li><li> Focus on continuous improvement </li><li> Look ahead to mitigate possible risks or concerns </li><li> The meeting is facilitated by the Scrum Master.</li></ul> {:/}|**Useful Tips:** {::nomarkdown}<ul><li> Gather information/data based on facts. </li><li> Generate relevant insights - conversations over accusations. Open, honest and constructive. </li><li> Prioritize and decide on actionable commitments, assigned to a team member with a timeline. </li><li> Revisit issues and check-in on status in the future.</li></ul> {:/}|
|**Benefits:** Teams that conduct retrospectives at the end of each sprint (iteration) are able to: {::nomarkdown}<ul><li> Reflect on their process and agree upon a way of working. </li><li> Collectively find ways to improve productivity and reach goals. </li><li> Determine and constantly update the Definition of Done. </li><li> Continuously improve and evolve. </li><li> Build the team's sense of ownership and its self-management.</li></ul> {:/}|

<a name="scrum-of-scrums"></a>**6. <a href="{{ site.baseurl }}/guides/conducting_scrum_of_scrums">Scrum of Scrums</a>**

|**The Meeting**  | **Tips and Benefits**
|---------------|---------------|
|**Purpose:** Also known as a Meta-Scrums, the purpose of is to provide the platform for team representatives to share high-level updates on their respective team’s work, identify impediments, and collaborate on help needed from other teams.| **Who should attend:** Teams select a representative, or "ambassador," to attend the session who is able to articulate progress and impediments on their behalf. Depending on the context, ambassadors may be technical contributors, or each team's Scrum Master, or even managers of each team.|
|**How it is conducted:** {::nomarkdown}<ul><li> Teams select a representative as "ambassador" to attend the session who is able to articulate progress and impediments on their behalf.</li> <li> The "ambassador" participates in a daily meeting with ambassadors from other teams.</li> <li>During the meeting, each team representative answers the following three questions:</li><li> <i>What has your team done since we last met? </i> <li> <i> What will your team do before we meet again? </i> </li> <li><i> Is anything slowing your team down or getting in their way? </i> </li> <li><i> Are you about to put something in another team’s way? </i> </li> <li> Resolution of impediments focuses on the challenges of coordination between the teams</li><li> Solutions entail agreeing to interfaces between teams, negotiating responsibility boundaries, etc.</li></ul> {:/}|**Useful Tips:** {::nomarkdown}<ul><li> Track Scrum of Scrums items via a backlog of its own, where each item contributes to improving cross-team coordination. </li><li> Change attendees over the course of the project. Allow the team to choose its representative based on who will be in the best position to understand and comment on the issues most likely to arise at that time during a project.</li><li> Allow the team to frequency of the Scrum of Scrums meeting. Similar to a daily scrum, the suggestion is to have this session on a daily basis, if applicable. </li><li> Unlike the daily scrum meeting, if a problem is identified and is prioritized high, it should address in the scrum of scrums. Therefore, while many scrum of scrum meetings will be over in fifteen minutes, it’s recommended to budget more time to address potential problems.</li></ul> {:/}|
|**Benefits:** {::nomarkdown}<ul><li> Can be used as a technique to scale Scrum up to large groups (over a dozen people), consisting of dividing the groups into Agile teams of 5-10.</li><li> Allows clusters of teams to discuss their work, focusing especially on areas of overlap and integration. </li><li> Provides a platform to identify situations where teams need to coordinate </li><li> Keeps people connected by making sure that at least one member from each team sees one from every other team once a day. </li></ul> {:/}|

<a name="sprint-release-planning"></a>**7. <a href="{{ site.baseurl }}/guides/conducting_release_planning">Release Planning</a>**

|**The Meeting**  | **Tips and Benefits**
|---------------|---------------|
|**Purpose:** To commit to a plan for delivering an increment of product value that represents the amount of scope that a team intends to deliver by a given deadline. Enables multiple Teams plan development for a product release.| **Who should attend:** The Scrum master, Product owner, Delivery team or agile team, Stakeholders| 
|**How it is conducted:** {::nomarkdown}<ul><li> The Product owner prepares High-level vision, market, business objectives and a prioritized backlog. <li> Scrum master – Facilitates the meeting. </li> <li> The Agile Development team – Provide insights into technical feasibility and dependencies, overall capabilities, known velocity, technical impacts, etc.</li></ul> {:/}| **Useful Tips:** {::nomarkdown}<ul><li> Have a “definition of ready” for backlog items to be discussed during release planning. </li> <li> Ensure leadership and stakeholders are present and engaged. </li> <li> For small teams, make sure the entire cross-functional team is there to participate for both input and accountability purposes. For larger teams and organizations, a subset of the team may be selected or elected to represent the team. </li> <li> Establish a common baseline for sizing estimates. </li> <li> Logistics: Create an agenda in advance. Consider room size and breakout rooms or online video conferencing is available for distributed teams. </li> <li> Plan to limit releases deadlines - typically range between 2 and 12 months.</li></ul> {:/}|
|**Benefits:** Below are some of the benefits of running a successful release Planning meeting: {::nomarkdown}<ul><li> Provides the team a common vision about what needs to be achieved, and when. </li> <li> Provides the platform for collaboration across multiple teams to identify cross-Team dependencies and sequence of work. </li> <li> Guides the team to make informed decisions based on dependency, capacity and available skills.</li></ul> {:/}|

------
**More Resources on Agile Meetings**
* [How to Use the Daily Stand-up Meeting Effectively](https://www.scrumalliance.org/community/articles/2012/june/how-to-use-the-daily-stand-up-meeting-effectively) 
* [6 Common Misconceptions and Anti-Patterns of the Sprint Review Meeting](http://www.solutionsiq.com/6-common-misconceptions-and-anti-patterns-of-the-sprint-review-meeting/)
* [Backlog Grooming](https://www.agilealliance.org/glossary/backlog-grooming/)
* [Agile Release Planning Best Practices](http://enterprise-knowledge.com/agile-release-planning-best-practices/)