Skip to content

Team Ceremonies

Ceremonies exist to keep a team in sync — to make sure everyone shares the same picture of what we’re building, how we work, and how it’s going. Run well, they’re the cheapest coordination you’ll ever buy. Run badly, they’re the thing your best engineers quietly resent. The job is to keep enough structure to get the value and cut everything else.

A rule I hold every recurring meeting to: it needs a clear purpose and an owner, and if it stops earning its slot on the calendar, it gets changed or killed. Ceremonies are tools, not traditions.

Team norms (ways of working)

Before you optimize any individual meeting, agree on how the team works together. A team’s ways of working are the explicit answers to the questions every team answers implicitly anyway: What are our core collaboration hours? What’s our definition of ready and definition of done? How do we handle code review turnaround? When is it a Slack message versus a meeting? What does “done” actually mean?

Write these down with the team, not for them — norms only stick when the people held to them helped set them. Then treat the document as living. Revisit it when something feels off, when the team grows, or in a retro when the same friction keeps coming up.

Sprint planning and kickoff

Planning is where the team turns a prioritized backlog into a shared commitment for the next stretch of work. The outcome you want isn’t a perfectly packed sprint — it’s a team that walks out understanding why this work, what done looks like, and who’s picking up what.

A few things that make planning work:

  • Come in with a groomed, prioritized backlog. Planning is for committing, not for discovering scope for the first time.
  • Talk through acceptance criteria and unknowns out loud — the conversation is half the value.
  • Plan to a sustainable capacity, not a heroic one. A sprint that’s full to the brim has no room for the inevitable surprise.
  • Leave with the top of the sprint clear enough that people can start Monday without waiting on you.

Sprint retro

The retro is the team’s standing invitation to improve how it works, and it’s the ceremony I’d protect first. The goal is a small number of concrete changes the team actually commits to — not a venting session, and not a list of complaints with no owner.

A couple of things keep retros healthy:

  • Rotate the format. The same three columns every two weeks goes stale fast. Pull from a catalog like FunRetrospectives to keep people engaged.
  • Make it safe. Retro only works if people will say the real thing. If it’s gone quiet, that’s a team-health signal, not a sign everything’s fine.
  • Close the loop. Pick one or two actions, assign owners, and revisit them next time. A retro whose actions never happen teaches the team that the retro is theater.
💡
End every retro by reviewing last retro’s action items before generating new ones. It takes two minutes and it’s the single highest-leverage thing you can do — it turns retro from a recurring complaint box into a system that visibly makes the team better over time.

Team building

Coordination ceremonies keep the work in sync; team building keeps the people in sync. Trust isn’t built in standup — it’s built in the lower-stakes moments where people get to be humans to each other. That doesn’t mean forced fun. The best team building is often just protected, unstructured time together: a shared lunch, a retro that opens with a real check-in, an occasional session that exists only to connect.

Whatever form it takes, be intentional about it. Trust is what makes every other ceremony cheaper — a team that trusts each other can have the hard planning conversation and the honest retro without it turning into a fight.

📚 Go Deeper

Books

Tools

  • RetrotoolA clean, free online retro board — what I reach for when the team is remote and I want low-friction setup.
  • FunRetrospectivesA catalog of retro and team-building activities so your retros don't calcify into the same three columns forever.
Last updated on