Cross-functional teams
Rituals: planning/grooming/retro/demo
Planning, refinement, retro and demo: the purpose of team rituals, participants, entrances, exits, and signs of a useless encounter.
A ritual is justified if it regularly produces the right decision or general context. For planning, refinement, retro and demo, pre-determine the input, expected output and owner of the subsequent actions; a meeting without decisions, preparation or changes to the process should be shortened, combined or canceled.
Why Rituals Are Important in Cross-Functional Teams
Synchronization and responsibility
Rituals are regular meetings that allow the team to negotiate, keep focus and solve problems quickly, especially when the team is composed of specialists from different roles (product, development, testing, analytics, design, etc.).
Example
Planning brought together a product manager, a backend developer, a frontend, a tester and a designer, each identifying their own risks and challenges, and the result is that the team is united in their understanding of what to do and why.
We disassemble rituals in parts
Planning (planning)
Essence
The team chooses which tasks to take on the sprint (or week/year), usually the product owner and team agree on the objectives, priorities and scope of work.
Key responsibility
Product owner sets goals and priorities. Teams give you a scoring of the tasks and confirm what the tasks are actually done.
Mistakes and anti-patterns
- Raw backlog brought, tasks are not ready for evaluation There is no open dialogue about the risks. The meeting becomes a long monologue product owner.
Example
The planning team rejected the task because the backend lacks API data, and the manager takes it to grooming for revision.
Grooming (or backlog refinement)
Essence
This is a meeting where the team discusses, refines and breaks down tasks from the backlog so they are clear, small and ready to be assessed.
Key responsibility
The team asks clarifying questions, offers breakups and formats, and the owner of the product explains the business context.
Mistakes and anti-patterns
Only 1-2 people are actively involved, the rest are silent. Tasks are not broken down into small, testable pieces. There is no general picture of priorities
Example
The grooming task seemed simple, but the discussion revealed a dependent service, so we decided to split it into two tickets and put blockers.
Retro (retrospective)
Essence
The team discusses what worked well and what can be improved after the work cycle is completed.
Key responsibility
Scrum master/facilitator creates a safe environment, and each team member offers ideas for change.
Mistakes and anti-patterns
Retro is reduced to complaints or silence. No follow-up (action items) The results were excellent (“Well done, thank you all”)
Example
In retro, the team realized that there was a lack of communication with the designers, and the solution is to do syncs twice a week in the next sprint.
Demo (demonstration)
Essence
Showing the results of the sprint to stakeholders, it is important to focus on the value to the user.
Key responsibility
The team shows the actual functionality. The product owner links the result to business goals.
Mistakes and anti-patterns
- Showing “semi-working” things There is no connection between the demo and the sprint goals.
- No interested parties (or are formally listened to)
Example
In the demo, the team showed a new filter in search, and the managers realized that they needed to change the order of the options, which was important for sales users.
How to combine rituals for good, not for a tick
Regularity and transparency
The meeting calendar is fixed in advance and not canceled without good reason, otherwise the rituals quickly devalue, it is important that everyone knows why they came and what benefits to endure.
Responsibility is not just for the manager
Effective rituals work when all roles are active, so don’t delegate the responsibility for questions and suggestions to one person.
Example
If the team is often not satisfied with the results of retro or planning, try to hold a meeting in a different format or switch the facilitator.
Metrics and how to know if rituals work
How to measure benefits
The results are visible when:
- The tasks (user stories) are reachable, there are no systematic kickbacks.
- After grooming, tasks become a size that is convenient for sprinting.
- The results of retro are implemented, problems from retro do not repeat for months.
- On demo there is feedback from stakeholders, you can see the benefits of the release.
If this is not the case, rituals are formal, try to change the approach: format, schedule, facilitator, depth of preparation.
Where to look for benchmarks by metrics
The exact numbers depend on the market and the specifics of the team.
There you will find templates, checklists and examples of ritual expectations.
FAQ
How do you know if rituals are meaningless?
If meetings are formal, the tasks do not become clearer, the discussions are boring and there is no obvious improvement – it is time to change the approach.
Do you need to do grooming and planning separately?
It’s preferable to time-separate: grooming is where you prepare tasks, planning is where you choose volume and you form goals, and in emergencies you can combine, but quality often suffers.
Who’s supposed to be doing retro?
It’s not necessarily Scrum wizard. Any team member can facilitate it, it’s important to be neutral and involve everyone.
How to do demo if the feature did not have time to finish?
Better to be honest about the progress and comment on the reasons. Don’t pretend the feature is ready - it’s worse for trust.
If only a part of the team can come, should the ritual be cancelled?
Depending on the composition: if there are no key roles (for example, without the owner of the product, planning loses its meaning).
How long should these meetings last?
For a team of up to 8 people: planning 60-120 minutes grooming 60 minutes retro 45-60 minutes demo 30-45 minutes Accurate numbers – in practice, teams adjust to their needs.