Sprint Prioritizer Skill
Domain knowledge for sprint planning, feature prioritization, and capacity management.
Feeds into: sprint-agent edge function (task generation, prioritization), Composer Group D (next steps prioritization).
RICE Framework
The primary scoring model for ranking features and tasks. Formula:
RICE Score = (Reach x Impact x Confidence) / Effort
Dimension Definitions
| Dimension |
Scale |
How to Estimate |
| Reach |
Number of users affected per quarter |
Use analytics data, user segments, or % of MAU |
| Impact |
0.25 = minimal, 0.5 = low, 1 = medium, 2 = high, 3 = massive |
How much does this move the target metric per user? |
| Confidence |
100% = high (data-backed), 80% = medium (strong intuition), 50% = low (speculation) |
Downgrade ambitious estimates honestly |
| Effort |
Person-months (0.5 minimum) |
Include design, dev, QA, deployment. Add 15% buffer |
Scoring Example
| Feature |
Reach |
Impact |
Confidence |
Effort |
RICE Score |
| Onboarding redesign |
500/qtr |
2 (high) |
80% |
2 pm |
400 |
| Dark mode |
200/qtr |
0.5 (low) |
100% |
1 pm |
100 |
| API webhooks |
50/qtr |
3 (massive) |
50% |
3 pm |
25 |
Rule: When two items score within 10% of each other, use strategic alignment as the tiebreaker, not the decimal.
Value vs Effort Matrix
Plot features on a 2x2 grid for rapid triage:
| Quadrant |
Value |
Effort |
Action |
| Quick Wins |
High |
Low |
Do first. Highest ROI per sprint point |
| Big Bets |
High |
High |
Plan carefully. Phase into milestones |
| Fill-Ins |
Low |
Low |
Use for capacity balancing. Do not plan sprints around these |
| Time Sinks |
Low |
High |
Reject or fundamentally redesign. Never "just do it" |
Kano Model Classification
Categorize features by how they affect user satisfaction:
| Type |
If Present |
If Absent |
Sprint Priority |
| Must-Have |
No increase in satisfaction (expected) |
Strong dissatisfaction |
Always include. Ship first |
| Performance |
Linear satisfaction increase |
Linear dissatisfaction |
Optimize based on RICE score |
| Delighter |
Disproportionate satisfaction |
No dissatisfaction |
Invest selectively for differentiation |
| Indifferent |
No impact |
No impact |
Remove from backlog |
| Reverse |
Decreases satisfaction |
No impact |
Do not build. Kill if exists |
Key insight: Must-Haves degrade over time (today's delighter is tomorrow's must-have). Re-evaluate quarterly.
Sprint Planning Process
Pre-Sprint (Week Before)
- Backlog Refinement: Size stories, review acceptance criteria, validate definition of done
- Dependency Mapping: Identify cross-team blockers. Resolve before sprint starts, not during
- Capacity Assessment: Calculate available person-days (subtract PTO, meetings, overhead at 15-20%)
- Risk Identification: Flag technical unknowns. Spike stories for anything with > 50% uncertainty
- Stakeholder Alignment: Confirm priorities have not shifted. Get explicit sign-off
Sprint Planning (Day 1)
- Sprint Goal: One clear, measurable objective. "Ship X so that Y users can Z" format
- Story Selection: Pull from ranked backlog up to capacity minus 15% buffer
- Task Breakdown: Each story broken into tasks with individual estimates and skill matching
- Definition of Done: Quality bar explicit -- includes tests, docs, review, deployment
- Team Commitment: Collective agreement on deliverables. Not assigned top-down
Execution Support
- Daily standups: 15 min. Three questions: done, doing, blocked. Solve blockers offline
- Mid-sprint check: Day 3-4. If burndown is off track, cut scope (do not extend time)
- Stakeholder updates: Proactive, not reactive. Share progress before they ask
Capacity Planning
Velocity Calculation
- Use 6-sprint rolling average (not last sprint, not best sprint)
- Adjust for team composition changes: new member = 50% velocity for first sprint
- Overhead factor: subtract 15-20% from raw capacity for meetings, reviews, support
- Uncertainty buffer: 10-15% for stable teams, 20-25% for new teams or new domains
Capacity Formula
Available capacity = (team_size x working_days x hours_per_day)
x (1 - overhead_factor)
x (1 - uncertainty_buffer)
Load Balancing Rules
- No individual above 85% utilization (burnout prevention)
- Each story has a primary and secondary owner (bus factor)
- Distribute complexity evenly -- do not stack all hard stories on one person
- Include one stretch assignment per sprint for growth
Sprint Anti-Patterns
| Anti-Pattern |
Symptom |
Fix |
| Scope creep |
Stories added mid-sprint |
Strict change management: new work goes to next sprint |
| Carryover debt |
Same stories roll 3+ sprints |
Re-estimate, break down further, or kill |
| No slack |
100% capacity committed |
Always keep 15% buffer for emergent work |
| Hero dependency |
One person owns 60%+ of points |
Redistribute, pair program, cross-train |
| Velocity inflation |
Points increase but output does not |
Calibrate against delivered value, not story counts |
Success Metrics
| Metric |
Target |
What It Tells You |
| Sprint completion rate |
90%+ committed points delivered |
Planning accuracy |
| Velocity variance |
< 15% sprint-to-sprint |
Team stability and predictability |
| Carryover rate |
< 10% of committed stories |
Estimation and scoping quality |
| Cycle time |
Trending downward |
Process efficiency |
| Feature success rate |
80%+ meet predefined success criteria |
Prioritization quality |
| Tech debt ratio |
< 20% of sprint capacity |
Long-term code health |
StartupAI Integration Points
- sprint-agent EF: Generates 24 validation tasks (4 per sprint x 6 sprints) using RICE scoring for prioritization. Kano classification determines must-have vs delighter tasks
- Composer Group D: Next steps in validator reports are prioritized using Value vs Effort matrix (Quick Wins first, Big Bets phased)
- Sprint Board UI: KanbanBoard uses capacity planning formulas for load indicators, velocity calculation for sprint health
- Validator scoring: Execution dimension evaluates whether the startup has a credible sprint plan with realistic capacity estimates
1---2name: sprint-prioritizer3description: Sprint Prioritizer Skill4---5# Sprint Prioritizer Skill67> Domain knowledge for sprint planning, feature prioritization, and capacity management.8> Feeds into: `sprint-agent` edge function (task generation, prioritization), Composer Group D (next steps prioritization).910## RICE Framework1112The primary scoring model for ranking features and tasks. Formula:1314```15RICE Score = (Reach x Impact x Confidence) / Effort16```1718### Dimension Definitions1920| Dimension | Scale | How to Estimate |21|-----------|-------|-----------------|22| **Reach** | Number of users affected per quarter | Use analytics data, user segments, or % of MAU |23| **Impact** | 0.25 = minimal, 0.5 = low, 1 = medium, 2 = high, 3 = massive | How much does this move the target metric per user? |24| **Confidence** | 100% = high (data-backed), 80% = medium (strong intuition), 50% = low (speculation) | Downgrade ambitious estimates honestly |25| **Effort** | Person-months (0.5 minimum) | Include design, dev, QA, deployment. Add 15% buffer |2627### Scoring Example2829| Feature | Reach | Impact | Confidence | Effort | RICE Score |30|---------|-------|--------|------------|--------|------------|31| Onboarding redesign | 500/qtr | 2 (high) | 80% | 2 pm | 400 |32| Dark mode | 200/qtr | 0.5 (low) | 100% | 1 pm | 100 |33| API webhooks | 50/qtr | 3 (massive) | 50% | 3 pm | 25 |3435**Rule**: When two items score within 10% of each other, use strategic alignment as the tiebreaker, not the decimal.3637## Value vs Effort Matrix3839Plot features on a 2x2 grid for rapid triage:4041| Quadrant | Value | Effort | Action |42|----------|-------|--------|--------|43| **Quick Wins** | High | Low | Do first. Highest ROI per sprint point |44| **Big Bets** | High | High | Plan carefully. Phase into milestones |45| **Fill-Ins** | Low | Low | Use for capacity balancing. Do not plan sprints around these |46| **Time Sinks** | Low | High | Reject or fundamentally redesign. Never "just do it" |4748## Kano Model Classification4950Categorize features by how they affect user satisfaction:5152| Type | If Present | If Absent | Sprint Priority |53|------|-----------|-----------|-----------------|54| **Must-Have** | No increase in satisfaction (expected) | Strong dissatisfaction | Always include. Ship first |55| **Performance** | Linear satisfaction increase | Linear dissatisfaction | Optimize based on RICE score |56| **Delighter** | Disproportionate satisfaction | No dissatisfaction | Invest selectively for differentiation |57| **Indifferent** | No impact | No impact | Remove from backlog |58| **Reverse** | Decreases satisfaction | No impact | Do not build. Kill if exists |5960**Key insight**: Must-Haves degrade over time (today's delighter is tomorrow's must-have). Re-evaluate quarterly.6162## Sprint Planning Process6364### Pre-Sprint (Week Before)65661. **Backlog Refinement**: Size stories, review acceptance criteria, validate definition of done672. **Dependency Mapping**: Identify cross-team blockers. Resolve before sprint starts, not during683. **Capacity Assessment**: Calculate available person-days (subtract PTO, meetings, overhead at 15-20%)694. **Risk Identification**: Flag technical unknowns. Spike stories for anything with > 50% uncertainty705. **Stakeholder Alignment**: Confirm priorities have not shifted. Get explicit sign-off7172### Sprint Planning (Day 1)73741. **Sprint Goal**: One clear, measurable objective. "Ship X so that Y users can Z" format752. **Story Selection**: Pull from ranked backlog up to capacity minus 15% buffer763. **Task Breakdown**: Each story broken into tasks with individual estimates and skill matching774. **Definition of Done**: Quality bar explicit -- includes tests, docs, review, deployment785. **Team Commitment**: Collective agreement on deliverables. Not assigned top-down7980### Execution Support8182- **Daily standups**: 15 min. Three questions: done, doing, blocked. Solve blockers offline83- **Mid-sprint check**: Day 3-4. If burndown is off track, cut scope (do not extend time)84- **Stakeholder updates**: Proactive, not reactive. Share progress before they ask8586## Capacity Planning8788### Velocity Calculation8990- Use 6-sprint rolling average (not last sprint, not best sprint)91- Adjust for team composition changes: new member = 50% velocity for first sprint92- Overhead factor: subtract 15-20% from raw capacity for meetings, reviews, support93- Uncertainty buffer: 10-15% for stable teams, 20-25% for new teams or new domains9495### Capacity Formula9697```98Available capacity = (team_size x working_days x hours_per_day)99 x (1 - overhead_factor)100 x (1 - uncertainty_buffer)101```102103### Load Balancing Rules104105- No individual above 85% utilization (burnout prevention)106- Each story has a primary and secondary owner (bus factor)107- Distribute complexity evenly -- do not stack all hard stories on one person108- Include one stretch assignment per sprint for growth109110## Sprint Anti-Patterns111112| Anti-Pattern | Symptom | Fix |113|-------------|---------|-----|114| Scope creep | Stories added mid-sprint | Strict change management: new work goes to next sprint |115| Carryover debt | Same stories roll 3+ sprints | Re-estimate, break down further, or kill |116| No slack | 100% capacity committed | Always keep 15% buffer for emergent work |117| Hero dependency | One person owns 60%+ of points | Redistribute, pair program, cross-train |118| Velocity inflation | Points increase but output does not | Calibrate against delivered value, not story counts |119120## Success Metrics121122| Metric | Target | What It Tells You |123|--------|--------|-------------------|124| Sprint completion rate | 90%+ committed points delivered | Planning accuracy |125| Velocity variance | < 15% sprint-to-sprint | Team stability and predictability |126| Carryover rate | < 10% of committed stories | Estimation and scoping quality |127| Cycle time | Trending downward | Process efficiency |128| Feature success rate | 80%+ meet predefined success criteria | Prioritization quality |129| Tech debt ratio | < 20% of sprint capacity | Long-term code health |130131## StartupAI Integration Points132133- **sprint-agent EF**: Generates 24 validation tasks (4 per sprint x 6 sprints) using RICE scoring for prioritization. Kano classification determines must-have vs delighter tasks134- **Composer Group D**: Next steps in validator reports are prioritized using Value vs Effort matrix (Quick Wins first, Big Bets phased)135- **Sprint Board UI**: KanbanBoard uses capacity planning formulas for load indicators, velocity calculation for sprint health136- **Validator scoring**: Execution dimension evaluates whether the startup has a credible sprint plan with realistic capacity estimates
amo-tech-ai