Agile ceremony agenda and notes templates
Last updated: · Reviewed quarterly
Five ceremonies, one page. A team running two-week sprints holds around fifteen of these a quarter, and the notes for all of them are usually a Jira board that records outcomes without any of the reasoning. The templates are below, free and complete, one per ceremony. After them, how to stop typing them out: the meeting is already recorded on your device, and an agent writes the right template from the transcript into a file you keep.
The agile ceremony templates
Five ceremonies, five templates, and they are deliberately short. A ceremony record that takes longer to write than the ceremony took to run does not get written twice.
Daily scrum
The one where a record is least obviously worth keeping, and the two things worth keeping are the blocker with an owner and the decision somebody made standing up.
# Standup, <date>, sprint <n>
**Present:**
## Blockers
| Blocker | Whose | Owner of the fix | Needed by |
| --- | --- | --- | --- |
## Moved since yesterday
<only what changed. Not a status report from each person in turn.>
## Decisions
<the small ones that got made standing up and would otherwise vanish>
## Taken offline
| Topic | Who | When |
| --- | --- | --- |
Sprint planning
The sprint goal is the payload. Everything else in this template exists to make it possible to tell, at the review, whether the goal was met or merely approached.
# Sprint planning, sprint <n>, <date>
**Present:**
**Sprint dates:**
## Sprint goal
<one sentence, verbatim, agreed by the room. If there are two, there is no sprint goal.>
## Forecast
| Item | Estimate | Owner | Acceptance |
| --- | --- | --- | --- |
## Capacity and known absences
<holiday, on-call, anything already committed elsewhere>
## Deferred
| Item | Why not this sprint |
| --- | --- |
## Dependencies on other teams
| What | Who | Confirmed? |
| --- | --- | --- |
## Open questions
<raised in planning, not resolved, each with a name>
Sprint review
The feedback block is the reason this meeting is not a demo. Record what stakeholders said rather than whether they seemed pleased.
# Sprint review, sprint <n>, <date>
**Present:**
**Stakeholders:**
## Sprint goal, and whether we met it
<the goal as written in planning, then a plain yes, no, or partly>
## Demonstrated
| Item | Shown by | Accepted? |
| --- | --- | --- |
## Feedback
<what stakeholders actually said, in their words. This is the reason the meeting exists.>
## Backlog changes agreed
| Change | Because | Who agreed |
| --- | --- | --- |
## Not accepted, and what happens to it
<item, the gap, and where it goes next>
Sprint retrospective
Two blocks that most retro templates lack: everything raised, not just what was chosen, and exactly one experiment. A retro that produces five actions has produced none.
# Retrospective, sprint <n>, <date>
**Present:**
**Facilitator:**
## Carried over
- [ ] <last sprint's experiment, and what actually happened to it>
## What we are keeping
<what worked, specifically enough to repeat on purpose>
## What we are changing
<everything raised. All of it, even the items not chosen.>
## The one experiment
<exactly one change, with an owner and the sprint it will be judged in>
## Raised and parked
<real, agreed, and not this sprint. Needs a date to come back.>
Backlog refinement
The not-ready table is what makes refinement worth holding. An item that is not ready needs a named person and a date, or it will be not ready again in a fortnight.
# Backlog refinement, <date>
**Present:**
## Ready
| Item | Estimate | Acceptance criteria agreed |
| --- | --- | --- |
## Not ready, and what is missing
| Item | Missing | Who provides it | By when |
| --- | --- | --- | --- |
## Split
<items broken up, and the reasoning, because the reasoning is what stops it being re-split>
## Decisions
| Decision | Owner | Date |
| --- | --- | --- |
## Questions for the product owner
<raised by the team, needing an answer before this can be forecast>
These are records, not facilitation guides. How to run a standup that stays inside fifteen minutes, and the five retro formats that hold up, are in standup and retrospective formats.
What has to survive an agile ceremony
What they decide. Different things, which is why one page carries five templates rather than one. Planning decides the sprint goal and the forecast. Review decides what stakeholder feedback changes about the backlog. Retro decides one process experiment. Refinement decides readiness. The daily scrum decides almost nothing and exists to surface blockers, which is why its template is five lines long.
Who is in them. The team, plus stakeholders at the review. The record is for the product owner who missed one, and for the retrospective three sprints from now that will otherwise re-raise something already tried. What product owners keep covers the version where the ask arrives in a huddle rather than a ceremony.
What must survive them. The sprint goal in the words the room agreed, because a paraphrased goal cannot be failed. The distinction between what was committed to and what was discussed, which is the single thing a Jira board loses. And the retro item that was raised and not chosen, because the fourth time it is raised is the only evidence that matters and no individual retro contains it.
What these notes need that others do not. A verbatim sprint goal. A one-experiment rule on the retro, enforced in the template rather than hoped for in the room. And refinement decisions attached to item identifiers, so the reasoning is findable from the ticket rather than from a date.
Five of our eight roles run these weekly, which is why this page exists at a search volume that would not otherwise justify it. Nobody looks for a sprint review template; everybody attends one.
What the board does not keep
Agile's answer to this is the board. The ticket is the record, the board is the state, and a ceremony that produced changes to both has recorded itself.
It half works. What the board keeps is the outcome: the item moved, the estimate changed, the story got split. What it loses is every reason. Why the estimate doubled, what the stakeholder actually said at the review, which of the four things raised in the retro the team decided to try and why it picked that one. Six sprints later the same story gets split the same way for the same reason, and the retro raises the deployment complaint for the fifth time, and each of those is a conversation the team has already had and cannot find.
Writing it from the recording
This half is a product feature. Exactly what it does, in four steps:
- The day is already recorded. Earkeep captures your microphone and your system audio continuously and transcribes on your device, and the audio is never written to disk at all. There is no start button and no bot joining the call. Always-on capture covers why, and private by design covers where the audio goes, which is nowhere.
- You mark the meeting once it is over. Select the range on the timeline and save it as a meeting. Sprint ceremonies are recurring calendar events, so a connected calendar names and bounds each one on its own. The unscheduled huddle straight after refinement is the one you mark by hand, and it is often where the actual decision happened. Calendar connection has the detail.
- You pick a saved template in the composer. Settings → Templates holds instruction presets, each with a name, an agent, a working directory and the prompt text. Opening the agent panel on a saved meeting offers them, and the meeting and its transcript are attached to the prompt for you, as resources, so the preset itself is just the instruction.
- The agent writes the file. It runs on your machine, as your own CLI, with your own key, in the directory the preset names. Agents and MCP explains how that works.
The "one click" is picking the preset. Nothing fires a template because a meeting's title matched a pattern; Earkeep has no such matching.
The preset for this page, with ~/notes/sprints as the directory:
Write this ceremony up as a new markdown file in this directory, named
sprint-<number>/<ceremony>-<yyyy-mm-dd>.md, where ceremony is one of standup, planning,
review, retro or refinement.
Work out which ceremony this was from the transcript and use that template's sections:
- standup: Blockers, Moved since yesterday, Decisions, Taken offline
- planning: Sprint goal, Forecast, Capacity and known absences, Deferred, Open questions
- review: Demonstrated, Feedback, Backlog changes agreed, Not accepted
- retro: What we are keeping, What we are changing, The one experiment, Carried over
- refinement: Ready, Not ready and why, Estimates, Split, Decisions
Quote the sprint goal verbatim. It is the one sentence the whole sprint is measured against
and a paraphrase of it is worth nothing.
Record what the team committed to, not what it discussed. If an item was talked about but
not forecast into the sprint, it goes under Deferred.
For a retro, record exactly one experiment. If the room agreed several actions, list them
all under "What we are changing" and mark which single one the team chose to actually try.
If it chose none, say so.
Attribute an item only when someone said out loud who owns it. Otherwise leave the owner
blank rather than guessing.
One preset for five ceremonies rather than five presets, because the alternative is picking the wrong one at four in the afternoon and getting a retro written as a planning session. The agent can tell a standup from a review from the transcript far more reliably than you can remember which preset you named what.
Cross-linking a year of them, on your own schedule
Earkeep has no scheduler. There is no nightly job to switch on, no "run this agent every week" setting, and there is not one hidden in a menu either. What it has instead is a directory of plain markdown files and a read-only MCP server on loopback, which is everything a scheduler you already own needs.
The pattern on top of that is a compiled wiki: raw sources stay immutable, an agent writes one page per concept from them, and a schema file states the rules. The LLM Wiki is the pattern and from what was said to what you know is the pipeline a meeting travels along it. For sprint ceremonies the destination is a page per sprint plus a single retro ledger, and the ledger is the one that matters: the recurring process complaint that has now appeared in six retros is invisible in any one of them and obvious the moment they are on one page.
Keep the ingest instructions in a file so a scheduled run and a manual one read the same one. ~/wiki/INGEST.md:
Sources are the markdown files under ~/notes/sprints. Never edit them.
Maintain one page per sprint in ~/wiki/sprints/. Each page: the sprint goal verbatim, what
was forecast, what was delivered, what was deferred and why, and the retro experiment.
Maintain ~/wiki/retro-ledger.md as one row per thing raised in a retrospective: what was
raised, the sprint, whether it became the experiment, and what happened to it. Append only.
Group rows that are the same complaint in different words, and say how many times it has
now been raised.
Maintain ~/wiki/deferred.md: every item deferred out of a sprint, with the sprint number
and the reason. An item deferred four sprints running is a decision nobody has made.
Every claim carries the date of the write-up it came from and links that file.
Then the schedule, which is yours. On macOS a LaunchAgent is the supported mechanism and it survives the laptop being asleep at the appointed minute, where a cron job simply misses it. Save this as ~/Library/LaunchAgents/com.yourname.wiki-ingest.plist:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.yourname.wiki-ingest</string>
<key>ProgramArguments</key>
<array>
<string>/bin/zsh</string>
<string>-lc</string>
<string>cd ~/wiki && /opt/homebrew/bin/claude -p "$(cat INGEST.md)"</string>
</array>
<key>StartCalendarInterval</key>
<dict>
<key>Hour</key><integer>19</integer>
<key>Minute</key><integer>30</integer>
</dict>
<key>StandardOutPath</key>
<string>/tmp/wiki-ingest.log</string>
<key>StandardErrorPath</key>
<string>/tmp/wiki-ingest.err</string>
</dict>
</plist>
Load it once with launchctl bootstrap gui/$(id -u) and the path to that file. Or, if you already keep a crontab, one line instead:
30 19 * * 1-5 cd $HOME/wiki && /opt/homebrew/bin/claude -p "$(cat INGEST.md)" >> /tmp/wiki-ingest.log 2>&1
Two things bite about that line. Cron runs with a minimal PATH, so the agent binary needs its absolute path or the job fails silently. And on current macOS a cron job that reads directories under ~/Documents or ~/Desktop needs Full Disk Access granted to /usr/sbin/cron in System Settings.
The join between a meeting and its write-up is the filename convention you chose, and nothing else: there is no field on a saved meeting recording where its notes landed. The retro ledger is uncomfortable reading by the fourth sprint, which is the point: a complaint raised six times and never chosen as the experiment is the team telling you something the individual retros could not.
What this does not do
- No speaker labels. There is no diarisation, so nothing in the transcript says who said which sentence, and the minutes cannot attribute a line to a person from the audio. Attribution comes from what was said out loud ("Sam will take the migration"), from a connected calendar's attendee list, or from you typing the names. The
**Present:**line is a line you fill in. - macOS only. macOS 13 or later. The Windows audio path is designed and not released, and the scheduling half of this page is macOS-specific by construction.
- The agent is yours. It runs as your own CLI with your own key. Earkeep does not resell model access and there is no per-meeting AI fee, which is what makes it €39 once. What the agent does with the context after Earkeep hands it over is a property of the agent you chose, not of Earkeep. Setting up Claude Code covers installing and signing in to one of them.
- Nothing writes back. The MCP server is read-only, with exactly two tools, so a scheduled agent can read your meetings and cannot create or edit a meeting, a note or a file through it. The wiki is a one-way derivative of the record.
Related
- Project kickoff meeting agenda template: the meeting before the first sprint, where the scope these ceremonies operate inside was set.
- Team meeting agenda template: for the weekly that is not a ceremony and should not be run like one.
- Standup and retrospective formats: how to facilitate these, which is a different problem from how to record them.
- All meeting minutes templates.
Frequently asked questions
Is there a free daily scrum meeting agenda template?
The standup template above, and it is five lines because a standup does not need more. There is no email gate and nothing to sign up for. If your standup needs a longer template than that, the honest diagnosis is that it has turned into a status meeting, and the team meeting template is the shape it has become.
Do we really need notes for a fifteen-minute standup?
Mostly no, and this page is not going to pretend otherwise. Two things are worth keeping: a blocker with a named owner for the fix, and any decision that got made standing up, because those are the ones that exist nowhere else. Everything else a standup produces is already on the board by lunchtime.
What is the difference between sprint planning and backlog refinement?
Refinement decides whether an item is ready; planning decides whether it is in. Running them together is common and it is why planning sessions overrun, because a room that is still writing acceptance criteria cannot forecast. The templates are separate here for the same reason: the refinement record is about what is missing from an item, and the planning record is about what the team committed to.
Why does the retrospective template only allow one experiment?
Because a retro that produces five actions produces none, and every team learns this the same slow way. The template records everything that was raised, so nothing is lost, and then asks the team to pick exactly one thing to actually change and name the sprint it will be judged in. The carried-over block at the top is what makes that stick, since the next retro opens by asking what happened to it.
Does this record the meeting without telling anyone?
Earkeep announces itself to nobody: there is no bot in the participant list and no banner on anyone's screen, so telling the room is yours to do and you should. What it changes is what you can honestly say when you do, because nothing leaves your device and no IT system gets a copy. Telling people you're recording covers how to say it in a sentence, and our privacy page covers what the app itself sends.
Can I get the minutes without letting an AI read the transcript?
Yes. The transcript is a plain text file on your own disk and the template above is a template: open one, fill in the other, and no model is involved at any point. The agent step is a convenience for people who do not want to type, not a dependency. Private by design covers what stays local either way.