task-ops
Four meetings sit on the calendar every sprint. Attendance is good, the board gets updated, and the same blocker still shows up in the next retrospective. That is usually why someone looks up agile ceremonies after running them for a year. Not to learn the names, but to work out which of the four is doing real work and which one has become a standing appointment nobody feels able to cancel.
The names are not the problem. The problem is that most descriptions of these meetings explain the agenda and skip the output. A meeting with an agenda and no output is a ritual. A meeting that ends with a decision somebody is accountable for is a working session. Every one of these events was designed as the second kind, and each one goes wrong in its own specific way.
Scrum defines five events, and the Sprint itself is one of them: a fixed length container of one month or less inside which everything else happens. The other four are what people mean by ceremonies. The useful way to tell them apart is not by length or by who facilitates, but by the single question each answers and who is allowed to answer it.
| Ceremony | The question it answers | Who decides | What leaves the room |
|---|---|---|---|
| Sprint Planning | What is worth committing to, and how it gets done | Developers select the items, Product Owner frames the value | A Sprint Goal and a Sprint Backlog |
| Daily Scrum | What changes in the plan for the next day | The Developers | An actionable plan for tomorrow |
| Sprint Review | What to do next with the product | Product Owner, informed by stakeholders | An adjusted Product Backlog |
| Sprint Retrospective | What to change in how the team works | The whole Scrum Team | One or two improvements with an owner |
Read the last column back against last sprint. If nothing in that column changed, the meeting did not happen. A conversation happened. The test is blunt and it catches most of the trouble. A standup that produced no change to the plan was a status report. A review that produced no change to the backlog was a demo. A retrospective that produced a list nobody owns was a vent.
The 2020 Scrum Guide states maximums for a one-month Sprint: eight hours for Sprint Planning, four hours for the Sprint Review, three hours for the Sprint Retrospective, and 15 minutes for the Daily Scrum. For shorter Sprints it says only that the events are usually shorter. No formula is given.
Most teams halve the numbers for a two-week Sprint, which lands on four hours of planning, two hours of review, ninety minutes of retrospective, and a quarter of an hour each working day. Add that up and the ceremonies cost roughly ten hours per person per two-week sprint, or about twelve percent of a standard working fortnight. For a team of six that is sixty person-hours a sprint.
Two things follow from seeing the figure written down. The first is that a maximum is not a slot to fill. A planning session that finishes in ninety minutes with a clear Sprint Goal has not been done badly. The second is that when a ceremony reliably runs to its maximum, the cause is almost always upstream of the meeting. Planning overruns because items arrived unread. Retrospectives overrun because the previous three produced nothing, so the backlog of grievances is three sprints deep.
A ninety-minute meeting with six people in it also costs the two fragmented half-days around it. That is the real argument for holding events at the same time and place: not tidiness, but protecting the hours that are not in the meeting. The Scrum Guide makes the same point in plainer terms, noting that a consistent time and place reduces complexity.
Planning covers three topics in order. Why is this Sprint valuable, which produces the Sprint Goal. What can be done this Sprint, where the Developers select items from the Product Backlog in discussion with the Product Owner. How the chosen work gets done, which is decomposition into work items of a day or less, and which the guide places at the sole discretion of the Developers.
The ordering matters more than it looks. The Sprint Goal has to be finalized before planning ends, and it is meant to be set before the item selection hardens. Teams that run the topics backwards, filling capacity first and then writing a goal that describes the items they picked, end up with a sprint that is a list. A list cannot be used to make a trade-off mid-sprint, because there is no statement of what the sprint was for.
Two failure modes account for most bad planning sessions. The first is items being read for the first time in the room, which turns planning into refinement and blows the timebox. The second is estimation treated as the point of the meeting, with an hour spent arguing a five against an eight on work that will be re-planned in three days anyway.
A quick diagnostic: ask someone on the team, a week into the sprint, what the Sprint Goal is. If nobody can say it in one sentence without opening the tool, planning produced a backlog and not a goal.
The guide is specific here. The Daily Scrum is a 15-minute event for the Developers, held at the same time and place every working day. If the Product Owner or Scrum Master are actively working on Sprint Backlog items, they attend as Developers. The structure is the team's to choose, provided it focuses on progress toward the Sprint Goal and produces an actionable plan for the next day.
The three familiar questions about yesterday, today and blockers are not in the current guide. They survive because they are easy to facilitate, and they cause the most common failure in the whole set: the meeting turns into six people reporting to whoever seems most senior. Once that happens the content shifts from the work to the person, and the output quietly disappears.
The practical change is to walk the board instead of the people. Start at the column nearest done and move left, oldest card first, and talk about cards rather than individuals. Two things fall out of this immediately. Work that has sat still for four days becomes visible, and people with nothing to report stop inventing something to say. Anything that needs more than a sentence gets a named follow-up straight after, with the two or three people it concerns.
A distributed team can run this in writing, and the 15 minutes becomes a thread. The output still has to exist: what changed, what is blocked, what the plan for the next day is. The risk is that the written version becomes a log nobody reads. Keep the replan on the board rather than in the thread, so the current state of work has one home. A board that already shows owners, dates and blockers removes most of what the meeting used to read aloud, which is a large part of what a board with several view types is for.
This is where the counting arguments come from. Some sources list four ceremonies, some list five, and the disagreement is about refinement. The guide treats it as an ongoing activity rather than an event: refinement is the act of breaking down and further defining Product Backlog items into smaller, more precise items, adding detail such as description, order and size. Items that can be finished within one Sprint are deemed ready for selection at Sprint Planning, and they usually reach that state through refining activities.
So refinement has no timebox, no required attendees and no fixed cadence, and nothing stops a team from scheduling a session for it anyway. Most teams that plan well have one, precisely because it is what keeps items from being read for the first time during planning. Keep it small. The Developers who will do the work are the ones who need to size it, and an audience does not help.
One rule of thumb travels well: the top of the backlog should hold about two sprints of ready work. Less than that and planning becomes refinement. Much more and time gets spent detailing items that will be reordered before anyone starts them.
The Sprint Review looks outward. The team inspects the outcome of the sprint with stakeholders, discusses what has changed in the environment, and the Product Backlog is adjusted based on what the conversation surfaces. The guide is explicit that this is a working session and should not be reduced to a presentation.
The Sprint Retrospective looks inward, at individuals, interactions, processes, tools and the Definition of Done. It closes the sprint, and the improvements it identifies are meant to be acted on as soon as possible. The guide suggests they may even be added to the next Sprint Backlog, which is the most useful sentence in that section: an improvement with a place in the sprint plan gets done, and an improvement in a document does not.
Small teams often merge the two to save an hour, and the merge reliably costs the retrospective. With stakeholders in the room, the product conversation expands and nobody wants to raise a process problem in front of a client. If the calendar really cannot hold both, keep them on the same day but separate, with the stakeholders leaving between the two.
Ceremonies designed for a ten-person team with a dedicated Scrum Master do not scale down cleanly, and pretending otherwise is how they become theatre. The trade-offs are not symmetrical.
Cutting the retrospective is the cheapest choice this week and the most expensive over a quarter, because it is the only event whose output is a change to the way the team works. Cutting the standup is defensible when the board is genuinely current and people talk during the day, and indefensible when the board is stale, because then the meeting is the only place the truth gets said. Cutting the review is workable when stakeholders see the increment some other way, and dangerous when it was the only regular contact with the person who decides what matters. Cutting planning is not workable at all.
Shortening is not cutting, and it is usually the better move. A thirty-minute retrospective with one improvement that gets an owner beats a ninety-minute one that produces a list. The other lever is to move information out of the meetings and into the artifacts. When the board carries dates, dependencies and blockers where everyone can see them, the events stop being about finding out what is happening and go back to being about deciding what to do, which is the difference between the tooling questions covered in the tool comparisons and the process questions covered here.
Pick the one ceremony whose output from last sprint cannot be named, and fix its output before touching its agenda or its length. Give the retrospective a single owned improvement, give planning a Sprint Goal stated in a sentence, and put both somewhere the team already looks, which means on the board rather than in a document. A single place where the plan, the dates and the conversation all live makes the meetings shorter on their own, and Pinateca is free for up to five people and ten boards if the current setup is spread across three tools.
Both counts are defensible. Scrum defines five events, but one of them is the Sprint itself, which is the container rather than a meeting. That leaves four meetings. Sources that say five are usually counting backlog refinement, which the Scrum Guide describes as an ongoing activity rather than a formal event.
The published maximums apply to a one-month sprint: eight hours for planning, four for the review, three for the retrospective, and 15 minutes for the daily. For shorter sprints the guide says only that events are usually shorter, so most teams halve them and land near four hours, two hours, ninety minutes and 15 minutes. These are ceilings, not durations to fill.
The Scrum Master is accountable for the events taking place and staying inside their timebox, but not for chairing them. Sprint Planning belongs to the whole team, the Daily Scrum belongs to the Developers, and the Sprint Review is a joint working session with stakeholders. On a small team without a dedicated Scrum Master, rotating the facilitation usually works better than assigning it permanently to the most senior person.
Yes, if the output survives the format change. The daily replan can become a written thread and the retrospective can collect input in a document before a shorter live session. What cannot move to writing is the part of planning where trade-offs get negotiated, so most distributed teams keep one scheduled overlap a sprint for that and run the rest asynchronously.
Almost always the retrospective produces items with no owner and no place in the next sprint. An improvement written in meeting notes competes with committed work and loses every time. Putting one improvement on the board as a card, with a person's name on it, changes more than any adjustment to the meeting format.