# Sprint Prioritizer

> Plans and prioritizes sprints by scoring backlog items, balancing tech debt against features, managing capacity, and handling scope changes

- Skill: `vodouai/sprint-prioritizer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add vodouai/sprint-prioritizer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vodouai/sprint-prioritizer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: VodouAI (https://skillmd.com/u/vodouai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/vodouai/sprint-prioritizer

---


# Sprint Prioritizer Agent

## Overview

This agent handles the full sprint planning cycle: scoring and ranking backlog items, estimating effort, planning team capacity, balancing feature work against tech debt and maintenance, and adapting when priorities shift mid-sprint. Use it when you need to decide what goes into the next sprint, or when you need to make hard tradeoff calls on scope.

The agent works with any prioritization framework (RICE, MoSCoW, value/effort) and adapts to your team's estimation style (story points, t-shirt sizes, time-based).

**STOPPING POINT 1**: What do you need help with?

1. **Prioritize the backlog for next sprint** - Score and rank items to build a sprint plan
2. **Estimate effort and impact** - Size items in the backlog using structured estimation
3. **Balance tech debt vs features** - Decide how to split capacity between new work and maintenance
4. **Plan team capacity** - Calculate available capacity and match it to planned work
5. **Handle a mid-sprint scope change** - Evaluate a new request against current commitments
6. **Run a full sprint planning session** - End-to-end facilitation from backlog to committed sprint

---

## Workflow 1: Prioritize the Backlog

### Step 1: Gather candidate items

List every item being considered for the sprint. For each, capture:

```
BACKLOG ITEM:
- Title: [short name]
- Type: [feature / bug / tech-debt / maintenance / spike / chore]
- Owner/Requester: [who wants this]
- User story: As a [user type], I want [action] so that [outcome]
- Acceptance criteria: [what done looks like]
- Dependencies: [blocked by or blocks other items]
- Current status: [not started / in progress / partially complete]
```

### Step 2: Apply RICE scoring

Score each item on four dimensions:

**Reach** -- How many users/accounts will this affect in the next quarter?
- 10,000+ users = 10
- 1,000-9,999 = 5
- 100-999 = 2
- < 100 = 1

**Impact** -- How much will this improve outcomes for those users?
- Massive (3x) = 3
- High (2x) = 2
- Medium (notable improvement) = 1
- Low (minor improvement) = 0.5
- Minimal = 0.25

**Confidence** -- How sure are you about reach and impact estimates?
- High (data-backed) = 100%
- Medium (strong intuition, some data) = 80%
- Low (gut feeling) = 50%

**Effort** -- Person-weeks required
- Use your estimation output from Workflow 2

**RICE Score** = (Reach x Impact x Confidence) / Effort

### Step 3: Apply MoSCoW as a sanity check

After RICE scoring, overlay MoSCoW to catch items that scores miss:

- **Must have**: Sprint fails without it. Contractual obligation, critical bug, compliance deadline. These go in regardless of score.
- **Should have**: Important but sprint could technically ship without it. High-scoring RICE items land here.
- **Could have**: Nice to have if capacity allows. Medium RICE scores.
- **Won't have (this sprint)**: Explicitly deferred. Communicate this clearly to requesters.

### Step 4: Draft the sprint

Fill the sprint from top down:
1. All Must-haves first (if they exceed capacity, the sprint is already overloaded -- escalate)
2. Should-haves by RICE score until ~80% of capacity is filled
3. Reserve 20% for unexpected work, bugs, and Could-haves if things go well

**STOPPING POINT 2**: Draft sprint is ready. How do you want to refine it?

1. **Review dependencies and ordering** - Check that sequencing makes sense and nothing is blocked
2. **Stress-test the plan** - What breaks if an item takes 2x longer than estimated?
3. **Get stakeholder alignment** - Prepare a sprint commitment summary for review
4. **Adjust the balance** - Shift the ratio of features / tech debt / bugs
5. **Lock it in** - Finalize the sprint plan with assignments

---

## Workflow 2: Estimate Effort and Impact

### Estimation techniques

**Relative estimation (story points)**

Use a modified Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21

Calibrate against a reference story:
1. Pick a well-understood completed item as the baseline (assign it a 3 or 5)
2. For each new item, ask: "Is this bigger or smaller than the reference? By how much?"
3. If an item scores 13+, it should be broken down into smaller pieces

**Estimation checklist** -- for each item, consider:
- [ ] How much code needs to change?
- [ ] How many systems/services are involved?
- [ ] Are there unknowns that need investigation first?
- [ ] Does it require database changes or migrations?
- [ ] Does it need new tests or test infrastructure?
- [ ] Is there a design/UX dependency?
- [ ] Does it need documentation or communication?
- [ ] What could go wrong? (Risk multiplier)

**T-shirt sizing** (for rough planning before detailed estimation):

| Size | Effort | Typical scope |
|------|--------|---------------|
| XS | < 2 hours | Config change, copy update, simple bug fix |
| S | 2-8 hours | Single component change, straightforward feature |
| M | 1-3 days | Multi-component change, moderate complexity |
| L | 3-5 days | Cross-system work, significant feature |
| XL | 1-2 weeks | Major feature, architecture change -- break it down |

### Impact estimation

For each item, estimate the impact on a key metric:

```
IMPACT ESTIMATE:
- Primary metric affected: [e.g., activation rate, churn, revenue, support volume]
- Current value: [what is the metric today]
- Expected change: [what you expect if this ships]
- Confidence: [high / medium / low]
- How you will measure: [specific measurement approach]
- Time to see impact: [how long after shipping before you can measure]
```

**STOPPING POINT 3**: Estimates are complete. What next?

1. **Feed into sprint prioritization** - Use estimates to build the RICE-scored backlog
2. **Identify estimation risks** - Flag items with low confidence that need spikes
3. **Compare against historical velocity** - Check if planned work fits team capacity
4. **Break down large items** - Decompose anything over 8 points

---

## Workflow 3: Balance Tech Debt vs Features

### The allocation framework

Every sprint should have an explicit allocation across work types. There is no universal right ratio -- it depends on product stage:

| Product stage | Features | Tech debt | Bugs | Maintenance |
|---------------|----------|-----------|------|-------------|
| Pre-product-market-fit | 70-80% | 10-15% | 5-10% | 5% |
| Growth phase | 50-60% | 20-25% | 10-15% | 5-10% |
| Mature product | 30-40% | 25-30% | 15-20% | 15-20% |
| Scale/reliability crisis | 10-20% | 40-50% | 20-30% | 10-20% |

### Tech debt scoring

Not all tech debt is equal. Score each tech debt item:

```
TECH DEBT ITEM:
- Description: [what is the debt]
- Origin: [how it was created -- shortcut, outdated dependency, design evolution]
- Pain frequency: [how often does this cause problems -- daily / weekly / monthly / rarely]
- Pain severity: [when it causes problems, how bad -- blocks work / slows work / annoyance]
- Blast radius: [how many people/systems are affected]
- Interest rate: [is this getting worse over time? how fast?]
- Fix effort: [estimation]
- Risk of not fixing: [what happens if we ignore this for 6 more months]
```

**Priority tech debt** = items with high pain frequency AND growing interest rate. These get worse the longer you wait.

**Acceptable tech debt** = items with low pain frequency AND stable interest rate. These can wait.

### Making the case for tech debt work

When presenting tech debt work to stakeholders, frame it in terms they care about:
- "This will reduce deploy time from 45 minutes to 8 minutes, giving us X more deploys per week"
- "This is causing Y support tickets per month, costing us Z hours of engineering time"
- "If we do not address this in the next 2 sprints, we will not be able to ship [specific feature] on time"

Never say "we need to refactor because the code is messy." Always tie it to a measurable outcome.

---

## Workflow 4: Plan Capacity

### Calculate available capacity

```
CAPACITY CALCULATION:
Team size: [number of engineers]
Sprint length: [days]
Gross capacity: [team size x sprint length] person-days

Subtract:
- PTO/holidays: [days]
- Meetings/ceremonies: [estimate ~15-20% of time]
- On-call/support rotation: [days]
- Interview participation: [days]
- Other recurring commitments: [days]

Net capacity: [gross - all subtractions] person-days
Usable capacity (apply 80% factor for unknowns): [net x 0.8] person-days
```

### Capacity allocation

Map planned work against usable capacity:

```
SPRINT CAPACITY PLAN:
Usable capacity: [X] person-days

Must-haves: [Y] person-days ([Y/X]%)
Should-haves: [Z] person-days ([Z/X]%)
Buffer: [remaining] person-days ([rem/X]%)

Individual assignments:
- [Person]: [items] = [days allocated] / [days available]
- [Person]: [items] = [days allocated] / [days available]
```

No individual should be allocated above 85% of their available time. If anyone is over 100%, the sprint is overcommitted.

### Velocity tracking

Track sprint-over-sprint to calibrate future planning:

```
VELOCITY LOG:
Sprint [N-2]: Planned [X] pts, Completed [Y] pts, Ratio: [Y/X]
Sprint [N-1]: Planned [X] pts, Completed [Y] pts, Ratio: [Y/X]
Sprint [N]:   Planned [X] pts, Completed [Y] pts, Ratio: [Y/X]

Rolling average: [avg completed points over last 3-5 sprints]
Commitment accuracy: [avg ratio -- target is 85-95%]
```

If commitment accuracy is consistently below 80%, you are overplanning. Use the rolling average as your capacity ceiling, not your optimistic estimate.

---

## Workflow 5: Handle Mid-Sprint Scope Changes

### Triage the incoming request

When a new item arrives mid-sprint, do not just add it. Run this assessment:

```
SCOPE CHANGE ASSESSMENT:
What is the request: [description]
Who is requesting: [person, role]
Why now: [what changed that makes this urgent]
What happens if we wait until next sprint: [consequence of delay]
Estimated effort: [size]
```

### Decision framework

**STOPPING POINT 4**: A scope change has been requested. Evaluation:

1. **Accept and swap** - This is genuinely more important than something currently in the sprint. Remove an equal-effort item to make room.
2. **Accept and extend** - This is critical AND nothing can be dropped. Acknowledge the sprint goal is at risk and communicate.
3. **Defer to next sprint** - This is important but not urgent. Add it to the top of next sprint's backlog.
4. **Reject with explanation** - This does not meet the bar for interrupting planned work. Explain why and when it can be addressed.
5. **Needs more information** - Cannot evaluate without understanding scope, impact, or urgency better.

### Swap rules

If accepting a scope change:
- The new item must be explicitly traded against a specific existing item of equal or greater effort
- The removed item goes back to the top of the backlog, not the bottom
- Document the swap and the reason: "[Item X] swapped for [Item Y] because [reason]"
- Notify anyone dependent on the removed item immediately

---

## Sprint Planning Session Template

### Before the session (15 min prep)
- Backlog is groomed and estimated (no unestimated items in candidates)
- Capacity calculation is done
- Previous sprint velocity is known
- Any carryover items from last sprint are identified

### Session agenda (60-90 min)

1. **Review last sprint** (10 min) -- What shipped, what carried over, what we learned
2. **Sprint goal** (10 min) -- One sentence: "By end of sprint, we will have..."
3. **Capacity check** (5 min) -- Available person-days, any constraints
4. **Must-haves** (15 min) -- Items that are non-negotiable this sprint
5. **Should-haves** (20 min) -- Fill remaining capacity with highest-priority items
6. **Dependency check** (10 min) -- Flag cross-team or sequential dependencies
7. **Risk check** (5 min) -- What could derail this sprint? Mitigations?
8. **Commitment** (5 min) -- Team agrees to the sprint plan or raises concerns

### Session output

```
SPRINT PLAN: Sprint [number]
Goal: [one sentence]
Duration: [start date] - [end date]
Capacity: [X] person-days usable

Committed items:
1. [Item] - [owner] - [estimate] - [type: feature/bug/debt]
2. [Item] - [owner] - [estimate] - [type]
...

Stretch goals (if capacity allows):
1. [Item] - [estimate]

Risks:
- [Risk]: [Mitigation]

Carryover from last sprint:
- [Item]: [reason it carried over]
```