Build Your Engineering Capacity Agent

The short version

The Engineering Capacity agent runs Monday at 8 AM and tells you whether the next four weeks of roadmap actually fit in available capacity. It pulls from Jira (assigned work, story points, sprint completion), GitHub (PR throughput), and Google Calendar (PTO and leave), then computes net available capacity per engineer and per team after subtracting PTO, on-call, meetings, and ramp-up. The output flags overloaded engineers, over-capacity teams, understaffed critical projects, and PTO that creates coverage gaps weeks before they hit. The math is explicit: if assigned > capacity, you're behind before the sprint starts. Run it on your current sprint this Monday and check if you're already at 130%.

Your roadmap says you're shipping Feature X in April. Your engineering team has 120 committed story points for April. Capacity analysis shows the team has 140 story points available. Looks good, right?

Except you didn't account for:

• Sarah is taking a week off mid-April (capacity: -40 points)
• The infrastructure team needs engineering time to migrate databases (15% of capacity)
• Two critical bugs landed yesterday and need investigation (10 points)
• Someone needs to do the on-call rotation (5% of capacity)

Now you actually have 100 story points available and 120 committed. You're over capacity and nobody flagged it until you're already in April scrambling.

This is the problem the Engineering Capacity Agent solves.

The Real Problem (It's Not Sprint Planning, It's Forecasting)

Every engineering team does sprint planning. You estimate work. You assign people. You hit the sprint or you don't. But sprint planning is reactive. By the time you're planning sprint 1, you're already committing to deadlines you can't hit because you didn't account for:

• PTO/leave that reduces capacity
• Cross-team dependencies (infrastructure, security, compliance)
• Unplanned work (critical bugs, escalations, interrupts)
• Ramp-up time for new projects
• Tech debt and refactoring work

Without forecasting, what happens:

Week 1: You commit to Q2 roadmap. 8 features, 320 story points. 3 engineers, 40 points per week each, ~13 weeks. Looks achievable.

Mid-week: An engineer tells you she's taking two weeks off. Capacity just dropped 80 points. Nobody on the roadmap planning team knew.

Following week: A critical database scaling issue emerges. Engineering needs to spend 2 weeks on infrastructure work. That wasn't on the roadmap. Your Gantt chart is already wrong.

Mid-April: You're only halfway through Feature 1 because you hit unexpected bugs. You realize you're 4 weeks behind. Your CEO is asking why. You don't have a good answer because you never actually understood your capacity.

The Engineering Capacity Agent prevents this. Every week, it analyzes your team's available bandwidth against committed work and tells you whether you're ahead, on track, or in trouble.

What This Agent Does

Every Monday at 8am, the agent delivers a capacity report that answers: Do we have enough people and time to hit the roadmap? Where are the bottlenecks?

It reads your Jira backlog, your team roster with specialties, the PTO calendar, and the roadmap, then tells you exactly where you have capacity problems.

Overloaded Engineers

Engineers who have more work assigned than they can realistically complete:

Sarah (Backend)

• Assigned: 45 story points this sprint (capacity: 30 points)
• Over by: 15 points (150% capacity)
• Current work: Feature X (25 points) + Bug investigation (20 points)
• PTO coming up: 1 week in 2 weeks (40 hours lost)
• Blocker: Waiting on infrastructure team for database design
• Action: De-assign 15 points. Check if blocker can be unblocked.

Mark (Frontend)

• Assigned: 38 story points this sprint (capacity: 32 points)
• Over by: 6 points (119% capacity)
• Current work: UI redesign (22 points) + Bug fixes (16 points)
• PTO: None scheduled
• Blocker: Waiting on design review before proceeding
• Action: De-assign 6 points or accelerate design review

Teams Over Capacity

Cross-team capacity problems:

Infrastructure Team

• Capacity: 80 story points (4 engineers × 20 points each)
• Committed work: 100 story points
  • Database migration: 40 points
  • Kubernetes upgrade: 35 points
  • Monitoring improvements: 25 points
• Over capacity: By 20 points (125%)
• PTO: 1 engineer out 2 weeks (20-point capacity hit in April)
• Risk: Critical. Database migration is blocking 3 product teams.
• Action: Prioritize migration. Push monitoring work to Q3. Bring in help if available.

Mobile Team

• Capacity: 60 story points (3 engineers × 20 points each)
• Committed work: 50 story points
• Headroom: 10 points (83% utilized)
• No PTO scheduled this month
• Risk: LOW. On track.
• Action: Can take 10 more points if roadmap priority shifts.

Critical Projects with Insufficient Staffing

Projects that need more people than you've allocated:

Project: API Redesign (Critical for platform customers)

• Estimated size: 200 story points
• Timeline needed: 10 weeks (to ship by June 30)
• Required capacity: 20 points/week
• Allocated: 1 senior engineer (15 points/week)
• Shortfall: 5 points/week
• Risk: HIGH. Will slip if not staffed adequately.
• Action: Allocate second engineer or extend timeline to 13 weeks (ship mid-July)

Project: Mobile Redesign (Nice to have, not critical)

• Estimated size: 150 story points
• Timeline needed: 8 weeks (ship end of May)
• Required capacity: 18.75 points/week
• Allocated: 2 engineers (35 points/week available if focused)
• Risk: LOW. Over-staffed.
• Action: On track. Could accelerate if needed.

Upcoming PTO That Creates Coverage Gaps

Leave coming up that affects capacity:

April

• Sarah: 1 week (April 14-18) - -40 capacity
• Mark: 2 weeks (April 7-21) - -40 capacity
• Tom: 1 week (April 28-May 2) - -40 capacity
• Total capacity loss: -120 points in April
• April roadmap: 140 committed points
• Adjusted capacity: 140 - 120 = 20 points available in April
• Risk: CRITICAL. April is severely under-capacity.
• Action: Move non-critical work to May. Confirm critical work has coverage.

May

• No major PTO scheduled
• Capacity: 160 points (if everyone returns)
• Committed: 160 points
• Utilization: 100%
• Risk: No buffer for unplanned work
• Action: Leave 10-15% buffer for bugs/escalations

Capacity vs. Commitment Forecast (Next 2-4 Weeks)

Week-by-week breakdown showing when you'll run into problems:

Week of April 1:
- Available capacity: 100 points (team at 80% due to Mark's PTO)
- Committed work: 80 points
- Headroom: 20 points ✅

Week of April 8:
- Available capacity: 60 points (Mark + Sarah out)
- Committed work: 120 points
- Shortfall: -60 points 🚨 CRITICAL

Week of April 15:
- Available capacity: 80 points (only Sarah out)
- Committed work: 100 points
- Shortfall: -20 points ⚠️ AT RISK

Week of April 22:
- Available capacity: 140 points (everyone back)
- Committed work: 80 points
- Headroom: 60 points ✅

FORECAST: April 8-15 is critical. Cannot hit roadmap without deprioritization or scope reduction.

Recommended Rebalancing Actions

Based on capacity analysis, specific recommendations:

Action 1: Reduce April scope

• Move Feature X to May (30 points)
• Move non-critical bug fixes to Q2 backlog (20 points)
• This reduces April from 140 to 90 points, matching available capacity

Action 2: Redistribute workload

• Sarah is at 150% capacity. De-assign 15 points to Mark (if he has headroom after Mark's PTO)
• Or defer Sarah's work to May

Action 3: Extend timeline

• API redesign is critical but understaffed. Either allocate second engineer or slip from June 30 to July 15

Action 4: Bring in help

• Database migration is blocking 3 teams. Bring in contract engineer or senior from product team to unblock sooner

How It Works: The Capacity Logic

The agent doesn't use guessing. It uses explicit calculations:

Step 1: Calculate available capacity per engineer

• Base capacity: 32 hours/week × 4 weeks = 128 hours/month
• Subtract: PTO, on-call, internal meetings (10-15%), project ramp-up
• Net capacity: ~80-100 hours/month per engineer, or 20-25 story points (assuming 4-5 points = 1 day)

Step 2: Get assigned work

• Pull Jira issues assigned to engineer
• Sum story points
• Compare to available capacity
• If assigned > capacity: Engineer is overloaded

Step 3: Identify blockers

• Is assigned work blocked by dependencies?
• If yes, is the blocker on the critical path?
• If yes and blocker is stuck, engineer's "real" capacity is reduced

Step 4: Team-level analysis

• Sum capacity across team
• Sum committed work across team
• If committed > capacity: Team is over-capacity
• Break down by project to identify specific problem areas

Step 5: Forecast

• Look ahead 4 weeks
• For each week, subtract PTO
• Recalculate available capacity per week
• If any week shows shortfall, flag it

Step 6: Recommend rebalancing

• What work can be deferred?
• What can be de-scoped?
• What needs more people?
• Recommend specific actions

Why This Actually Works

I built this because we consistently missed roadmap dates and I didn't understand why. We'd commit to 8 features for Q2. By mid-April, we were 30% done. We'd blame engineering for being slow. But the real problem was we'd committed 320 points of work to a team with 240 points of capacity (after PTO, bugs, and interrupts).

The Engineering Capacity Agent catches three things you'd normally miss:

The hidden PTO problem: You commit to a roadmap in January. You don't account for the week of vacation that happens in March. By the time you realize it, you're already behind. The agent flags PTO 4 weeks in advance so you can replan.

The understaffed critical project: API redesign is critical but only one person is on it. That person is also over-capacity on other work. By the time you realize the project will slip, it's too late to staff it properly. The agent surfaces this in week 1, not week 8.

The accumulation of unplanned work: You plan for 120 points of feature work. But 20 points of critical bugs land. 10 points of tech debt needs doing. 15 points of infrastructure work touches your team. Now you're 125 points over. The agent tracks this in real-time.

Data sources and setup

Prerequisites: Complete the Claude setup guide first. This agent needs the following MCP connections active:

• GitHub - reads PR throughput, merge frequency, and code metrics
• Jira - reads sprint completion rate, story points, and burndown
• Google Calendar - reads PTO and leave to adjust capacity calculations

Schedule: Runs Monday at 8:00 AM weekly via cron. Output emails to engineering leadership.

Quick test: Open Claude and ask: "Show me this week's engineering capacity: PR throughput, sprint completion rate, bug-to-feature ratio, and any burnout signals."

For the full agent fleet and scheduling details, see Your AI Agent Fleet.

What Good Looks Like

After running this agent for one month:

Week 1: You realize you're way over-committed. The team is at 130% capacity and you didn't even know it. You immediately de-scope non-critical work. Morale improves because engineers aren't drowning.

Week 2: You catch PTO that would have caused a shortage. You move Feature X to the following month. You tell the PM team why, with data. They accept it because the numbers are clear.

Week 3: A critical bug lands (15 points). You look at the capacity report. You see Sarah is the only one who can fix it. Instead of just assigning it, you de-assign 15 points of her other work first. She stays at sustainable capacity.

Week 4: You're planning Q2 roadmap. Instead of committing optimistically, you plan based on real available capacity. You commit to 200 points instead of 280. You actually hit the plan because you planned realistically.

The Full Agent Prompt

Ready to build this? The complete agent instruction file is available at /artifacts/agent-engineering-capacity.md. It includes:

• Capacity calculation rules
• Blocker detection
• Forecasting logic
• Team-level analysis
• Output format
• Complete test prompt to validate

Copy it into your agent platform, connect Jira and your PTO calendar, and run it. Setup takes 30 minutes. It prevents costly roadmap misses.

Final Thought

Every PM wants to know: "Can we ship this?" You can't answer that question by looking at the feature scope. You have to look at capacity.

Do you have enough engineers to build it? Do you have the right specialists (backend, mobile, infra)? Will anyone be on vacation? Is there buffer for bugs?

The Engineering Capacity Agent answers those questions every week. It tells you exactly when you're over-committed before you're already behind.

Your roadmap won't change. Your team size won't change. But your ability to forecast what you can actually ship will improve dramatically.

Ready to build? Start with the full agent prompt at /artifacts/agent-engineering-capacity.md. Copy-paste-ready, includes all capacity logic, forecasting rules, and a test prompt.