Назад към всички

afrexai-sprint-planner

// Plan, scope, and run agile sprints that actually ship. No ceremony bloat.

$ git log --oneline --stat
stars:1,933
forks:367
updated:March 4, 2026
SKILL.mdreadonly

Sprint Planner

Plan, scope, and run agile sprints that actually ship. No ceremony bloat.

What It Does

Takes your backlog (or a rough list of tasks) and produces a sprint plan with:

  • Capacity math (team size × available days × focus factor)
  • Story point allocation with buffer
  • Sprint goal + success criteria
  • Daily standup template
  • Retro prompts tied to metrics

Usage

Tell your agent: "Plan a 2-week sprint for [team/project]" with:

  • Team size and availability
  • Backlog items (paste or describe them)
  • Any hard deadlines or dependencies

Sprint Planning Framework

1. Capacity Calculation

Available hours = team_size × sprint_days × hours_per_day × focus_factor
focus_factor = 0.7 (accounts for meetings, interrupts, context switching)

2. Backlog Prioritization (RICE)

Score each item:

  • Reach: How many users/processes does this affect? (1-10)
  • Impact: How much does it move the needle? (0.25, 0.5, 1, 2, 3)
  • Confidence: How sure are you about estimates? (0.5, 0.8, 1.0)
  • Effort: Person-days to complete

RICE Score = (Reach × Impact × Confidence) / Effort

Sort descending. Fill sprint capacity from top.

3. Sprint Goal

One sentence. Measurable. Example: "Ship user onboarding flow — 80% of new signups complete setup within 48 hours."

4. Buffer Rule

Reserve 20% capacity for unplanned work. If you're filling 100% of capacity, you're already behind.

5. Definition of Done

Every item needs:

  • Code reviewed and merged
  • Tests passing
  • Deployed to staging
  • Product owner sign-off

6. Daily Standup (async-friendly)

Each person posts:

  1. What I shipped yesterday
  2. What I'm shipping today
  3. What's blocking me (if anything)

Skip "what I worked on" — focus on shipped output.

7. Sprint Retro (15 min max)

  • Velocity: Planned points vs completed points
  • Carry-over: What didn't get done and why?
  • One thing to change: Pick ONE process improvement. Not five.

8. Anti-Patterns to Flag

  • Sprint scope changed mid-sprint more than once
  • No items completed until final 2 days
  • Carry-over exceeds 30% of planned work
  • Standup takes more than 10 minutes

Output Format

# Sprint [N] Plan — [Start Date] to [End Date]

## Sprint Goal
[One sentence]

## Team Capacity
- Team: [N] engineers × [D] days × 0.7 focus = [H] available hours
- Buffer: 20% ([B] hours reserved)
- Committable: [C] hours

## Committed Items
| # | Item | Points | Owner | RICE | Status |
|---|------|--------|-------|------|--------|
| 1 | ...  | ...    | ...   | ...  | To Do  |

## Stretch Goals (if capacity allows)
| # | Item | Points |
|---|------|--------|

## Risks & Dependencies
- ...

## Success Criteria
- [ ] Sprint goal met
- [ ] Velocity within 15% of target
- [ ] Zero critical bugs introduced

Why This Works

Most sprint planning fails because teams skip capacity math and overcommit. This framework forces honest numbers first, then fills from a prioritized backlog. The 20% buffer isn't laziness — it's how you actually hit your commitments.

Built by AfrexAI — AI context packs for business teams. Get the full SaaS Context Pack ($47) for sprint planning, roadmap templates, and 40+ agent-ready frameworks.