Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From jira
Deep-dive into team capacity calculations, velocity tracking, and sprint health analysis. Use when analyzing velocity trends, calculating detailed capacity adjustments, or diagnosing sprint anti-patterns.
npx claudepluginhub ramirez-justin/claude-plugins --plugin jiraHow this skill is triggered — by the user, by Claude, or both
Slash command
/jira:capacity-analysisThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Advanced techniques for capacity planning, velocity analysis, and sprint health diagnostics.
Analyzes sprint velocity data to produce team health reports with delivery trends, capacity utilization, and improvement recommendations. Responds to queries about sprint velocity, team delivery health, risks, or retrospective data analysis.
Track and interpret sprint velocity to forecast capacity, identify bottlenecks, and improve planning accuracy. Use when analyzing team productivity trends.
Recommends sprint scope by pulling backlog from Jira/Linear MCP or manual input, calculating team capacity from velocity and availability, and suggesting committed work, stretch goals, and deferred items.
Share bugs, ideas, or general feedback.
Advanced techniques for capacity planning, velocity analysis, and sprint health diagnostics.
For basic sprint planning: See the Sprint Planning Assistant skill.
Base Hours = Team Size × Sprint Days × Hours/Day
Actual = Base - (PTO + Meetings + Support Rotation + Buffer)
Team: 6 developers
Sprint: 10 work days
Work: 6 hours/day (accounting for meetings)
PTO: 1 person out 3 days
Training: 2 people × 2 days
On-call: 1 person at 80% capacity
Buffer: 10%
Base capacity: 45 points (historical velocity)
Adjustments:
- PTO: 3 days / 10 days × (1/6 team) = -7.5% → -3.4 pts
- Training: 4 person-days / 60 total = -6.7% → -3 pts
- On-call: 20% of 1/6 team = -3.3% → -1.5 pts
- Buffer: -10% → -4.5 pts
Sprint capacity: 45 - 3.4 - 3 - 1.5 - 4.5 ≈ 33 points
Percentage of time on sprint work:
| Team Type | Focus Factor |
|---|---|
| New team | 50-60% |
| Typical team | 60-70% |
| High performing | 70-80% |
Method 1: Simple Average (last 3 sprints)
Sprints: 38, 42, 44 points
Velocity = (38 + 42 + 44) / 3 = 41 points
Method 2: Weighted Average (recent sprints count more)
Velocity = (Sprint_N × 3 + Sprint_N-1 × 2 + Sprint_N-2 × 1) / 6
Example: (44 × 3 + 42 × 2 + 38 × 1) / 6 = 42 points
| Trend | Meaning | Action |
|---|---|---|
| Increasing | Team maturing, processes improving | Gradually increase commitments |
| Stable | Consistent, predictable | Use as reliable planning baseline |
| Decreasing | Technical debt? Team changes? | Investigate root causes |
| Erratic | Inconsistent sizing or scope changes | Improve estimation practices |
Use velocity for planning, not capacity. Velocity accounts for real-world factors.
Sprint burndown data:
sprint = "Sprint 42" AND status IN ("In Progress", "To Do")
Carry-over issues:
sprint WAS "Sprint 42" AND sprint = "Sprint 43" AND resolution IS EMPTY
Blocked issues:
sprint in openSprints() AND status = "Blocked"
Loading 60 points when velocity is 40.
Symptoms: Incomplete sprints, stressed team, quality issues
Fix: Use historical velocity, add 10% buffer, track carry-over rate
Loading 20 points when velocity is 40 to "guarantee" completion.
Symptoms: Team finishing early, stakeholders frustrated
Fix: Commit to realistic amount, have stretch goals ready
Just a collection of random stories.
Symptoms: Lack of focus, unclear priorities, no cohesion
Fix: Define clear objective that ties stories together
Constantly splitting stories after sprint starts.
Symptoms: Scope creep, unclear definition of done
Fix: Better grooming and estimation up front
Starting blocked work.
Symptoms: Context switching, idle time, frustration
Fix: Map dependencies during planning, start unblocked work first
Adding unplanned features during implementation.
Symptoms: Stories take longer, scope creep
Fix: Stick to acceptance criteria, capture new ideas as separate stories
| Metric | Healthy Range | Warning Sign |
|---|---|---|
| Carry-over rate | < 10% | > 20% |
| Velocity variance | ± 15% | > 30% |
| Blocked time | < 5% | > 15% |
| Stories completed | > 80% | < 60% |
| Story size variance | Low | High |
High carry-over diagnosis:
sprint = "Sprint 42" AND statusCategory != Done
ORDER BY "Story Points" DESC
Blocked items analysis:
sprint in openSprints() AND status CHANGED TO "Blocked"
ORDER BY updated DESC
Sprint Number: 43
Duration: Jan 15-28 (10 days)
Sprint Goal: Complete user profile functionality
TEAM CAPACITY
─────────────
Members: 6 developers
Availability:
- Alice: 10 days (full)
- Bob: 7 days (3 days PTO) → -5%
- Carol: 10 days (full)
- Dave: 10 days (on-call) → -3%
- Eve: 9 days (1 day training) → -2%
- Frank: 10 days (full)
Historical velocity: 45 points
Adjusted capacity: 36 points
SPRINT BACKLOG (36 points)
──────────────────────────
□ PROJ-101: User profile page (8 pts)
□ PROJ-102: Avatar upload (5 pts)
□ PROJ-103: Profile editing (8 pts)
□ PROJ-104: Privacy settings (5 pts)
□ PROJ-105: Completion badge (3 pts)
□ PROJ-106: Update navigation (2 pts)
□ PROJ-107: Profile tests (5 pts)
STRETCH GOALS
─────────────
○ PROJ-108: Social media links (5 pts)
○ PROJ-109: Custom themes (8 pts)
DEPENDENCIES & RISKS
────────────────────
Dependencies:
- PROJ-102 needs design review (due Jan 16)
- PROJ-104 needs security review
Risks:
- Avatar upload may need third-party service
- Privacy settings have regulatory requirements
Mitigation:
- Start PROJ-101, 103, 106 first
- Spike for avatar service options
For advanced capacity analysis, I will:
You: "Our velocity has been dropping. Sprint 40: 45pts, 41: 38pts, 42: 32pts. What's going on?"
Me: "I see a concerning 29% velocity decline over 3 sprints. Let me investigate.
[Queries sprint data]
Analysis:
Likely causes:
Recommendations:
Want me to find the specific blocked issues?"