Program Increment Planning, often called PI Planning, is a structured, time-boxed event designed to align development teams toward a shared vision and mission within the Scaled Agile Framework (SAFe). Determining team capacity is the systematic process of estimating the maximum volume of work a team can realistically complete during the upcoming increment. This estimation provides the necessary guardrails for effective planning, ensuring that the work commitment aligns with the team’s ability to deliver. Capacity determination is a fundamental practice within SAFe, providing the necessary data to forecast outcomes and manage expectations across the entire organization.
Understanding the Context: PI Planning and Team Capacity
PI Planning is typically a two-day, cadence-based event where all teams on an Agile Release Train (ART) come together to review the Program Backlog and draft their team-level plans. This synchronous approach ensures organizational alignment on objectives, milestones, and dependencies for the next Program Increment (PI), which is typically an 8- to 12-week period.
Team Capacity represents the maximum amount of effort the team can dedicate to new feature development during that PI duration. This effort is generally expressed using abstract planning units, such as Story Points. Accurately defining this capacity is necessary for teams to select the right amount of work from the prioritized backlog and make a credible commitment to stakeholders.
Why Capacity Determination is Crucial for Program Execution
Effective capacity planning prevents overcommitment, where teams attempt to take on more work than they can reasonably complete. Grounding the work commitment in a realistic capacity number improves program predictability. This allows the organization to forecast delivery timelines with greater confidence and manage risks proactively.
Accurate capacity determination manages the expectations of business owners and stakeholders regarding the scope of work that will be delivered. Planning within known limits helps the team maintain a sustainable pace throughout the increment, reducing burnout and preserving solution quality.
Defining the Baseline: Calculating Total Available Working Time
The first mathematical step in capacity determination is establishing the raw, unadjusted baseline of total available working time for the team. This calculation multiplies the number of team members available for the entire PI by the number of working days within the Program Increment period. For example, a nine-person team working a ten-week PI (50 working days) calculates a baseline of 450 person-days.
This initial figure represents the theoretical maximum capacity under ideal conditions. The result is a raw input, typically expressed in person-days or person-hours, and serves as the starting point for all subsequent adjustments.
The Foundational Initial Step: Accounting for Known Absences
The foundational initial step for determining PI Planning team capacity is the systematic subtraction of all known, non-working time from the baseline calculation. This process immediately adjusts the theoretical maximum down to a realistic figure by removing fixed constraints on the team’s availability. Known absences are non-negotiable time blocks that must be removed before any work estimation can begin.
This includes planned employee vacations, public holidays that fall within the PI calendar, and scheduled training days. Teams may also forecast a small allowance for anticipated sick leave based on historical team data. Removing these planned absences clarifies the true number of person-days or hours available for work. Failing to remove this time would instantly inflate the capacity estimate, leading to inevitable overcommitment.
Converting Available Time into Estimated Effort
Once the available working time is refined by removing all known absences, the next step is to convert that time into an estimated effort, typically expressed in Story Points. This conversion relies on the team’s historical performance metric known as Team Velocity. Team Velocity is defined as the average number of Story Points the team successfully completed and delivered in previous Program Increments.
To derive the estimated capacity, the refined available time is correlated with the team’s historical velocity factor. Using the team’s average velocity from the last two or three PIs provides a reliable forecast. For instance, if a team achieved an average velocity of 50 Story Points per iteration and the upcoming PI has five iterations, the initial capacity forecast is 250 Story Points.
This method uses past performance as the most reliable indicator of future output, effectively translating the team’s available time into a quantity of work they have proven they can successfully manage. This estimated capacity represents the team’s ability to handle new feature development, but it requires final adjustments for operational needs.
Finalizing Capacity and Applying Buffers
The final stage of capacity determination involves applying necessary buffers to the estimated capacity to account for work not directly related to new feature development. This adjustment ensures the team is not planning to commit to 100% of their theoretical maximum. A portion of capacity must be explicitly allocated for non-feature work:
- Maintenance activities, such as addressing technical debt and refactoring code.
- Unplanned work, including supporting production issues, fixing newly discovered defects, and responding to urgent support requests.
- Internal team activities, such as coaching, team building, and necessary administrative overhead.
These buffers typically range from 10% to 20% of the total estimated capacity, depending on the maturity and stability of the team and product. Applying these buffers yields the final, realistic capacity number, which the team uses to select work from the Program Backlog. The team must review and sign off on this final capacity number, signifying their collective commitment to the planned work.

