mirror of
https://github.com/phuryn/pm-skills.git
synced 2026-06-14 15:34:56 +03:00
Pawel Huryn
194 lines
5.0 KiB
Markdown
194 lines
5.0 KiB
Markdown
---
|
|
description: Sprint lifecycle — plan a sprint, run a retrospective, or generate release notes
|
|
argument-hint: "[plan|retro|release-notes] <context>"
|
|
---
|
|
|
|
# /sprint -- Sprint Lifecycle
|
|
|
|
Three modes covering the sprint lifecycle: **plan** for sprint planning, **retro** for retrospectives, **release-notes** for shipping communication.
|
|
|
|
## Invocation
|
|
|
|
```
|
|
/sprint plan 2-week sprint, 4 engineers, focus on checkout improvements
|
|
/sprint retro [paste team feedback or sprint data]
|
|
/sprint release-notes [paste tickets, changelog, or PRD]
|
|
/sprint # asks which phase you're in
|
|
```
|
|
|
|
## Modes
|
|
|
|
---
|
|
|
|
### Plan Mode
|
|
|
|
Prepare for sprint planning with capacity estimation, story selection, and risk identification.
|
|
|
|
#### Workflow
|
|
|
|
**Step 1: Gather Sprint Context**
|
|
- Sprint duration (1 or 2 weeks)
|
|
- Team composition (engineers, designers, QA — and availability)
|
|
- Sprint goal or focus area
|
|
- Backlog items to consider (paste, upload, or describe)
|
|
- Any carry-over from last sprint
|
|
- Known interruptions (holidays, on-call, meetings)
|
|
|
|
**Step 2: Estimate Capacity**
|
|
|
|
Apply the **sprint-plan** skill:
|
|
|
|
- Calculate available engineering hours/points after meetings, on-call, PTO
|
|
- Apply a velocity adjustment based on historical data (if provided) or industry standard (70% of theoretical capacity)
|
|
- Show capacity breakdown per team member
|
|
|
|
**Step 3: Select and Sequence Stories**
|
|
|
|
- Recommend which stories fit within capacity
|
|
- Flag dependency chains (A must complete before B starts)
|
|
- Identify risks: stories that are underspecified, have external dependencies, or need design input
|
|
- Balance quick wins with larger items
|
|
- Ensure every story has acceptance criteria
|
|
|
|
**Step 4: Generate Sprint Plan**
|
|
|
|
```
|
|
## Sprint Plan: [Sprint Name/Number]
|
|
|
|
**Duration**: [dates]
|
|
**Sprint Goal**: [one sentence]
|
|
**Team**: [members and availability]
|
|
|
|
### Capacity
|
|
| Member | Available Days | Points/Hours | Notes |
|
|
|--------|--------------|-------------|-------|
|
|
|
|
**Total capacity**: [X] points/hours
|
|
**Recommended commitment**: [Y] points/hours (with buffer)
|
|
|
|
### Selected Stories
|
|
| # | Story | Points | Owner | Dependencies | Risk |
|
|
|---|-------|--------|-------|-------------|------|
|
|
|
|
### Sprint Risks
|
|
1. [Risk] — Mitigation: [action]
|
|
|
|
### Definition of Done
|
|
- [ ] Code reviewed
|
|
- [ ] Tests passing
|
|
- [ ] Deployed to staging
|
|
- [ ] QA approved
|
|
- [ ] Documentation updated (if applicable)
|
|
```
|
|
|
|
---
|
|
|
|
### Retro Mode
|
|
|
|
Facilitate a structured retrospective that produces actionable improvements.
|
|
|
|
#### Workflow
|
|
|
|
**Step 1: Gather Sprint Feedback**
|
|
|
|
Accept input as:
|
|
- Team feedback (pasted from a survey, Slack, or collaborative doc)
|
|
- Sprint metrics (velocity, bugs, incidents)
|
|
- The user's own observations
|
|
|
|
Ask: "Which retro format do you prefer?"
|
|
- **Start/Stop/Continue** (simple, fast)
|
|
- **4Ls** (Liked, Learned, Lacked, Longed for)
|
|
- **Sailboat** (Wind = helps, Anchor = slows, Rocks = risks, Island = goals)
|
|
|
|
**Step 2: Analyze and Structure**
|
|
|
|
Apply the **retro** skill:
|
|
|
|
- Categorize feedback into the chosen framework
|
|
- Identify themes and patterns
|
|
- Separate symptoms from root causes
|
|
- Highlight wins worth celebrating
|
|
|
|
**Step 3: Generate Retro Summary**
|
|
|
|
```
|
|
## Sprint Retrospective: [Sprint Name]
|
|
|
|
**Date**: [today]
|
|
**Format**: [Start/Stop/Continue | 4Ls | Sailboat]
|
|
**Participants**: [if known]
|
|
|
|
### What Went Well
|
|
[Grouped themes with supporting evidence]
|
|
|
|
### What Didn't Go Well
|
|
[Grouped themes with root cause analysis]
|
|
|
|
### Key Insights
|
|
[2-3 patterns that emerged]
|
|
|
|
### Action Items
|
|
| # | Action | Owner | Deadline | Priority |
|
|
|---|--------|-------|----------|----------|
|
|
|
|
### Metrics This Sprint
|
|
| Metric | This Sprint | Last Sprint | Trend |
|
|
|--------|-----------|------------|-------|
|
|
```
|
|
|
|
---
|
|
|
|
### Release Notes Mode
|
|
|
|
Generate user-facing release notes from technical artifacts.
|
|
|
|
#### Workflow
|
|
|
|
**Step 1: Accept Release Content**
|
|
|
|
Accept:
|
|
- Jira/Linear tickets or changelog
|
|
- PRD or feature specs
|
|
- Git commit messages or PR descriptions
|
|
- Team's internal summary of what shipped
|
|
|
|
**Step 2: Transform**
|
|
|
|
Apply the **release-notes** skill:
|
|
|
|
- Translate technical language into user benefits
|
|
- Categorize as: New Features, Improvements, Bug Fixes
|
|
- Write in the product's voice (ask about tone if not clear)
|
|
- Highlight the most impactful change first
|
|
|
|
**Step 3: Generate Release Notes**
|
|
|
|
```
|
|
## What's New — [Version/Date]
|
|
|
|
### Highlights
|
|
[1-2 sentence summary of the most important change]
|
|
|
|
### New Features
|
|
- **[Feature Name]** — [user-facing benefit in plain language]
|
|
|
|
### Improvements
|
|
- **[Improvement]** — [what's better now]
|
|
|
|
### Bug Fixes
|
|
- Fixed [issue] that caused [user impact]
|
|
|
|
### Coming Soon
|
|
[Optional teaser for next release]
|
|
```
|
|
|
|
Save as markdown and offer to format for different channels (blog post, in-app, email, Slack announcement).
|
|
|
|
## Notes
|
|
|
|
- For plan mode: protect 20% buffer for unplanned work — teams that plan at 100% capacity always miss
|
|
- For retro mode: focus on 2-3 high-impact action items, not 10 things nobody will do
|
|
- For release notes: always frame changes as user benefits, not technical implementations
|
|
- Each mode can chain to the others: plan → (sprint happens) → retro → release-notes
|