$npx -y skills add product-on-purpose/pm-skills --skill iterate-refinement-notesDocuments backlog refinement session outcomes including stories refined, estimates, questions raised, and decisions made. Use during or after refinement to capture the results and share with absent team members.
| 1 | <!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 --> |
| 2 | # Refinement Notes |
| 3 | |
| 4 | Refinement notes capture the outcomes of backlog refinement (grooming) sessions.what was discussed, what was estimated, and what decisions were made. They serve as a quick reference for team members who missed the session and a historical record of how stories evolved from idea to ready-for-sprint. |
| 5 | |
| 6 | ## When to Use |
| 7 | |
| 8 | - During refinement sessions to capture decisions in real-time |
| 9 | - After refinement to share outcomes with absent team members |
| 10 | - When onboarding new team members to explain backlog context |
| 11 | - Before sprint planning to review what's been refined |
| 12 | - When stories need re-refinement due to time elapsed |
| 13 | |
| 14 | ## When NOT to Use |
| 15 | |
| 16 | - You need the stories themselves written -> use `deliver-user-stories` |
| 17 | - You need a general meeting summary, not a backlog-refinement record -> use `foundation-meeting-recap` |
| 18 | - You are running the retrospective ceremony -> use `iterate-retrospective` |
| 19 | - Refined stories need their failure scenarios enumerated -> use `deliver-edge-cases` |
| 20 | |
| 21 | ## Instructions |
| 22 | |
| 23 | When asked to document refinement notes, follow these steps: |
| 24 | |
| 25 | 1. **Record Session Metadata** |
| 26 | Note the date, attendees, and duration. This helps track who was part of decisions and when discussions happened. |
| 27 | |
| 28 | 2. **List Stories Discussed** |
| 29 | For each story, capture the outcome: estimated points, refined status, key discussion points, and any modifications made to the original scope. |
| 30 | |
| 31 | 3. **Document Questions Raised** |
| 32 | Questions that couldn't be answered in the session need owners and due dates. Don't let them disappear.they often block sprint planning. |
| 33 | |
| 34 | 4. **Capture Decisions Made** |
| 35 | Record any scope decisions, technical approaches agreed upon, or priority changes. These decisions are valuable context that gets lost without documentation. |
| 36 | |
| 37 | 5. **Note Action Items** |
| 38 | Any follow-up work needed before stories are sprint-ready: mockups to create, technical spikes to run, stakeholders to consult. |
| 39 | |
| 40 | 6. **Flag Blocked Stories** |
| 41 | Clearly identify stories that can't proceed until blockers are resolved. Include what the blocker is and who owns resolution. |
| 42 | |
| 43 | 7. **Plan Next Session** |
| 44 | Note what should be refined next and any preparation needed. |
| 45 | |
| 46 | ## Output Format |
| 47 | |
| 48 | Use the template in `references/TEMPLATE.md` to structure the output. Complete notes fill every template section: Session Info; Summary; Stories Refined; Stories Summary Table; Questions Raised; Decisions Made; Action Items; Blocked Stories; Parking Lot; and Next Session. |
| 49 | |
| 50 | ## Quality Checklist |
| 51 | |
| 52 | Before finalizing, verify: |
| 53 | |
| 54 | - [ ] All discussed stories have outcomes recorded |
| 55 | - [ ] Open questions have owners assigned |
| 56 | - [ ] Decisions are captured with enough context |
| 57 | - [ ] Blocked stories are clearly flagged |
| 58 | - [ ] A reader who missed the session can tell each story's outcome and what happens next without asking |
| 59 | |
| 60 | ## Examples |
| 61 | |
| 62 | See `references/EXAMPLE.md` for a completed example. |