Sprint Planning with Real Capacity
Build a sprint commitment that fits: capacity from real availability, forecast from recent sprints, carryover first, one sprint goal.
Before & after
Same prompt, same agent — the only difference is the skill.
A 2-week sprint with a team of 6 is a good size. You'll want to think about what your key priorities are, how much work you can realistically fit, and making sure everyone has clear tasks. It's helpful to do some estimation so you know your team's capacity. You might want to reserve some time for bugs or tech debt. Communication is important—maybe a daily standup keeps everyone aligned. You'll probably want to review the sprint at the end to see how you did. Identifying blockers early helps. It really depends on your current project status and what the business needs most. What are the main things you're trying to ship in the next sprint?
SPRINT BACKLOG (2 weeks, 6 devs, 8 SP/dev = 48 SP total capacity) PRIORITY 1: Authentication redesign (product request, shifts launch) • User profile SSO integration: 5 SP → assigned to dev1, dev2 (pairs on first 3 days) • OAuth token refresh logic: 3 SP → dev3 • Logout clear sessions endpoint: 2 SP → dev4 SUBTOTAL: 10 SP PRIORITY 2: Performance regression fix (blocking enterprise trial) • DB query optimization (reports page): 5 SP → dev5 (SQL + testing) • Caching layer implementation: 5 SP → dev6 SUBTOTAL: 10 SP PRIORITY 3: Tech debt & bugs (reserve 20% sprint) • Flaky test suite: 3 SP → dev1 (after SSO) • Dependency security updates: 2 SP → rotating owner, 30min daily SUBTOTAL: 5 SP BUFFER & CARRYOVER: 18 SP (37% reserve for shifting asks) KNOWN RISKS • OAuth provider API changes mid-sprint → mitigate with mock server • Reports data volume test may reveal new bottleneck → escalate immediately VALIDATION: Standup daily 10am, blockers tracked in shared log. Friday retro: compare estimate to actual per person.
About this skill
Stop overcommitting. This planner turns your backlog and your team's real availability into a sprint commitment the team can keep, with the arithmetic shown so the tradeoffs are clear to stakeholders.
What it does
- Computes capacity from actual days: time off, holidays, on-call, and a realistic focus factor
- Forecasts from the average of recent sprints and counts carryover first
- Writes one outcome-based sprint goal and puts goal-path items in first
- Checks readiness, splits oversized items, and keeps unconfirmed dependencies out
- Produces a committed list, a stretch list, and what is explicitly out
What you get
A sprint plan proposal: capacity and forecast math, committed and stretch lists with readiness and dependencies, exclusions, and risks.
Best for
Scrum masters, product owners, and team leads preparing sprint planning.
SKILL.md preview
---
name: sprint-planning-capacity
description: Turn a prioritized backlog and the team's real availability into a sprint commitment that fits - capacity from actual days (time off, holidays, on-call, meetings), a forecast from recent sprints rather than wishful velocity, carryover counted first, one clear sprint goal, readiness and dependency checks, and a committed list plus a stretch list. Use before a sprint starts when someone says "plan the next sprint", "how much can we take on?", "what fits in two weeks?", "build the sprint from this backlog", "we keep overcommitting", or "sprint planning prep".
---
# Sprint Planning with Real Capacity
… (sign up to view the full skill)More business & ops skills
View all Business & Ops skills →Product Practice Diagnostic
Trace a product-team symptom (unused features, roadmap churn, priority fights) to the broken stage of the loop and fix one thing first.
Feature Launch Go-to-Market Plan
Plan one feature launch: tier, plan access, audience messages, readiness gates for support, sales, billing, and docs, and success metrics.
Pricing Tier and Packaging Diagnosis
Finds why your pricing tiers underperform and redesigns value metric, fences, price gaps, and upgrade triggers with a migration plan.
Product Specs, Roadmaps, and Research Decisions
Turn customer evidence into testable PRDs, dependency-aware roadmaps, and stakeholder updates with clear decisions and tradeoffs.