Sprint Prioritization

Triggers

• sprint planning
• sprint prioritization
• backlog prioritization
• feature prioritization
• RICE framework
• MoSCoW prioritization
• Kano model
• velocity analysis
• capacity planning
• resource allocation
• story points
• sprint goal
• agile planning
• scope creep
• technical debt
• release planning

Instructions

When activated, help teams plan sprints, prioritize features, and allocate resources using data-driven frameworks.

Prioritization Frameworks

RICE Framework

• Reach: Number of users impacted per time period with confidence intervals.
• Impact: Contribution to business goals (scale 0.25-3) with evidence-based scoring.
• Confidence: Certainty in estimates (percentage) with validation methodology.
• Effort: Development time in person-months with buffer analysis.
• Score: (Reach x Impact x Confidence) / Effort with sensitivity analysis.

Value vs. Effort Matrix

• High Value, Low Effort: Quick wins -- prioritize first.
• High Value, High Effort: Major projects -- strategic investments with phased approach.
• Low Value, Low Effort: Fill-ins -- use for capacity balancing.
• Low Value, High Effort: Time sinks -- avoid or redesign.

Kano Model Classification

• Must-Have: Basic expectations (dissatisfaction if missing).
• Performance: Linear satisfaction improvement.
• Delighters: Unexpected features that create excitement.
• Indifferent: Features users don't care about.
• Reverse: Features that actually decrease satisfaction.

Sprint Planning Process

Pre-Sprint Planning

1. Backlog Refinement: Story sizing, acceptance criteria review, definition of done validation.
2. Dependency Analysis: Cross-team coordination requirements with timeline mapping.
3. Capacity Assessment: Team availability, vacation, meetings, training with adjustment factors.
4. Risk Identification: Technical unknowns, external dependencies with mitigation strategies.
5. Stakeholder Review: Priority validation and scope alignment.

Sprint Planning Day

1. Sprint Goal Definition: Clear, measurable objective with success criteria.
2. Story Selection: Capacity-based commitment with 15% buffer for uncertainty.
3. Task Breakdown: Implementation planning with estimates and skill matching.
4. Definition of Done: Quality criteria and acceptance testing.
5. Commitment: Team agreement on deliverables and timeline.

Capacity Planning

• Use 6-sprint rolling average for velocity with trend analysis and seasonality adjustment.
• Account for vacation, training, meeting overhead (typically 15-20%).
• Maintain uncertainty buffer (10-15% for stable teams).
• Match developer expertise to story requirements.
• Balance work complexity to prevent burnout.

Execution Support

• Use goal_create to track sprint goals and milestones.
• Use knowledge_write to document velocity data and retrospective learnings.
• Daily blocker identification with escalation paths.
• Mid-sprint progress assessment and scope adjustment.

Deliverables

Sprint Dashboards

• Real-time progress, burndown charts, velocity trends with predictive analytics.

Reporting

• Executive summaries with business impact.
• Release notes with user-facing feature descriptions.
• Retrospective reports with action item follow-up.

Risk Management

• Risk scoring via Probability x Impact matrix.
• Contingency planning with alternative approaches.
• Early warning systems with metrics-based alerts.

Success Metrics

• Sprint Completion: 90%+ of committed story points delivered consistently.
• Stakeholder Satisfaction: 4.5/5 rating for priority decisions and communication.
• Delivery Predictability: +/-10% variance from estimated timelines with trend improvement.
• Team Velocity: <15% sprint-to-sprint variation with upward trend.
• Feature Success: 80% of prioritized features meet predefined success criteria.
• Cycle Time: 20% improvement in feature delivery speed year-over-year.
• Technical Debt: Maintained below 20% of total sprint capacity.
• Dependency Resolution: 95% resolved before sprint start.

Verify

• The deliverable for this phase exists as a concrete artifact (doc, ticket, board, repo) and its location is shared, not described
• Each commitment has an owner name, a due date, and a definition-of-done that someone other than the author could check
• Risks are listed with likelihood/impact and a named mitigation, not as a generic 'risks: TBD' bullet
• Dependencies on other teams/vendors/agents are explicit; an ack from each dependency is recorded or marked 'pending'
• Success criteria for the next phase are numeric or otherwise objectively testable
• A rollback / kill-switch / 'we will stop if X' criterion is written down before work starts