The most important aspect of the Agile Manifesto and its twelve principles is delivering value to the customer or user. In order to achieve this, teams need to maintain a shared understanding of customers’ needs and of the work that must be done.
The Agile approach is especially important in complex project and product environments that deal with a high level of uncertainty, and several types of Agile meetings (or ceremonies) are key to its success.
In this article, you will learn more about these types of meetings, as well as how to implement them.
Rules for Meetings
Each meeting in the Agile world has a unique purpose and a set of rules for conducting it. To benefit from these meetings, you need to know the purpose, the rules, and the requirements of each type.
The Agile methodology is not a framework but an umbrella philosophy that encompasses multiple methods and frameworks. You may think of Agile meetings primarily in terms of the Scrum ceremonies described in The Scrum Guide, but these practices are valuable in nearly all Agile contexts.
As an Agile coach, I have observed many teams use these ceremonies for a time, then lose focus. Sometimes teams may need to get reoriented. Here are some tips that work for all Agile meetings.
Do:
- Understand the purpose of the meeting type
- Have the right people at the meeting
- Run the meeting because it brings value to your team and its work
- Make room for every voice and encourage introverts to contribute
- Choose the proper setup, methods, and practices
- End the meeting when the work is done, even if it’s early
- Support the team in moving forward
- Use visualization as often as possible
- Ensure everyone comes prepared
Don’t:
- Run a meeting just because “everyone is doing it”
- Mix up different meeting types
- Follow the rules blindly
- Run a meeting without any outcome (e.g., decisions, further questions)
Because Agile focuses on teamwork and collaboration, communication is key. Agile meetings can help you communicate in a structured, focused way.
If you use Agile meetings properly, they will produce the following benefits:
- Support for team building
- Shared understanding of the work to be done
- Focus on the right things to do and alignment on the goal
- Transparency in processes and progress
- Continuous improvement through constant feedback and early identification of challenges
Let’s take a closer look at each of the Agile meetings.
Sprint Planning
The sprint planning ceremony comes at the beginning of each sprint. The Product Owner and the Scrum Master (or similar roles) and the development team commit to the sprint goal. For that goal, the development team decides which product backlog items (PBIs) or user stories (US) will enter the sprint backlog. The sprint goal should be challenging but not impossible, and it should consider the business need as well as the capability of the team.
After selecting the items, the development team creates a strategy to reach the sprint goal and presents it to the Product Owner and Scrum Master. The development team checks to see that it has all the necessary information to work toward the sprint goal and double checks that the estimates are still valid.
This meeting references principles 8 and 11 of the Agile Manifesto.
Principle 8 is about keeping a constant pace that’s directly linked to the capacity of the team:
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
In Principle 11, self-organizing teams are the solution for developing great products. Sprint planning is self-organizing:
The best architectures, requirements, and designs emerge from self-organizing teams.
Purpose:
- Commitment to the sprint goal
- Alignment on what has to be done
- Clarity about how to reach the sprint goal
- Just-in-Time capacity planning for more reliability and predictability
- Clarification of last questions and inconsistencies
Anti-Patterns:
- The Product Owner determines which and how many items go into the sprint backlog
- The development team doesn’t think about how to reach the sprint goal
- Capacity planning doesn’t match the capability of the team
Standup/Daily Scrum
The standup or daily Scrum is a brief but valuable meeting. It happens every day at the same time and in the same place. This ritual makes it easy for participants to structure the day around the standup. Everyone in the development team shares insights on the following questions:
- What have I done in the last twenty-four hours to add value to our sprint goal?
- What am I planning to do today to add value to our sprint goal?
- Which impediments came my way that may potentially jeopardize our sprint goal?
The Product Owner is invited to take part in the meeting but has no speaking time. The Scrum Master helps the team to run the meeting.
Not only does the standup give transparency to everyone about the status of work, it makes impediments visible at an early stage. The teams can figure out how to remove the blockers from their flow. Additionally, by sharing their goals, they’re better able to focus on them.
The standup helps to bring principle 4 of the Agile Manifesto into practice:
Business people and developers must work together daily throughout the project.
Purpose:
- Provide an update on accomplishments and goals
- Identify blockers and take action on them
- Strengthen the individual focus of each team member
Anti-Patterns:
- Only one person is speaking during the fifteen minutes
- Product owner never takes part
- The answers are always “Same as yesterday!”
Can’t answer all the questions or solve the problems during a fifteen-minute timebox? Encourage those responsible for finding a solution to make connect separately and let the rest of the team go back to work.
Sprint Review
Since customer satisfaction plays an important role in Agile, in this fast-moving VUCA world, you need customer feedback in short cycles to ensure you’re still on the right path. In the sprint review, the development team presents the results of the last sprint to the Product Owner, the Scrum Master, and eventually some representatives of the customer or other stakeholders.
The Product Owner and the customer give feedback to the development team. If any part of the results are not accepted, the development team will fix this during the next sprint.
The sprint review corresponds to principle 1 of the Agile Manifesto:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Purpose:
- Progress update for Product Owner and stakeholders
- Presentation of results for feedback
- Identifying failures and misinterpretation at an early stage
- Continuous learning
- Maximizing customer satisfaction
Anti-Patterns:
- The team has nothing to present
- The team or the Product Owner regularly skips the review
- The Product Owner or stakeholder doesn’t offer feedback
Sprint Retrospective
At the end of each sprint comes the sprint retrospective. In this team meeting, the development team, the Product Owner, and the Scrum Master review how they have worked together. In many teams, the Scrum Master is the facilitator of this ceremony. If you don’t have one, each team member can take that role. The retrospective is an excellent starting point for continuous improvement and working to become more Agile; it delivers value even to teams unfamiliar with Agile methods.
The retrospective is mentioned in principle 12 of the Agile Manifesto:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
To get the most benefit out of the retrospective, it should be interactive and engaging. It is divided into five phases:
- Set the stage
- Gather data
- Generate insights
- Make decisions
- Closing
There are creative exercises available for each phase. One useful source is the Retromat.
To run a valuable retrospective, psychological safety is a prerequisite. Many experienced facilitators use the Prime Directive and the Vegas Rule at the beginning of each retrospective to maintain the right approach:
- Vegas Rule: What happens in the Retrospective stays in the Retrospective.
- Prime Directive: Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. – Norman L. Kerth
Purpose:
- Learn more about the collaboration during the last sprint
- Find out: What was good? What didn’t work? What is missing?
- Make problems visible
- Understand the Why of what worked/what didn’t work
- Make decisions together
- Strengthen the trust within the team
- Continuous improvement of collaboration
Anti-Patterns:
- Everything is always “good”
- No one wants to speak about “bad” aspects
- Only one person is speaking
- The team makes decisions, but nothing happens afterward
Backlog Refinement
Backlog refinement is an ongoing process and not an explicit ceremony. But many teams do this significant work in a separate meeting because, otherwise, it would be neglected or forgotten.
With backlog refinement, you take responsibility for cleaning and prioritizing your backlog. Since requirements and learnings change during the development process, the backlog should not be written in stone. With the refinement ritual, you pick out the old and no-longer-necessary items and throw them away.
In the refinement process, the development team, the Product Owner, and the Scrum Master check if the definition of each item is good enough to work on and catch if anything crucial is missing. They can add or specify acceptance criteria and other important information until the team’s definition of ready is fulfilled. If there are open questions, the team takes action to clarify them. The team reviews the estimates; if there are no estimates yet, the team will create them. The feedback and the learnings from the sprint review will influence the backlog refinement and priorities.
Holding an extra meeting for refinement can sometimes get boring—people have problems concentrating and the quality drops. I prefer the ten-minute story time. After each standup, the team picks one item and refines it for a maximum of ten minutes. This provides an ongoing process and a set time for completing the task. Other teams run one meeting each week. You should determine what’s best for your team.
Backlog refinement refers to principle 10 of the Agile Manifesto:
Simplicity—the art of maximizing the amount of work not done—is essential.
The better the team understands what’s required, the less likely they are to do unnecessary work.
Duration:
There is no official timebox for backlog refinement. Older versions of the Scrum Guide suggest that teams block ten percent of the sprint time for it, but you should take as much time as you need to refine the work items. That will depend on the quality of the requirements, their complexity, or the experience of the Product Owner or development team.
Purpose:
- Determine the status of the backlog
- Make sure critical information is in place so the team can concentrate on development
- Prepare for a successful sprint
- Make sure that everyone is on the same page
Anti-Patterns:
- Items are poor quality
- The team has to rewrite the items
- Too much information is missing
- The team only wants to be “ready” and doesn’t concentrate on the task
- One person is doing it alone
Conclusion
Using different types of meetings for specific purposes supports the Agile concept of working in a structured way. Staying focused and on topic helps increase work quality and motivates your team.
Take some time to review your meetings, so you know if you are still following their original intent or have unconsciously left the Agile path. You may find room for improvement.
