Agile ceremonies: What I’d keep, change, or drop
Our reviewers evaluate writing services independently. Learn how we stay transparent, our methodology, and tell us about anything we missed.
A ceremony needs a job
I use “agile ceremonies” as shorthand for recurring conversations that help a team plan, coordinate, inspect results, and improve. The meeting is not the outcome. If a ceremony cannot say what decision or learning it produces, I question the format.
The conversations I would keep useful
Planning should create a shared goal, realistic work view, and clarity about risks. A daily conversation should focus on the goal and help needed; status can be asynchronous when a meeting adds no value. A review should inspect a usable increment with people who can provide feedback, not merely present polished slides.
A retrospective should examine how the team worked and choose a small improvement experiment. I create enough safety to discuss system conditions rather than personal blame, then revisit whether the experiment helped.
I give each meeting a clear purpose and decision owner, invite people who add context, use pre-reads when useful, and change cadence as needs change. Ceremonies are scaffolding: I keep the conversations that improve product decisions and team flow, adapt heavy ones, and drop theater.
A practical check
I periodically ask attendees what they got from each recurring meeting. If the answer is only “we have always done it,” I run a small experiment: shorten it, change the input, move it async, or cancel it. A ceremony earns its place through usefulness.
My bottom line
I use this framework to make the work explicit, not to create ceremony for its own sake. Start with the decision, show the evidence, make ownership visible, and revisit the approach when the product or context changes.
If you are building the fundamentals behind this kind of work, the Product HQ product management certification is a useful next step. I also share practical lessons in the Product HQ newsletter.
