How to Run Sprint Planning with Capacity Estimation and Story Selection in pm-skills

You can run sprint planning with capacity estimation and story selection by using the /sprint plan command or invoking the sprint-plan skill directly, which calculates team capacity with a 15-20% buffer and selects stories from a prioritized backlog until the capacity ceiling is reached.

The pm-skills repository provides an AI-assisted marketplace for product management workflows, offering a structured approach to sprint planning through dedicated skills and slash commands. This system separates domain logic from user interaction, allowing you to run sprint planning with capacity estimation and story selection either interactively or programmatically. The methodology follows a skill-first architecture where the sprint-plan skill contains the core logic while the /sprint command handles the interface layer.

Understanding the Sprint Planning Architecture

The pm-skills implementation relies on two distinct components that work together to deliver consistent, repeatable sprint planning sessions.

The sprint-plan Skill

The sprint-plan skill defines the step-by-step methodology for estimating capacity, selecting stories, mapping dependencies, and surfacing risks. Located at pm-execution/skills/sprint-plan/SKILL.md, this file provides a structured checklist and markdown template that the AI fills based on your inputs, including backlog data, velocity reports, and team rosters. Because the skill is written as a markdown document with front-matter, any compatible LLM can execute the exact same procedure every time, eliminating human bias from the planning process.

The /sprint Command

The /sprint command serves as the user-facing entry point that orchestrates the skill in "plan" mode. Found in pm-execution/commands/sprint.md, this slash command captures context through interactive prompts, handles file attachments like CSV backlogs or team calendars, and returns a ready-to-share sprint plan markdown. The command supports three modes—plan, retro, and release-notes—making it a thin wrapper that provides convenient CLI-style access while the skill handles the heavy lifting of capacity calculations.

Step-by-Step Capacity Estimation and Story Selection

When you run sprint planning with capacity estimation and story selection, the system executes a six-step procedure defined in the sprint-plan skill.

Step 1: Context Gathering

The process begins by collecting essential inputs. The /sprint plan command asks you to provide or upload your current backlog in CSV or markdown format, the team roster with PTO and meeting hour allocations, and the last three sprints' velocity data. This context gathering phase ensures the AI has complete visibility into available resources and historical performance before making calculations.

Step 2: Capacity Calculation

The skill calculates realistic capacity using three data points. First, it determines available hours per team member based on the sprint duration and individual calendars. Second, it establishes a baseline capacity using historical velocity—the average story points completed across the previous three sprints. Finally, it applies a 15-20% buffer to account for bugs, tech debt, and unexpected interruptions, producing a final capacity value that prevents overcommitment.

Step 3: Story Selection

Stories are drawn from the prioritized backlog and filtered by the Definition of Ready criteria. The skill adds items to the sprint incrementally until the capacity ceiling is reached, ensuring the team only commits to work that is properly scoped and ready for development. This selection process respects dependencies and maintains a sustainable workload based on the calculated capacity.

Step 4: Dependency Mapping and Risk Identification

Before finalizing the plan, the skill flags internal and external blockers, builds a critical-path order for story implementation, and surfaces high-uncertainty items with suggested mitigations. This step ensures that complex technical requirements or waiting dependencies are visible before the sprint begins, allowing the team to schedule spikes or coordination meetings proactively.

Practical Implementation Examples

You can invoke the sprint planning workflow through two primary methods depending on your environment and automation needs.

Using the /sprint Command

For interactive sessions in Claude Code or compatible environments, use the slash command syntax:

/sprint plan 2-week sprint, 5 engineers, focus on checkout improvements

The model then requests your backlog, team availability, and velocity history before executing the sprint-plan skill. It returns a markdown document similar to this output:

## Sprint Plan: Checkout Improvement Sprint

**Duration**: 2026-07-01 – 2026-07-14  
**Sprint Goal**: Reduce checkout abandonment by 15%.

| Member | Available Days | Points | Notes |
|--------|----------------|--------|-------|
| Alice  | 8              | 16     | – |
| Bob    | 8              | 16     | On-call 1 day |
| Carol  | 9              | 18     | – |

**Total capacity**: 80 points  
**Recommended commitment**: 64 points (20% buffer)

### Selected Stories

| # | Story | Points | Owner | Dependencies | Risk |

|---|-------|--------|-------|--------------|------|
| 1 | Reduce payment API latency | 8 | Alice | – | High technical complexity |
| 2 | Add one-click purchase button | 5 | Bob | Story 1 | UI design pending |
| 3 | Implement retry logic | 3 | Carol | – | – |

### Sprint Risks

- Payment API latency may require backend refactor → schedule a spike early in the sprint.
- UI design not finalized → coordinate with design on day 2.

Invoking the Skill Programmatically

For integration into CI/CD pipelines or custom tooling, call the skill directly via a hypothetical client:

from claude import ClaudeClient

client = ClaudeClient()
prompt = """
Run the sprint-plan skill for a 2-week sprint with:
- Team: 4 engineers (Alice, Bob, Carol, Dave)
- Availability: each 8 days, Alice 1 day on-call, Bob 0.5 day PTO
- Historical velocity: 30, 28, 32 points
- Backlog items (title, points, owner):
  1. "Checkout flow redesign", 12, Alice
  2. "Payment API retry logic", 8, Bob
  3. "Discount code UI", 5, Carol
  4. "Analytics event tagging", 3, Dave
"""

result = client.run_skill("sprint-plan", prompt)
print(result.markdown)

This programmatic approach feeds raw values directly into the skill without interactive prompting, returning the same structured markdown output suitable for automated documentation or Jira integration.

Integration with Retrospectives

After completing the sprint, you can seamlessly transition to retrospective analysis using the related command:

/sprint retro [paste sprint metrics and team feedback]

The retro command automatically references the previous sprint plan markdown to surface unmet commitments and variance analysis, creating a closed loop between planning and reflection.

Summary

• The sprint-plan skill at pm-execution/skills/sprint-plan/SKILL.md contains the core methodology for capacity calculation and story selection, while the /sprint command at pm-execution/commands/sprint.md provides the user interface.
• Capacity estimation combines team availability, historical velocity averages, and a mandatory 15-20% buffer to prevent overcommitment.
• Story selection draws from the prioritized backlog, filters by Definition of Ready, and stops when the capacity ceiling is reached.
• The system outputs a complete markdown sprint plan including capacity tables, selected stories with dependencies, and a risk mitigation list.
• You can trigger the workflow interactively via /sprint plan or programmatically by calling the skill directly for integration into automated pipelines.

Frequently Asked Questions

How does the capacity buffer calculation work?

The skill automatically deducts 15-20% from your baseline velocity capacity to account for unexpected bugs, technical debt escalation, and unplanned interruptions. This buffer is applied after calculating the raw capacity from historical velocity data, ensuring the team commits to a realistic workload that accommodates typical sprint disruptions.

Can I customize the Definition of Ready criteria?

Yes, because the sprint-plan skill is implemented as a markdown file at pm-execution/skills/sprint-plan/SKILL.md, you can modify the story vetting criteria directly in the source. The skill references this definition when filtering the backlog during the selection phase, allowing teams to add requirements like "has acceptance criteria" or "security review completed" to match their specific workflow standards.

What file formats does the /sprint command accept for backlog data?

The /sprint command accepts backlogs in CSV or markdown formats. When you invoke /sprint plan, the system prompts you to paste the content directly or upload files containing your backlog items, velocity reports, and team roster information, making it compatible with exports from Jira, Azure DevOps, or simple spreadsheet tools.

How does the skill handle dependencies between stories?

During the dependency mapping phase, the skill analyzes your backlog for internal blockers (stories that require other sprint items) and external dependencies (third-party APIs, design approvals, etc.). It builds a critical-path order for implementation and flags these dependencies in the output table with specific risk mitigations, such as scheduling technical spikes or coordinating with external teams early in the sprint.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}