Sprint capacity and portfolio capacity measure the same thing at two completely different levels of the organization. That gap creates a persistent coordination problem in any organization running agile teams inside a traditionally managed portfolio.
Sprint capacity is a team's ability to deliver work in a single iteration, usually two weeks. Portfolio capacity is the organization's ability to deliver a set of strategic investments over a planning horizon of quarters or years. Both matter. Neither one is sufficient on its own. And in most hybrid environments, the two are not connected at all.
What sprint capacity actually measures
Sprint capacity is typically expressed as story points or hours available for a sprint. A team of six people running at 80% utilization has roughly 192 hours of sprint capacity in a two-week sprint. In agile planning, teams pull work from a product backlog up to that capacity ceiling each sprint.
Sprint capacity is accurate because it reflects the actual state of the team right now: who is available this sprint, accounting for scheduled vacation, carryover from last sprint, and any known commitments outside the project. It is also short-horizon. It tells you what the team can do in the next 14 days, not what it can deliver over the next six months.
What portfolio capacity actually measures
Portfolio capacity is expressed in FTEs over a planning period: quarters or half-years. It tells the governance body how many people of which skills are available to take on strategic projects and at what level of commitment.
Portfolio capacity is approximate and long-horizon. It reflects expected team availability based on headcount and role allocations, not sprint-by-sprint actuals. It gives the governance body a planning surface to make approval decisions against, but it is an estimate, not a measurement.
Why the two do not naturally connect
The units are different. Story points are not FTEs. Sprint teams plan in two-week cycles. Portfolio managers plan in quarterly cycles. The people doing the planning are usually in different meetings, using different tools, and reporting to different stakeholders.
The result is a structural disconnect. A project may be allocated 2.0 FTEs at the portfolio level. But the sprint team running that project is averaging 40 story points per sprint when the original projection was 80. Nobody translated the gap. The portfolio still shows 2.0 FTEs committed. The actual throughput is closer to 0.8.
That gap shows up eventually as a missed milestone. By then, the project is three months behind and the cause is attributed to poor execution rather than a capacity assumption that was wrong from the start.
Converting sprint velocity to portfolio FTE capacity
The most reliable bridge between the two levels is to use historical sprint velocity as the portfolio capacity input rather than theoretical headcount.
The conversion works like this:
- Track the team's actual sprint velocity in hours over the last three to six sprints
- Calculate the average productive hours per sprint
- Multiply by the number of sprints in the planning period (six sprints per 13-week quarter)
- Divide by the net hours per FTE per quarter (roughly 390 to 440 net hours)
A team averaging 160 productive hours per two-week sprint, across six sprints in a quarter, delivers roughly 960 hours per quarter. At 440 net hours per FTE, that equals approximately 2.2 FTEs of actual delivery capacity, regardless of how many people are on the team.
If the portfolio was allocated 3.5 FTEs based on headcount, but actual velocity converts to 2.2, the portfolio is over-allocated for that team by 1.3 FTEs. That is a capacity gap that needs to be addressed before more work gets committed to them.
Explicit capacity reservations
When a project is approved by the governance body, the team responsible for delivery should formally reserve sprint capacity for that project. Something like: Project X owns 40% of this team's sprint capacity for Q3.
That reservation connects portfolio allocation to sprint planning. When the sprint team plans the upcoming sprint, they know that 40% of their capacity belongs to Project X. Other work fills the remaining 60%.
Without explicit reservations, sprint teams allocate capacity based on what is most urgent that week, which is frequently not the same as what the portfolio governance body decided was highest priority.
PMO visibility into sprint health
Portfolio managers need enough visibility into sprint-level data to know when a project is underconsuming its allocated capacity. A project allocated 2 FTEs at the portfolio level but averaging 20 story points per sprint when 40 was projected is a signal worth acting on.
The signal could mean the capacity assumption was wrong, the scope has changed, the team is blocked, or the project is being deprioritized at the sprint level in favor of other work. The cause matters because the response is different in each case.
This does not mean the PMO should run sprint ceremonies or attend standups. It means sprint data should feed the portfolio dashboard as a regular reporting input, and the PMO should review it with the same attention given to any other project health metric.
The PMO's role in a hybrid portfolio
In organizations running both waterfall and agile projects, the PMO maintains a single portfolio capacity view that aggregates both. Waterfall projects report capacity in FTEs and hours with traditional resource assignments. Agile teams report capacity via sprint velocity, which the PMO converts to FTE-equivalents using the method above.
The portfolio view does not care which methodology a team uses. It cares about whether the work allocated to the team is feasible given what the team can actually deliver. Both agile teams and waterfall teams need to express their capacity in comparable terms for the governance body to make informed decisions.
When the two levels conflict
The most common conflict: the portfolio shows a team has capacity for a new project, but the team says it is already at capacity based on sprint data.
The sprint data is almost always closer to the truth. Portfolio capacity calculations based on headcount overestimate available capacity because they do not account for context switching, non-project time, and the real overhead of running sprint ceremonies alongside project delivery. When the two conflict, start with the sprint velocity conversion and adjust the portfolio allocation to match.
For the FTE planning method that feeds portfolio capacity analysis, see the article on FTE planning for IT projects. For how capacity information gets used in approval decisions, see how to run a portfolio review meeting.
Frequently Asked Questions
What is the difference between sprint capacity and portfolio capacity?
Sprint capacity is a team's ability to deliver work in a single two-week iteration, measured in story points or hours. Portfolio capacity is the organization's ability to deliver strategic investments over a quarter or more, measured in FTEs. Sprint capacity is accurate and short-horizon. Portfolio capacity is approximate and long-horizon. Both are necessary.
How do you convert sprint velocity to portfolio FTE capacity?
Average the team's productive hours per sprint over the last three to six sprints. Multiply by the number of sprints in the planning period. Divide by net hours per FTE per period (roughly 390 to 440 per quarter). A team averaging 160 hours per sprint, over six sprints, delivers 960 hours per quarter, equal to approximately 2.2 net FTEs.
Why does the portfolio show full allocation when the sprint team says they are at capacity?
Because the portfolio allocation was based on theoretical headcount availability rather than actual sprint throughput. The portfolio may show 2 FTEs allocated, but the sprint data shows those people are delivering at 30 to 40% of full capacity due to context switching, support work, and shared ceremonies. Trust the sprint velocity when the two conflict.
Should the PMO attend sprint ceremonies?
No. The PMO's role is to receive sprint data as an input to the portfolio dashboard. That requires sprint reporting, not attendance at standups or retrospectives. The PMO needs to know whether a project is consuming its allocated capacity and tracking against portfolio commitments, not how the team is running its sprints.