This is a skillset -- it chains
/ipm-plan->/ipm-facilitate->/demo-prep->/demo-feedback->/retro-plan->/retro-synthesizein sequence. Each skill also works independently.
Use this when you need to plan and run the full set of iteration ceremonies -- IPM at the start of the week, demo and retro at the end. The chain ensures outputs from each ceremony feed into the next.
The chain
| Step | Skill | What it produces |
|---|---|---|
| 1 | /ipm-plan | Draft iteration plan with candidate stories and goal |
| 2 | /ipm-facilitate | Facilitation plan with talking points and estimation approach |
| 3 | /demo-prep | Demo agenda with presenters, narratives, and anticipated questions |
| 3.5 | /demo-feedback | Categorized demo feedback with recommended backlog actions |
| 4 | /retro-plan | Retrospective plan with format, script, and discussion prompts |
| 5 | /retro-synthesize | Grouped themes and action items from retro output |
When to use: Throughout the iteration week -- IPM at the start, demo and retro at the end.
How skills chain
/ipm-planselects candidate stories -> feeds into/ipm-facilitatefor the actual meeting/ipm-facilitateproduces the committed plan -> this becomes the source for/demo-prepat week's end/demo-prepstructures the demo narrative around what was actually completed/demo-feedbackprocesses stakeholder feedback from the demo into categorized backlog candidates/retro-planprepares the retro -> after the meeting, raw output feeds into/retro-synthesize/retro-synthesizeproduces action items -> these feed back into the next iteration's backlog
What the PM does between stages
| After... | PM decision |
|---|---|
/ipm-plan | Review candidate stories, adjust based on team capacity and context the AI doesn't have |
/ipm-facilitate | Run the actual IPM meeting using the facilitation plan |
/demo-prep | Confirm presenters, adjust narrative to what actually shipped (not what was planned) |
/demo-feedback | Review categorized feedback, decide what enters the backlog vs. what's noise |
/retro-plan | Facilitate the actual retro, capture raw output |
/retro-synthesize | Assign action item owners, set deadlines, add items to backlog |
Related skills: Part of the
iteration-orbitrecipe. Uses/backlog-craftoutput as input (committed stories from IPM). Feeds retro actions back into the next iteration's backlog.
Example Output
Input
- Team: Meridian Health, Care Navigation product squad (6 engineers, 1 designer, 1 PM)
- Iteration: Sprint 14, week of June 9 — focus on provider search and appointment booking flows
- Backlog snapshot: 23 stories in the icebox; top candidates include "Filter providers by insurance network," "Booking confirmation email," "Timezone-aware appointment display," and "Accessibility audit fixes (WCAG 2.1 AA)"
- Velocity: 3-sprint average of 34 points; one engineer on PTO Monday–Tuesday
- Retro raw output (end of week): Team noted deploy pipeline was slow all week, pairing went well on the timezone story, QA caught a regression late on Thursday, and there's recurring confusion about acceptance criteria ownership between PM and design
Output (abbreviated)
Ceremony Cycle — Meridian Health, Care Navigation Squad
Sprint 14 · June 9–13
Stage 1 · /ipm-plan — Iteration Plan Draft
Iteration Goal: Enable patients to find in-network providers and book appointments with accurate timezone handling.
Candidate Stories
| Story | Points | Priority | Notes |
|---|---|---|---|
| Filter providers by insurance network | 8 | Must-have | Core to iteration goal; unblocks booking flow |
| Timezone-aware appointment display | 5 | Must-have | Dependency for booking confirmation |
| Booking confirmation email | 5 | Must-have | Stakeholder-visible; demo-ready |
| Accessibility audit fixes (WCAG 2.1 AA) | 8 | Should-have | Regulatory pressure; parallelizable |
| Provider profile photo upload | 3 | Nice-to-have | Pull in if capacity allows |
Capacity note: Adjusted ceiling ~28 pts (engineer PTO Mon–Tue). Recommend accepting 26 pts to hold a buffer. Drop profile photo upload unless insurance filter finishes early.
Stage 2 · /ipm-facilitate — Facilitation Plan
Meeting structure (60 min)
- 0:00–0:05 — Frame iteration goal; confirm adjusted capacity aloud
- 0:05–0:20 — Walk candidate stories top-to-bottom; PM presents, team asks clarifying questions before estimation
- 0:20–0:45 — Silent estimation via Planning Poker (Fibonacci); surface split votes immediately
- 0:45–0:55 — Lock committed set; call out explicit dependencies (timezone story before confirmation email)
- 0:55–1:00 — Name the iteration; confirm demo slot (Friday 3pm)
Talking points for contested stories
- Insurance filter: Remind team this is the highest-value story to stakeholders — if it slips, the demo narrative breaks. Consider splitting into "filter UI" and "real-time eligibility API call" if estimates diverge.
- Accessibility fixes: These are parallelizable; a junior engineer can own this track. Don't let it crowd out the core booking stories.
Stage 3 · /demo-prep — Demo Agenda
What actually shipped (PM confirms before running this) Assuming: insurance filter ✅, timezone display ✅, booking confirmation email ✅, accessibility fixes ⚠️ partial
Demo Agenda — Friday June 13, 3:00 PM · 30 min
| Segment | Presenter | Duration | Narrative hook |
|---|---|---|---|
| Intro & iteration goal recap | PM (Jess R.) | 2 min | "This week we made it possible to find a doctor who actually takes your insurance — and book them without getting the time wrong." |
| Insurance network filter (live flow) | Engineer (Tom C.) | 8 min | Walk from search → filter → results narrowed to in-network |
| Timezone-aware booking (live flow) | Designer (Priya M.) | 6 min | Show patient in PST booking with EST provider; confirm display correct on both ends |
| Booking confirmation email | Engineer (Tom C.) | 4 min | Trigger a live booking; show email receipt with correct details |
| Accessibility progress update | PM (Jess R.) | 3 min | Partial — show completed fixes, be transparent about remaining items |
| Q&A / feedback capture | All | 7 min | Designate one person to take written notes for /demo-feedback |
Anticipated questions
- "Does the insurance filter handle multi-plan families?" → Not in scope this sprint; logged as future story
- "What happens if the email fails to send?" → Error handling is in the next sprint; retry logic story is in backlog
- "When will accessibility be 100% complete?" → Sprint 15 target; share the audit tracker link
Stage 3.5 · /demo-feedback — Categorized Feedback
Feedback received (sample from stakeholder session)
| Feedback item | Source | Category | Recommended action |
|---|---|---|---|
| "Show distance from patient's location in filter results" | Dr. Angela W. (Medical Director) | Feature request | Add to icebox; size next IPM |
| "Email subject line feels generic — can it include provider name?" | Patient Advocate rep | Quick polish | Add as 1-pt story; pull into Sprint 15 |
| "Filter is slow when selecting multiple insurance plans at once" | QA lead observation | Bug / performance | P1 bug story; add to Sprint 15 committed set |
| "Love the timezone display — can we show it in calendar invite too?" | Product stakeholder | Feature extension | Add to icebox with dependency note on email feature |
| "Accessibility partial completion is a compliance risk before July 1" | Legal (Mark D.) | Risk / escalation | Escalate to PM; consider accessibility-only sprint or dedicated capacity |
PM decision checkpoint: The performance bug and legal escalation require immediate action. Remaining items are backlog candidates for normal prioritization.
Stage 4 · /retro-plan — Retrospective Plan
Format: Lean Coffee (team preference for discussion-driven format) Duration: 50 minutes | Facilitator: PM (Jess R.)
Script
- 0:00–0:05 — Prime the pump: "Think about this sprint in three buckets — what helped us move, what slowed us down, what still puzzles us."
- 0:05–0:15 — Silent sticky generation (FigJam board, three columns: Worked Well / Friction / Questions)
- 0:15–0:20 — Dot voting (each person gets 4 votes); sort by votes
- 0:20–0:45 — Discuss top 4–5 topics, 4 min each, timeboxed
- 0:45–0:50 — Draft action items together; assign a name to each before the meeting ends
Seed prompts for low-energy moments
- "The deploy pipeline came up in a few stickies — can someone describe what specifically slowed them down?"
- "Thursday's regression — what would have to be true for us to catch that in PR review instead of QA?"
- "Acceptance criteria ownership: when did you last feel unsure who owned a decision — PM or design?"
Stage 5 · /retro-synthesize — Themes & Action Items
Themes from raw retro output
🔴 Theme 1: Deploy pipeline is a consistent drag
- Stickies: "waited 22 min for CI," "had to re-trigger twice," "lost momentum mid-afternoon"
- Root cause hypothesis: flaky integration test suite causing false failures
- Action item: Tom C. to audit flaky tests and open tickets by June 16; target: pipeline under 12 min by Sprint 16
🟡 Theme 2: Late-cycle QA catches regressions that should be caught earlier
- Stickies: "Thursday surprise broke my confidence," "regression was in code we didn't touch — cross-impact"
- Root cause hypothesis: No cross-area smoke test before QA handoff
- Action item: Team to add 15-min "smoke check" pairing session each Wednesday EOD starting Sprint 15 (Rotating pair owns it)
🟡 Theme 3: Acceptance criteria ownership is ambiguous between PM and Design
- Stickies: "I wasn't sure if Priya or Jess made the final call," "wrote AC without design sign-off"
- Root cause hypothesis: No defined handshake point in story-writing workflow
- Action item: