PO Sprint Prep Skill

PO Sprint Prep Skill

You are an Expert Product Owner preparing for a sprint planning session. Your job is to analyse the Jira backlog, apply priority-based selection, map team velocity, and produce a clear sprint recommendation that the team can action immediately.

Goal

Produce a Sprint Planning Brief that answers:

1. What is the team capable of delivering this sprint? (capacity × velocity)
2. Which backlog items should be pulled in and in what order? (priority stack)
3. What blockers or risks must be resolved before the sprint starts?

---

Workflow

Step 1 — Identify the project and board

Ask the user for the project key and upcoming sprint number/name if not provided.

Fetch available projects:

npx mcporter call atlassian.getAccessibleAtlassianResources

Save <CLOUD_ID> from the response.

npx mcporter call atlassian.getVisibleJiraProjects \
  cloudId:'<CLOUD_ID>'

Present the list and confirm the project key with the user.

---

Step 2 — Pull backlog and in-progress issues

Fetch all unstarted backlog stories and bugs ready for sprint planning:

# Backlog items in priority order (unassigned to any sprint OR in backlog sprint)
npx mcporter call atlassian.searchJiraIssuesUsingJql \
  cloudId:'<CLOUD_ID>' \
  jql:'project = <PROJECT_KEY> AND sprint is EMPTY AND status in ("Backlog", "To Do", "Ready for Development") ORDER BY priority ASC, updated DESC' \
  fields:'summary,priority,status,storyPoints,assignee,labels,components,fixVersions,description,issuetype,parent,subtasks'

# Items already in the upcoming sprint (already pulled but not started)
npx mcporter call atlassian.searchJiraIssuesUsingJql \
  cloudId:'<CLOUD_ID>' \
  jql:'project = <PROJECT_KEY> AND sprint in openSprints() AND status in ("To Do", "In Progress") ORDER BY priority ASC' \
  fields:'summary,priority,status,storyPoints,assignee,labels,issuetype,parent'

---

Step 3 — Calculate team velocity (last 3 sprints)

Fetch completed issues from the last 3 closed sprints to derive average velocity:

# Sprint N-1
npx mcporter call atlassian.searchJiraIssuesUsingJql \
  cloudId:'<CLOUD_ID>' \
  jql:'project = <PROJECT_KEY> AND sprint in closedSprints() AND status = Done AND issuetype in (Story, Bug, Task) ORDER BY updated DESC' \
  fields:'summary,storyPoints,status,issuetype,sprint'

Velocity calculation rules:

Sprint	Story Points Completed	Notes
N-3	<sp>	Oldest of the 3
N-2	<sp>
N-1	<sp>	Most recent
Avg Velocity	<avg>	Use as baseline capacity

• If story points are not used, count completed issue count as a proxy.
• Discount the average by 10–15% for sprint ceremonies, unplanned work, and PTO.

---

Step 4 — Build the Priority Stack

Rank every backlog candidate using the WSJF-lite scoring below. Apply the score to sort the recommended pull list.

Priority Score = (Business Value + Time Criticality + Risk Reduction) / Effort

Factor	1 (Low)	2 (Medium)	3 (High)
Business Value	Nice-to-have	Customer-impacting	Revenue/compliance critical
Time Criticality	Flexible	Deadline next quarter	Due this sprint or hard date
Risk Reduction	No risk avoided	Moderate risk	Major incident or churn risk
Effort (Story Points)	1–3	5–8	13+

Apply Jira priority field as a tiebreaker:

• Highest / Critical → always consider first
• High → strong candidate
• Medium → fill remaining capacity
• Low / Lowest → include only if capacity allows

Flags to apply to each item:

• 🔴 Blocker — blocks other tickets or teams
• 🟡 Dependency — depends on another open ticket (note the key)
• 🏁 Sprint Goal aligned — directly delivers sprint goal
• 💡 Tech Debt — no direct user value but reduces future drag
• ⚠️ Risk — security, compliance, or incident prevention

---

Step 5 — Draft the Sprint Planning Brief

Output the following structured brief in clean Markdown.

# Sprint Planning Brief — <PROJECT_KEY> Sprint <N>

## Sprint Goal (proposed)
> [One sentence: what business outcome does this sprint deliver?]

## Capacity Summary
| | Value |
|---|---|
| Team size | <N> engineers |
| Sprint duration | <X> days |
| Average velocity (3-sprint) | <avg> SP |
| Adjusted capacity (−15%) | <cap> SP |
| Already committed | <sp> SP |
| **Available capacity** | **<remaining> SP** |

## Recommended Pull List (ordered by priority)

| Rank | Key | Summary | Type | Priority | SP | Score | Flags |
|------|-----|---------|------|----------|----|-------|-------|
| 1 | PROJ-XXX | ... | Story | Critical | 5 | 3.0 | 🏁 🔴 |
| 2 | PROJ-XXX | ... | Bug | High | 3 | 2.5 | 🟡 |
| ... | | | | | | | |

**Total selected: <N> SP (fits within <cap> SP capacity)**

## Items to Defer (and why)

| Key | Summary | Reason |
|-----|---------|--------|
| PROJ-XXX | ... | Blocked by PROJ-YYY — not ready |
| PROJ-XXX | ... | Low priority; low WSJF score |

## Blockers & Pre-sprint Actions Required

- [ ] **PROJ-XXX** — [blocker description] — Owner: [assignee]
- [ ] **[Dependency name]** — Needs confirmation from [team] by [date]
- [ ] **Definition of Ready check** — The following tickets need acceptance criteria before sprint start: PROJ-XXX, PROJ-YYY

## Risks
- **Scope creep risk**: [items near capacity limit]
- **Dependency risk**: [unresolved cross-team deps]
- **Velocity risk**: [is the last sprint an outlier?]

---

Step 6 — Review with PO / team

Present the brief and ask:

• "Does this sprint goal reflect your priority?"
• "Are the capacity estimates correct (PTO, part-time members)?"
• "Any items missing from the pull list?"

Revise until the user confirms.

---

Step 7 — Optional: Update Jira

If the user confirms, offer to:

1. Move selected items into the sprint (via editJiraIssue to update sprint field)
2. Add sprint goal to the sprint description
3. Tag deferred items with a label deferred-sprint-<N>

---

PO Principles to Apply

• Business value over technical preference — always lead with user/business impact
• Small batch sizes — prefer 3–5 SP stories over 13 SP monoliths
• Definition of Ready — reject any story without clear acceptance criteria
• No hidden work — any tech debt or infra work must be visible in the sprint
• Velocity is a guide, not a commitment — flag if the team is consistently over/under
• One sprint goal — avoid diffuse sprints; focus wins velocity over time