Ceremony Playbook¶
Step-by-step guides for running each ceremony. Anyone on the team should be able to pick up this playbook and facilitate any ceremony — no tribal knowledge required.
Sprint Review¶
Purpose: Show stakeholders what was built. Collect feedback before it's released.
Duration: 30 minutes
When: Tuesday, 12:30 PM ET / 9:30 AM PT
Facilitator: PM (default) or Scrum Master
Attendees: Internal team, partner engineers (who demo their work), stakeholders, CPO
Preparation¶
| Who | What | When |
|---|---|---|
| PM | Send calendar reminder with sprint goal and agenda | Monday (day before) |
| PM | Identify which stories are demo-ready and assign demo owners | Monday afternoon |
| Demo owners | Prepare a working demo (not slides, not a Jira walkthrough) | Monday afternoon |
| PM | Prepare a 2-minute sprint summary: goal, what was completed, what wasn't and why | Tuesday morning |
Reminder template (send Monday):
Tomorrow at 12:00 PM ET — Sprint Review
Sprint goal: [one sentence]
Demos: - [Story title] — [demo owner] - [Story title] — [demo owner] - [Story title] — [demo owner]
Stakeholders: your feedback before release is the goal. Come with questions.
Agenda¶
| Time | Activity | Owner |
|---|---|---|
| 0:00 | Sprint summary — goal, what shipped, what didn't | PM |
| 0:02 | Demo 1 | Assigned dev |
| 0:09 | Demo 2 | Assigned dev |
| 0:16 | Demo 3 | Assigned dev |
| 0:23 | Stakeholder Q&A and feedback | PM facilitates |
| 0:28 | Capture action items and new backlog ideas | PM |
| 0:30 | End |
Running the Meeting¶
- Show working software. Not Jira tickets. Not slides. Not code. The actual thing running in staging or production.
- Each demo follows the same format: "This is the problem we solved. Here's what it does. Let me show you." Keep it to 5-7 minutes including questions.
- If a story isn't demo-able (backend work, infrastructure), show the effect: a faster response, a new API endpoint in Postman, a passing test suite. If there's truly nothing to show, describe it in 30 seconds and move on.
- Capture feedback in real time. PM writes down stakeholder feedback as new backlog items or notes — don't rely on memory.
- If there are fewer than 2 demos, shorten the meeting. A 15-minute review is fine. Don't fill time.
Expected Outcomes¶
- [ ] Stakeholders have seen completed work and understand what's about to be released
- [ ] Feedback captured as backlog items or discovery inputs
- [ ] Any release-blocking concerns surfaced before Wednesday release
- [ ] Team gets recognition for completed work
Retrospective¶
Purpose: Reflect on how the sprint went. Identify one thing to improve. Commit to an action.
Duration: 30 minutes
When: Tuesday, 1:15 PM ET / 10:15 AM PT (immediately after review break)
Facilitator: Scrum Master (default) or rotate
Attendees: Internal team only. Partner team members by invitation when cross-team issues need discussion.
Preparation¶
| Who | What | When |
|---|---|---|
| Scrum Master | Review last retro's action items — were they completed? | Monday |
| Scrum Master | Set up the retro board (shared doc, Miro, or simple Slack thread) | Monday |
| All attendees | Think about: what went well, what didn't, what to try next | Before the meeting |
Reminder template (send Monday):
Tomorrow at 1:15 PM ET — Retrospective (30 min, internal team only)
Before the meeting, think about: - One thing that went well this sprint - One thing that didn't go well or frustrated you - One thing you'd like to try next sprint
Last sprint's action item: [action item] — owned by [name]. Status: [done/not done]
Agenda¶
| Time | Activity | Owner |
|---|---|---|
| 0:00 | Review last retro's action item — done or not? | Scrum Master |
| 0:03 | Each person shares: one went-well, one didn't-go-well | Everyone (2 min each) |
| 0:15 | Discuss: identify the most impactful thing to improve | Scrum Master facilitates |
| 0:25 | Agree on ONE action item with an owner and a due date | Scrum Master |
| 0:28 | Confirm: does everyone feel heard? Anything unsaid? | Scrum Master |
| 0:30 | End |
Running the Meeting¶
- Start with last sprint's action item. If it didn't get done, ask why — not to blame, but to understand if action items are realistic. If two retros in a row produce unfinished action items, the team is overcommitting or the items aren't important enough.
- One action item, not five. A single concrete improvement the team commits to is more valuable than a wish list. "Review PRs within 24 hours this sprint" is better than "improve communication."
- The facilitator protects the space. If someone is dominating, redirect. If someone is quiet, invite them in. If a topic is veering into problem-solving, park it: "That's a real issue — let's take it offline after this."
- No status updates. This is not a standup. "I worked on the auth feature" is not retro content. "The auth feature was blocked for 3 days because we didn't have test credentials" is.
- Rotate the facilitator. The Scrum Master is the default, but rotating gives everyone practice and brings fresh perspectives to the format.
Retro Formats (rotate to keep it fresh)¶
Standard (default):
- Went well / Didn't go well / Try next sprint
Start-Stop-Continue:
- What should we start doing? / Stop doing? / Continue doing?
One Word:
- Each person describes the sprint in one word, then explains why. Good for surfacing mood and energy.
Sailboat:
- Wind (what pushed us forward) / Anchor (what held us back) / Rocks (risks ahead)
Expected Outcomes¶
- [ ] Last sprint's action item reviewed (done or explicitly dropped)
- [ ] Each team member shared at least one observation
- [ ] One concrete action item agreed upon with an owner and due date
- [ ] Team feels heard and psychologically safe
Sprint Planning¶
Purpose: Commit to a sprint goal and select stories the team believes they can deliver.
Duration: 60 minutes
When: Tuesday, 2:00 PM ET / 11:00 AM PT
Facilitator: Scrum Master (default) or PM
Attendees: Internal team, partner engineers, PM
Preparation¶
| Who | What | When |
|---|---|---|
| PM | Finalize prioritized backlog — stories should already be groomed from Thursday | Monday |
| PM | Draft a sprint goal (one sentence) | Monday |
| PM | Ensure all stories have acceptance criteria and designs attached | Monday |
| Scrum Master | Pull up last sprint's velocity (total points completed) | Monday |
| Scrum Master | Note any capacity constraints (PTO, holidays, on-call) | Monday |
| All devs | Review the groomed stories before the meeting — come with questions, not first impressions | Tuesday morning |
Reminder template (send Monday):
Tomorrow at 2:00 PM ET — Sprint Planning (60 min)
Proposed sprint goal: [one sentence]
Candidate stories: [link to groomed backlog or Jira filter]
Please review the stories before the meeting so we can focus on estimation and commitment, not reading stories for the first time.
Capacity notes: [any PTO, holidays, or constraints]
Last sprint velocity: [X points]
Agenda¶
| Time | Activity | Owner |
|---|---|---|
| 0:00 | Sprint goal — PM proposes, team discusses and agrees | PM |
| 0:05 | Capacity check — any PTO, constraints, or reduced availability? | Scrum Master |
| 0:08 | Walk through stories in priority order — clarify scope and acceptance criteria | PM presents, team asks questions |
| 0:20 | Estimate stories — story points using planning poker or quick consensus | Scrum Master facilitates |
| 0:45 | Commit — does the team believe they can deliver this set of stories? | Scrum Master asks, team confirms |
| 0:50 | Assign initial owners (optional — team can self-organize Wednesday) | Team |
| 0:55 | Recap: sprint goal, committed stories, total points, any risks | Scrum Master |
| 1:00 | End |
Running the Meeting¶
- Sprint goal first. The goal is a single sentence: "This sprint, we're focused on [outcome]." Not a list of tickets. The goal helps the team make trade-off decisions mid-sprint.
- Stories should not be new. Everything discussed at planning should have been groomed on Thursday. If a story is surprising the team, it wasn't groomed properly — note it and move on. Don't derail planning to groom stories in real time.
- Estimation is a conversation, not a vote. When estimates diverge (one dev says 3, another says 8), the conversation about why is more valuable than the number. The high estimator often sees complexity the others missed.
- Velocity is a guide, not a target. If last sprint was 34 points, plan for roughly 34 points. Don't plan for 50 because "we'll try harder." Don't plan for 20 because "last sprint was unusually productive."
- The team commits, not the PM. The PM proposes priority. The team decides how much they can take on. If the PM pushes for more, the Scrum Master intervenes: "The team has committed to X points. Adding more means something comes out."
- End with clarity. Everyone should leave knowing: (1) the sprint goal, (2) which stories are in the sprint, (3) total committed points, and (4) any known risks.
Expected Outcomes¶
- [ ] Sprint goal agreed upon (one sentence)
- [ ] Stories estimated with story points
- [ ] Team committed to a set of stories within capacity
- [ ] Capacity constraints documented (PTO, holidays)
- [ ] No surprise stories — everything was groomed Thursday
- [ ] Board updated with sprint backlog
Backlog Grooming¶
Purpose: Review candidate stories for the next sprint. Assess dev-readiness. Rough-size the work.
Duration: 60 minutes
When: Thursday, Week 2 of the sprint, 12:30 PM ET / 9:30 AM PT (replaces standup)
Facilitator: PM (default) or Scrum Master
Attendees: Internal team, partner engineers (for shared stories)
Preparation¶
| Who | What | When |
|---|---|---|
| PM | Select 8-12 candidate stories from the backlog (more than will fit — planning will narrow) | Wednesday |
| PM | Ensure each story has: problem statement, acceptance criteria, designs (if applicable) | Wednesday |
| PM | Order stories by priority | Wednesday |
| PM | Flag any stories that need feasibility input from engineering | Wednesday |
Reminder template (send Wednesday):
Tomorrow at 12:30 PM ET — Backlog Grooming (60 min, replaces standup)
Candidate stories for next sprint: [link to Jira filter or list]
I'll walk through each story. Come ready to: - Ask clarifying questions - Flag anything that isn't dev-ready - Give a rough t-shirt size (S/M/L/XL)
Agenda¶
| Time | Activity | Owner |
|---|---|---|
| 0:00 | Context — what's the focus for next sprint? Any themes? | PM |
| 0:03 | Walk through stories in priority order | PM presents each story |
| For each story: read the problem + acceptance criteria, show designs, ask "questions?" | PM | |
| Team asks clarifying questions, flags concerns, gives t-shirt size | Team | |
| 0:50 | Identify any stories that need more refinement before Tuesday planning | PM captures |
| 0:55 | Recap: which stories are dev-ready, which need work | PM |
| 1:00 | End |
Running the Meeting¶
- Dev-ready means the team can estimate it. If devs are asking "what does this actually mean?" or "where's the design?", the story isn't ready. Send it back to the PM.
- T-shirt sizing, not story points. Thursday is for rough sizing (S = 1-2 pts, M = 3-5, L = 8, XL = 13+). Final point estimation happens at Tuesday planning.
- XL stories get split. If a story is XL, ask: "Can this be broken into two stories that each deliver value independently?" If not, it might be an epic, not a story.
- Don't groom more than you need. 8-12 stories is a full sprint's worth plus a buffer. If you're grooming 20 stories, you're wasting time on work that won't make the cut.
- Capture questions for the PM to resolve. If a question can't be answered in grooming, the PM owns getting the answer by Monday so the story is ready for Tuesday planning.
Expected Outcomes¶
- [ ] 6-10 stories assessed as dev-ready with t-shirt sizes
- [ ] Stories needing refinement identified with specific gaps (missing AC, no designs, unclear scope)
- [ ] PM has a clear action list for Friday-Monday refinement
- [ ] Team has a preview of next sprint's work (no surprises at planning)
Mid-Sprint Health Check¶
Purpose: Quick pulse on sprint progress. Surface at-risk stories early enough to adjust.
Duration: 30 minutes (extended standup)
When: Tuesday, Week 2, 12:30 PM ET / 9:30 AM PT
Facilitator: Scrum Master
Attendees: Internal team, partner engineers (if actively working on sprint stories)
Preparation¶
| Who | What | When |
|---|---|---|
| Scrum Master | Review the sprint board — how many stories are done vs. remaining? | Before the meeting |
| Scrum Master | Calculate: are we on pace to complete the sprint commitment? | Before the meeting |
| Scrum Master | Identify any stories that haven't moved since last week | Before the meeting |
No separate reminder needed — this replaces the regular Tuesday standup. Just extend the invite to 30 minutes.
Agenda¶
| Time | Activity | Owner |
|---|---|---|
| 0:00 | Board snapshot — stories completed vs. remaining, points burned vs. total | Scrum Master |
| 0:05 | At-risk stories — which stories might not make the sprint? Why? | Team identifies |
| 0:15 | Scope decision — do we need to pull anything out? Add anything? | PM + Scrum Master |
| 0:25 | Blockers — anything stuck that needs help or escalation? | Team |
| 0:30 | End |
Running the Meeting¶
- This is not a second standup. Don't go person-by-person. Focus on the sprint as a whole: are we going to hit the goal?
- Be honest about risk. "This story is at risk" on Tuesday gives the team 6 working days to adjust. Silence until Friday is too late.
- Pulling stories out is not failure. If the team overcommitted or something unexpected came up, removing a story from the sprint is the right call. It's better than carrying half-done work into the next sprint.
- Keep it short. If the sprint is on track and there are no blockers, this can be 10 minutes. Don't stretch to fill 30.
Expected Outcomes¶
- [ ] Clear picture of sprint health (on track / at risk / off track)
- [ ] At-risk stories identified with a plan (push harder, pair up, or pull out)
- [ ] Any scope changes agreed upon
- [ ] Blockers escalated to whoever can resolve them
Daily Standup¶
Purpose: Sync on progress, surface blockers, keep momentum.
Duration: 15 minutes
When: Daily at 12:30 PM ET / 9:30 AM PT (async on Wednesdays)
Facilitator: Scrum Master (or self-facilitated)
Attendees: Internal team. Partner engineers optional (can post async).
Synchronous Format (Mon, Tue, Thu, Fri)¶
Each person answers three questions:
- What did I do since last standup?
- What am I doing today?
- Is anything blocking me?
Rules:
- 2 minutes per person max. If a topic needs discussion, take it offline: "Let's sync on that after standup."
- Don't solve problems in standup. Surface them and schedule a follow-up.
- Start on time. Don't wait for latecomers.
- Stand up (if in person) or keep cameras on (if remote). It naturally keeps things short.
Async Format (Wednesdays)¶
Post in the team Slack channel by 12:30 PM ET / 9:30 AM PT:
Yesterday: [what you completed]
Today: [what you're working on]
Blockers: [anything stuck, or "none"]
Rules:
- Post even if there's nothing interesting to report. Silence is ambiguous.
- If someone posts a blocker, respond — don't wait for Thursday standup.
- No-meeting Wednesday is sacred. Don't turn the async thread into a discussion. If something needs a conversation, schedule it for Thursday.
Expected Outcomes¶
- [ ] Everyone knows what the team is working on
- [ ] Blockers surfaced within 24 hours of occurring
- [ ] No surprises at mid-sprint health check
Ceremony Calendar at a Glance¶
| Ceremony | Duration | Facilitator | Reminder | Key Prep |
|---|---|---|---|---|
| Sprint Review | 30 min | PM | Monday | Assign demos, draft sprint summary |
| Retrospective | 30 min | Scrum Master | Monday | Review last action item, set up board |
| Sprint Planning | 60 min | Scrum Master | Monday | Finalize backlog, draft sprint goal, check capacity |
| Backlog Grooming | 60 min | PM | Wednesday | Select and prioritize candidate stories |
| Mid-Sprint Check | 30 min | Scrum Master | None (replaces standup) | Review board progress |
| Standup | 15 min | Self-facilitated | None | Come prepared with your 3 answers |
All reminders go out the day before. All prep happens the day before. No one should walk into a ceremony unprepared.