Shared Resource Capacity

Shared Resource Capacity is the portion of a person's or specialized resource's available working time that must be divided across multiple teams, projects, or initiatives rather than being dedicated entirely to a single Agile team. It represents one of the most common sources of capacity planning error, because time spent supporting other teams is not available for the current team's sprint commitments, even though the resource may appear on the team roster as a full member.

Core Concept

The Shared Resource Problem

Many organizations lack the headcount to dedicate specialists such as database administrators, security engineers, UX designers, or DevOps engineers to a single team full time. Instead, these specialists split their time across several teams simultaneously. When capacity planning fails to account for this split, the teams sharing the resource collectively overcommit, because each team's plan assumes access to more of the specialist's time than actually exists.

Allocation Percentage

Each team receiving a fraction of a shared resource's time is typically assigned an allocation percentage, agreed in advance, that represents the proportion of that resource's working hours dedicated to that team during a given period.

Where $P_t$ is the allocation percentage assigned to team $t$, and $k$ is the number of teams sharing the resource. If the sum of allocations across all teams exceeds one, the resource is structurally overcommitted before any actual work begins.

Sources of Shared Resource Demand

Specialist Scarcity

Highly specialized roles, such as security architects, data scientists, or platform engineers, are often too scarce or too expensive to dedicate to a single team, making sharing across multiple teams an organizational necessity rather than a choice.

Cross-Cutting Infrastructure

Shared infrastructure, shared codebases, or shared platform components frequently require input from a common set of engineers who service every team building on top of that platform, creating a natural bottleneck around their availability.

Support and Escalation Duties

Individuals who serve on rotating support or incident response duty across multiple teams have their planned capacity interrupted unpredictably, making their shared availability harder to forecast than a simple fixed percentage allocation.

Modeling Shared Resource Capacity

Fixed Percentage Allocation

The simplest model reserves a constant percentage of the shared resource's time for each team every iteration, providing predictability at the cost of flexibility when actual demand fluctuates.

Rotating Dedicated Blocks

An alternative model dedicates the shared resource entirely to one team at a time in rotating blocks, such as alternating sprints, which reduces context-switching cost for the specialist but introduces waiting periods for the teams not currently receiving their attention.

Demand-Driven Negotiation

More mature organizations negotiate shared resource time sprint by sprint based on actual upcoming demand from each team, requiring active coordination between product owners or team leads but yielding more efficient use of scarce specialist time.

Risks of Poorly Managed Shared Capacity

Silent Overcommitment

Because a shared resource may be listed on multiple team rosters simultaneously, it is easy for each team to independently assume full or near-full availability, producing a collective capacity plan that is impossible to satisfy in aggregate.

Priority Conflicts

When multiple teams compete for the same limited window of a shared resource's time, whichever team has the most organizational leverage often wins, regardless of which request is actually most urgent or valuable, distorting prioritization.

Increased Context Switching Cost

Specialists split across many teams pay a cognitive tax every time they switch contexts, reducing their effective output even when the raw hours allocated across teams sum correctly to their total available time.

Single Point of Failure

If a heavily shared resource becomes unavailable, every team relying on that resource is affected simultaneously, amplifying the organizational impact of a single person's absence far beyond what would occur with a dedicated team member.

Best Practices for Managing Shared Resource Capacity

Make Allocations Explicit and Visible

Documenting each team's percentage allocation of a shared resource, and making that documentation visible to all teams involved, reduces the likelihood of silent overcommitment and clarifies expectations.

Limit the Number of Teams Sharing a Single Resource

Spreading one person's time across too many teams multiplies context-switching losses; organizations often cap the number of teams a specialist can be actively allocated to at any one time.

Plan Shared Capacity at the Portfolio Level

Because shared resources cut across team boundaries, their allocation is best coordinated at a program or portfolio level rather than left to individual teams to negotiate independently, ensuring the sum of allocations never exceeds actual availability.

Track Actual Versus Planned Allocation

Comparing the time a shared resource actually spends on each team against the planned allocation percentage helps identify drift, informal reprioritization, or structural understaffing that formal plans have not captured.