Agile ceremonies are structured meetings that help product teams plan, track, and review their work. These ceremonies are designed to promote collaboration, transparency, and accountability, and to help teams stay focused on their goals.
Agile ceremonies are best thought of as patterns that are commonly found in high performance teams, rather than a rigid process that must be followed exactly. If you understand why each of the ceremonies exists, then you can reflect whether you also need this meeting, and if so, what format it should take.
Ultimately, the benefit of agile ceremonies is that they help you work with an agile mindset. Which is to say, they help you stay flexible and customer focused, with the end result of creating more value for your users faster.
This article will explore the most common agile ceremonies, the purpose for each of them, what they typically look like, and how they combine to allow teams to collaborate, execute and deliver frequent value to customers.
“If everyone is moving forward together, then success takes care of itself.”
– Henry Ford
What is agile?
Agile is an iterative process for building products that helps teams to deliver continuous value to their customers by increasing team velocity. The Agile Manifesto outlines four core principles:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
– The Agile Manifesto
Agile was born out of frustration towards the waterfall model that was often rigid, inflexible and slow. Being agile doesn’t mean that you can’t document or follow processes, it means that it’s more important to see what works for you. It makes sure your way of working maximizes value creation for customers, rather than becoming an end in its own right.
Working in an agile way has five benefits:
- Flexibility – as work is broken down into small chunks of work, you can easily adapt to changing customer needs or unexpected challenges by adjusting your priorities.
- Transparency – having regular catch ups helps build trust among the team members and stakeholders, and allows them to identify and resolve issues early on.
- Collaboration – frequent collaboration between people with cross-functional skill sets results in high quality and productivity, and ultimately better outcomes.
- Continuous improvement – regular reflection on how the team works and adjustments to this means there is continuous improvement of the team’s performance over time.
- Customer focus – putting the customer at the heart of the development process makes sure their needs are prioritized, and the team’s way of working maximizes value created for customers.
What is scrum?
Scrum is a methodology designed to help teams function with agile principles at heart. It is inspired by rugby where the team comes together in a “scrum” to move the ball forward. Unlike waterfall, scrum helps cross-functional teams to plan and ship features in (usually) one or two week sprints. Scrum significantly reduces the risk of building the wrong thing and helps to prioritize pieces of work that will bring the most value to the customers.
Scrum is one of the two most common working patterns for agile teams:
- Scrum – teams work in 1-2 week sprints, allowing prioritization, planning and reflection to be batched into a regular meeting routine. This balances forward planning and flexibility, and is suitable for most teams.
- Kanban – teams work continuously, with prioritization, planning and reflection done on the fly. This allows the team to be incredibly flexible, at the cost of forward planning. It’s best suited to teams where there is high uncertainty, such as 0 -> 1 work, or responding to customer requests.
This article focuses on the ceremonies that are typically found in teams that are practicing scrum, as these are the most typical patterns. Agile teams running kanban or other processes will cover many of the same needs these ceremonies address, whether in the same format or not.
Making agile ceremonies work for you
Agile ceremonies are extremely powerful when run effectively, but can be counter-productive if they are not tailored to your team’s needs. In particular, blindly following a given format can have several negative consequences:
- Inefficient – you can end up wasting time on unnecessary and time-consuming meetings.
- Confusing – if ceremonies don’t align with your goals and wider company processes such as OKRs, then people can get confused on what they are meant to be doing, and why.
- Low engagement – you can face resistance from the team and stakeholders to participate in agile ceremonies if they don’t feel they are creating value.
Agile is a mindset, not a process, so there’s no “right” way to do it. If the ceremonies are accelerating your team then great! Carry on. If they are slowing you down, then change things up or abandon them.
Whatever your approach, here’s some general thoughts to bear in mind:
- These are patterns, not a script – don’t think of agile ceremonies as a strict script that you need to stick to. Think of them as patterns of behavior that other teams have found helpful and you can learn from. We’ve outlined a fairly standard set of meetings here for you to use as a starting point, but the better you understand the purpose behind each meeting the better you’ll be able to adapt your own team’s rituals to drive performance.
- Keep the number of participants low, and meetings tight – meetings are expensive! Your default course of action should be to keep them as short as possible, and involve as few people as possible. It’s much easier to make decisions in a small group. Of course people want to have input and visibility into what is going on, but rarely is a meeting the best way to do this.
- Meetings shouldn’t be boring – it’s a red flag if any meeting is boring. If people aren’t actively engaged in what’s going on, then there’s probably a better way of working. Go back to first principles, figure out what your objective is for the meeting, then whether you need a meeting at all. If you do then work out the participants, timing and agenda to deliver that objective.
- Learn from others – Agile ceremonies are such operational meetings that it’s difficult to understand what good looks like if you haven’t seen it first hand. Visit other team’s ceremonies from time to time to get a fresh perspective and inspiration on how to run your own meetings.
Typical agile ceremonies
Teams running scrum often have five regular agile ceremonies:
- Backlog grooming – breaking down features into tickets engineers can work on, and estimate those tickets.
- Sprint planning – deciding what will be delivered during the upcoming sprint.
- Stand-up – keeping everyone focused on sprint goals, and resolving blockers fast.
- Sprint review – demoing what has been built during the sprint, and agreeing upcoming priorities with stakeholders.
- Retro – reflecting on team performance over the past sprint and identifying improvements for the next sprint.
How the agile ceremonies fit together to create the scrum rhythm Each ceremony happens once per sprint, with the exception of the daily stand-ups (which are daily – obviously!). Together they create a regular rhythm that drives the pace and activity of the sprint.
An example sprint schedule Let’s run through each of the agile ceremonies in more detail.
Backlog Grooming
A meeting to break down features into tickets engineers can work on, and estimate those tickets in advance of the sprint starting.
Purpose:
Backlog grooming ensures the product backlog is up-to-date and work is ready to be taken into an upcoming sprint during sprint planning:
- Ensures the backlog is up-to-date and prioritized, and everyone is clear about the strategy, scope and requirements for upcoming work.
- Creates time for the team to break down epics (shippable features) into tasks that make sense for engineers, and they can easily pick up and work on.
- Provides time for the team to estimate the size of tasks, and further break them down if they are too large.
Participants:
The tech lead and the engineers who have the experience and knowledge to break down the feature into tasks. You might call in other team members if you need their input – e.g. the PM / designer to clarify a user flow, or a data engineer to discuss a database schema.
Frequency:
Usually once a sprint, but this could be more if you’re just kicking off a big project, or less if you’re in the middle of one.
Duration:
Perhaps an hour each sprint, but this will vary a lot and depend on the size of the feature, the complexity of platform requirements (e.g.scalability, security), and whether the team is familiar with the code base.
Agenda:
- Select the next epic – pick the highest priority piece of work from the backlog to groom.
- Clarify the requirements – review the functional requirements along with user flows, designs and any other useful context. Everyone should be clear on why you’re building this feature. You should also discuss and prioritize unhappy paths, corner and edge cases to ensure high quality and reduce the likelihood of bugs.
- Break work into tickets – agree on the implementation approach and discuss the impact of any trade-offs that have to be made. Chunk up the work into pieces that can be completed by someone in a day or two.
- Estimate the ticket size – estimate the size of the tickets that you’ve created. This allows you to plan at an appropriate level of granularity each task, and estimate how much you can get done in a sprint.
- Identify dependencies – identify whether you need any other team’s help (e.g. devops, infrastructure, other product teams) so you let them know exactly what you need and check they have capacity to support you.
- Repeat – pick another epic, until you have enough work groomed for the next 1-2 sprints.
Tips for backlog grooming:
- Set a frequency that works for the team – whether it’s weekly or ad hoc, feel free to adjust the schedule to fit your team’s needs.
- Have a clear definition of ‘’ready’’ – create explicit criteria which means a ticket is ready to be worked on, so that you know what should be included in the ticket. This will help prevent you trying to groom work where the requirements aren’t clear.
- Have a clear definition of ‘’done’’ – you should agree on this with your team, so that you’re on the same page about when a ticket is complete and there are no nasty surprises at the end of the sprint. This will affect how you estimate the size of each piece of work.
- Tease out the unknowns – it’s really difficult to groom work where there are unknowns at play – whether these are in scope and requirements or of a technical nature. If it’s not clear what you need to build then run a spike or take the time to clarify the requirements and then come back later to finish grooming the ticket.
Sprint planning
Sprint planning is where you decide what will be delivered during the upcoming sprint.
Purpose:
Set goals for the sprint, and create a clear plan by deciding which tickets can be delivered:
- Make sure work is aligned with the longer term strategy.
- Work out what can be done in the next sprint.
Participants:
The product manager and the tech lead definitely need to be there, and you might include other members of the team if their input is required.
Frequency:
Once a sprint, either before or as it starts.
Duration:
Typically 20 – 40 minutes for a 2 week sprint, but as with other meetings this will depend on the work you’re doing, size of the team, and so on.
Agenda:
- Set a goal – setting a sprint goal helps you keep focused on your big strategic priorities, rather than getting distracted by lots of fragmented pieces of work. Bear in mind that a goal will likely be delivery focused, as it covers what the team can build in a sprint, and you are unlikely to have time to build, release and see impact from a feature all in a single sprint. It should follow naturally from what you have agreed as your OKRs and is on your roadmap.
- Calculate your team’s capacity – see how much work you’ve completed (story points / t-shirt sizes / number of tickets) in previous weeks, and then adjust this based on the team’s availability in the upcoming sprint, taking into account holidays, sickness and any other one off events (e.g. company offsite).
- Select tickets for the sprint – pick the tickets from the backlog that will help you meet your sprint goal. In general, add slightly more work than you expect to get done, so if the team works faster than expected, it’s clear what they should tackle next.
Tips for sprint planning:
- Make sure that your backlog is well groomed – tickets that are candidates for the sprint should have clear requirements and be estimated, otherwise you will end up spending the bulk of time in sprint planning scoping tasks out.
- Keep the team updated on priorities – the next sprint’s goals should be no surprise to anyone on the team. Motivation in teams is strongly correlated to how well you can connect the company mission and creating value for users to the work you are doing. Well run teams typically have good visibility for the next 2-3 sprints and understand how this will help achieve larger team and company goals.
- Prioritize your backlog – your backlog should reflect the current priorities and have ‘’ready’’ items for multiple sprints’ worth of work, so that you always have next-in-line options in case of unexpected curveballs.
Stand-up
A short, daily catch-up with your team.
Purpose:
‘’Daily stand-up meetings are for bonding, blockers and the future.’’
– Gitlab Remote Manifesto
Identify any blockers and make sure you’re still on track to meet your sprint goals:
- Unblock any team member who’s stuck.
- Foster accountability by getting each team member to publicly commit to work they’ll do, and then report back on whether it has been done.
- Foster collaboration, and develop a close-knit culture in the team.
Participants:
The whole team should attend the stand-up. You might also want to invite guests from other teams who are critical to your sprint’s success.
Frequency:
Every day.
Duration:
~15 minutes. Keep it snappy!
Agenda
Each member of the team answers three questions in turn:
- What did you accomplish yesterday? This keeps the team accountable to the commitments they made the day before. Over time this will help you to spot people who don’t deliver on time and need support.
- What are you working on today? This makes people reflect on the most important work they need to get done, and forces them to commit to delivering something specific. Doing this allows their teammates to spot any misalignment in priorities, and highlights dependencies.
- Is anything blocking you? This means everyone can get help in a maximum of 24 hours. This keeps momentum and morale high across the team.
Tips for daily stand-up:
- It’s a discussion, not a report – stand ups should be an active discussion amongst the team, where people can challenge each other, ask questions and offer help. Having one team member after another drone on without anyone interjecting is usually not a good use of everyone’s time.
- Hold each other to high standards – actively think about what you need to move faster, and how you can help others in the team go faster. There should be enough psychological safety in the team for people to positively challenge each other to maintain a high level of performance, e.g. ‘’This seems to be taking longer than you expected, do you need any help?’’
- Don’t neglect the personal side of things – spend a few minutes to check-in on everyone, especially after weekends and holidays. When stand-ups are all business and too serious they become very dry. Creating personal connections between teammates will help people collaborate and improve overall team performance.
- Invite others to join – if you’re collaborating with another team on a feature, run combined stand ups or invite their PM / tech lead to join yours. You’ll catch any issues early on and address them with the least effort.
- Keep it brief – uncovering areas that need deeper discussion is one of the most valuable things about stand-ups, but you probably don’t want to have a detailed conversation with everyone. If something comes up that is going to take more time to discuss then break out into a separate meeting with just the relevant people, so you’re not wasting everyone’s time.
Sprint review
Sprint reviews allow teams to show off what they’ve built over the course of a sprint, and get recognition and feedback from stakeholders and peers. Depending on how the product organization gets more formal input from stakeholders, these can vary significantly in format and tone from company to company.
Purpose:
There are two main reasons to run sprint reviews:
- Demo your work – show what you’ve built, get recognition for the team, and get people excited about what you are shipping. This is usually informal, light and celebratory, involving the whole team.
- Align with stakeholders – discuss your strategy, progress and plans with stakeholders to ensure everyone is aligned and quality is kept high. This is usually a formal, serious discussion run by the PM.
As the purpose, tone and participants for these two purposes are very different, it’s just as common to see these split out into separate meetings as joined together. For example:
- Team demo – perhaps a monthly session where every team in a tribe or the product org as a whole demos it’s work
- Product review – perhaps a weekly session where senior stakeholders review the most important topics across multiple teams.
Participants:
Demo: the whole team, and as many stakeholders as possible
Alignment: product leadership, stakeholders. PM and any product teams needed to support
Frequency:
Demo: teams should have an opportunity to showcase their work somewhere between once a week and once a quarter
Alignment: it can be helpful to align with stakeholders every 2-6 weeks.
Duration:
Demo: ~10-15 mins per sprint for each team.
Alignment: ~30-60 mins per sprint for each team.
Agenda:
This example agenda assumes that the demo and alignment topics are both being addressed in the same sprint review meeting:
- Review the team progress – kick off by reviewing how you’re doing against your mid term objectives (i.e. target outcomes) and progress against your roadmap (i.e. target output / initiatives). You should also review whether you’ve met your sprint goal. This should include some reflection of whether you are on track to hit longer term goals, and whether there are blockers for the team as a whole that you need stakeholder support to address.
- Show what has been built – demo what has been completed in the sprint, being clear the level of feedback that is useful for the team (e.g. is critiquing copy helpful at this point, or is this all placeholder text?). Get feedback from stakeholders, answer their questions and address any concerns.
- Review the backlog – review the backlog, with particular attention on initiatives that are transitioning between different development phases, e.g.:
- Kick off / problem definition
- Solution definition / design
- Development
- Release and roll out
Here the goal is to get stakeholder input appropriate to the stage that you are in, and take people on the journey with you. You don’t want to start working on designs before you’ve agreed on the problem you’re trying to solve, or start engineering work when you haven’t completed design work.
- Agree next steps – wrap up the meeting by running through the actions that have been agreed, and making sure it’s clear who is accountable for each action, as well as when it will be done by. If you’ve made significant decisions about what you’re working on, you might also want to record these in a decision log on the relevant PRD.
Tips for sprint reviews:
- Be clear on the purpose – are you showcasing work, aligning with stakeholders or both? When you’re clear on the purpose of the meeting, then the participants, timing and format of the meeting will follow
- Make demos fun – everyone likes to be recognised for their work and feel appreciated. Demos should be fun and make people feel good. If you’ve got someone on the team that is a natural showman then let them work their magic.
- Clarify the feedback you’re after – make it clear what stage of development you are in for different features, and the feedback that is appropriate for that stage. It’s hugely frustrating for everyone when people are giving you feedback on the details when you’re still working on the big picture or vice versa.
- Look for enthusiastic agreement – if stakeholders are voicing concerns, or even a little less engaged than usual, then dig in to find out more. You’ll often need their support to make a release a success, so check they are bought into your plans. Tempting as it is to take silence as agreement, this will often come back to bite you later on.
Retro
A sprint retro is a forum where the product team comes together to reflect on their performance over the past sprint, and identify concrete actions to go faster going forwards.
Common retro format Purpose:
See how you did against your team goals, and Increase velocity in the next sprint.
Participants:
The whole product team.
Frequency:
Once a sprint, at the end.
Duration:
Typically 30-45 minutes per sprint.
Agenda:
There are lots of different ways of running retros, but we’ll just cover one common format here:
- Review actions from last sprint – check in on the actions you agreed from the last sprint, and whether they have been completed or need rolling over.
- Individual reflection – everyone gets 2-3 mins to reflect on how the past sprint went. It can be helpful to divide this into:
- Stuff that went well
- Stuff that didn’t go well
- Shout-outs and thank yous to other team mates
- Suggestions
- Group discussion to identify themes – the team talks through the points raised to identify the themes that most people see, and prioritize which ones will have the biggest impact.
- Set actions – the team agrees to specific actions to increase their performance next sprint. This should include assigning owners and deadlines to the actions to make sure they actually happen.
Tips for sprint retros
- Create a psychologically safe environment – you should encourage objective, honest and respectful communication. You can’t have a productive conversation if people won’t tackle the real issues, or if everyone hates each other.
- Review actions from the previous sprint – make sure you include following up on previous actions as part of your agenda. This is key to developing a sense of accountability and making sure that agreed actions actually happen.
- Give shoutouts – retros are a great chance to celebrate the small wins and praise team members who have been very helpful or gone the extra mile. If the whole team has been working hard then you might even invite someone from leadership along to give the team some love. A little appreciation goes a long way.
- Dig below the surface – retros need to stay focused on performance, and shouldn’t be a chit chat at the end of a sprint. Whilst you can skip over minor gripes, you want to really dig into the meaty topics that are slowing you down to identify the root causes and solve them for good.
Summary
Agile is an attitude, not a technique with boundaries. An attitude has no boundaries, so we wouldn’t ask ‘can I use agile here’, but rather ‘how would I act in the agile way here?’ or ‘how agile can we be, here?’
– Alistair Cockburn, Agile Manifesto signatory
Agile ceremonies are common patterns that help teams plan, track and review product development in an agile way. Used effectively they can be incredibly powerful in driving team effectiveness, allowing you to be flexible, productive and maximize the value created for your users and the company. But “used effectively” almost certainly means “run adapted to your unique circumstances”, and not according to someone else’s script (even ours!). Only by understanding the principles behind agile ceremonies can you tailor them to your needs and really get the most out of them.
Resources
Hustle Badger articles
Further Reading
FAQs
What are agile ceremonies?
Agile ceremonies are meetings commonly run by product teams to plan, track and review their work. Whilst the agile manifesto explicitly warns against rigid process, teams often adopt similar rituals to help them work more efficiently. In this light, you can think of agile ceremonies as patterns that other teams frequently use, and you may well find helpful when thinking about how to run your own team.
What are the agile ceremonies?
Agile ceremonies will vary from team to team, and company to company, but there are five meetings that are commonly found in teams running agile scrum. These are:
* Backlog grooming
* Spring planning
* Daily stand-ups
* Sprint reviews
* Sprint retros
