| name | sprint-planning |
| description | Sprint planning prep — backlog candidates, stale items, release priorities, capacity analysis, and pull suggestions. Run before sprint planning to prepare. |
| allowed-tools | ["mcp__atlassian__jira_search","mcp__atlassian__jira_get_issue","mcp__atlassian__jira_get_project_versions","mcp__atlassian__jira_get_project_components","mcp__atlassian__jira_get_agile_boards","mcp__atlassian__jira_get_sprints_from_board","mcp__atlassian__jira_get_sprint_issues","mcp__atlassian__jira_batch_get_changelogs"] |
Sprint Planning Prep
Surface everything needed to run an effective sprint planning session: backlog candidates ready to pull, stale items at risk of being lost, release-scoped priorities, and capacity analysis. Read-only — surfaces data, never modifies tickets. Uses mcp__atlassian__* MCP tools exclusively (not jira-cli).
Run this before sprint planning to anchor the conversation around what to commit to next.
Custom Field Reference
| Field ID | Name | Notes |
|---|
customfield_10028 | Story Points | The story points field for this instance |
customfield_10464 | Activity Type | Select dropdown |
Important: Pass the fields parameter on every issue query:
fields: "summary,description,issuetype,status,priority,labels,assignee,reporter,created,updated,components,fixVersions,customfield_10028,customfield_10464"
Behavior
1. Current Sprint Context
Establish where things stand before planning the next sprint.
- Use
mcp__atlassian__jira_get_agile_boards → mcp__atlassian__jira_get_sprints_from_board to find the active sprint
- Use
mcp__atlassian__jira_get_sprint_issues to pull all sprint issues. You must pass the fields parameter:
fields: "summary,description,issuetype,status,priority,labels,assignee,reporter,created,updated,components,fixVersions,customfield_10028,customfield_10464"
- For each issue, read story points from
customfield_10028.
- Calculate: issues by status, story points per status, progress %
- Identify carry-over candidates: items still in To Do or In Progress that may spill
This gives the baseline: how much is likely to carry over and how much capacity is actually available.
2. Historical Velocity
Look at the most recent closed sprint(s) to establish a velocity baseline.
- Use
mcp__atlassian__jira_get_sprints_from_board — find the last 1-2 closed sprints (state = "closed")
- For each, use
mcp__atlassian__jira_get_sprint_issues (pass fields parameter with customfield_10028) to count completed story points
- Calculate average velocity (points completed per sprint)
This sets the capacity ceiling for the next sprint.
3. Release-Scoped Priorities
Surface items tagged with a Fix Version that need sprint assignment.
4. Backlog Candidates
Surface groomed backlog items that are ready to pull into a sprint.
Search using mcp__atlassian__jira_search with the fields parameter:
jql: "project = HYPERFLEET AND status != Done AND status != Closed AND (sprint not in openSprints() OR sprint is EMPTY) ORDER BY priority ASC, updated DESC"
fields: "summary,description,issuetype,status,priority,labels,assignee,reporter,created,updated,components,fixVersions,customfield_10028,customfield_10464"
For each item, score readiness on 6 points (story points, description, AC, component, activity type, assignee). Filter to items scoring 4+ — these are ready or nearly ready.
Cap at 15 candidates. Sort by priority, then by readiness score.
5. Stale Items at Risk
Surface backlog items that are aging and at risk of being forgotten.
From the backlog query results, use mcp__atlassian__jira_batch_get_changelogs on items with updated older than 60 days to verify staleness is real (meaningful updates, not just bot edits).
Classify:
| Tier | Criteria | Recommended Action |
|---|
| Stale | No meaningful update in 90+ days | Close or re-evaluate — is this still needed? |
| Aging | No meaningful update in 60-89 days | Groom next session or deprioritize |
Cap at 10 items. These need a decision: pull them in, close them, or consciously defer them.
6. Ungroomed Items Needing Attention
Surface items that can't be pulled in yet because they're missing critical fields.
From the backlog query, filter to items scoring 0-3 on the readiness scale that have High or Highest priority. These are important but not sprint-ready.
For each, note what's missing (no points, no AC, no assignee, etc.).
Cap at 10 items.
7. Capacity Analysis
Estimate available capacity for the next sprint:
- Velocity baseline: average points completed per sprint (from Step 2)
- Carry-over load: points likely carrying over from current sprint (from Step 1)
- Available capacity: velocity minus carry-over
- Release pressure: total remaining points across unreleased Fix Versions with dates (from Step 3)
This is an estimate, not a commitment. PTO and unexpected work aren't factored in — note this caveat.
Output Format
## Sprint Planning Prep
**Generated:** [date]
**Current sprint:** [Sprint Name] (Day X of Y, X% complete)
---
### 1. Capacity Estimate
| Metric | Points |
|--------|--------|
| Average velocity (last 2 sprints) | X pts |
| Likely carry-over | X pts |
| **Available capacity** | **X pts** |
**Release pressure:** X pts remaining across [N] unreleased versions
---
### 2. Carry-Over from Current Sprint
| Ticket | Summary | Pts | Status | Assignee |
|--------|---------|-----|--------|----------|
| PROJ-123 | [Summary] | 5 | In Progress | @person |
| PROJ-456 | [Summary] | 3 | To Do | @person |
**Total carry-over:** X items, Y pts
---
### 3. Release Priorities (not in sprint)
Items tagged with a Fix Version that need sprint assignment:
#### [Version Name] — release date: [date] ([X] days away)
| Ticket | Summary | Pts | Priority | Ready? |
|--------|---------|-----|----------|--------|
| PROJ-789 | [Summary] | 5 | High | 5/6 |
| PROJ-012 | [Summary] | - | High | 2/6 (no pts, no AC) |
---
### 4. Backlog Candidates (ready to pull)
Groomed items not in any sprint, scored 4+/6:
| Ticket | Summary | Pts | Priority | Score | Missing |
|--------|---------|-----|----------|-------|---------|
| PROJ-345 | [Summary] | 3 | High | 6/6 | — |
| PROJ-678 | [Summary] | 5 | Medium | 4/6 | labels, assignee |
---
### 5. Stale Items (at risk of being lost)
| Ticket | Summary | Last Meaningful Update | Days Stale | Action Needed |
|--------|---------|----------------------|------------|---------------|
| PROJ-111 | [Summary] | 2025-12-01 | 143 | Close or re-evaluate |
| PROJ-222 | [Summary] | 2026-01-15 | 98 | Groom or deprioritize |
---
### 6. Ungroomed but Important
High-priority items that can't be pulled in yet:
| Ticket | Summary | Priority | Score | Missing |
|--------|---------|----------|-------|---------|
| PROJ-333 | [Summary] | Highest | 2/6 | pts, AC, component, activity type |
---
### Suggested Pull Order
Based on release pressure, priority, and readiness:
| # | Ticket | Summary | Pts | Why |
|---|--------|---------|-----|-----|
| 1 | PROJ-123 | [Summary] | 5 | Carry-over, in progress |
| 2 | PROJ-789 | [Summary] | 5 | Release [v1.2] in 14 days |
| 3 | PROJ-345 | [Summary] | 3 | High priority, fully groomed |
| 4 | PROJ-678 | [Summary] | 5 | Medium priority, nearly ready |
**Running total:** X pts (vs X pts available)
Integration
- sprint-review: Run after planning to validate the final sprint — readiness, capacity, risks
- hygiene: Use to audit sprint tickets after planning is complete
- ticket-triage: Use to walk through ungroomed items interactively
- story-pointer: Use to estimate unpointed candidates
- set-activity-type: Use to fill missing activity types
- release-status: Complementary — release-status gives a deep dive on one Fix Version, this gives a cross-release view for planning
- backlog-grooming: Complementary — backlog-grooming is the full weekly audit, this surfaces planning-relevant items
Notes
- Apply the ghostwriter skill for tone
- The capacity estimate is directional — note that PTO, support load, and unplanned work aren't factored in
- The suggested pull order is a starting point for discussion, not a prescribed commitment
- Keep the report scannable — tables over prose
- Do NOT use jira-cli or Bash for JIRA queries — use the mcp__atlassian__ MCP tools only
