A 12-week average of how engineering effort is distributed helps leaders understand longer-term work patterns. But sprint planning depends on what’s happening now, not just what happened on average over the past quarter.
Sprint planning often operates at a two-week cadence. Quarterly averages operate at a 12-week cadence. Using a 12-week average to estimate next week’s engineering capacity works when work distribution is stable. It can fail when work distribution is volatile. A production incident, a compliance deadline, an unplanned infrastructure event, or a period of concentrated on-call load can shift capacity away from product development in a matter of days. Quarterly averages can smooth those events away, leaving the team with less capacity for planned product work than the average suggests.
The Larridin customer data illustrates the volatility. A 12-week average showing 12% Admin work looks like a manageable overhead level. But in one week, Admin work consumed 56.9% of org effort while Product Development fell to 4.6%. The following week, Product Development jumped to 50.1%. That kind of swing is easy to miss when sprint planning relies on the quarterly average alone.
WorkGraph classifies engineering work by intent rather than simply counting PRs. Categories such as Product Development, Deployments and Ops, Reliability, and Admin show what the work was trying to accomplish. That makes WorkGraph useful for capacity planning: it shows how engineering effort was distributed across types of work, not just how much output was produced. A team can ship work while the mix underneath that output changes sharply from one week to the next.
The week-level granularity is the critical piece. WorkGraph shows the distribution for individual weeks rather than only aggregating across the quarter. The 56.9% Admin week is visible as an anomaly against the surrounding weeks. Separately, Reliability data showed one engineer handling 29 of 46 team incidents in the same week Deployments and Ops reached 56.4% of org effort. Those signals corroborate a capacity event that a quarterly average could obscure.
A trailing four-week view can be a practical starting point for seeing the recent distribution of engineering work. Comparing that recent view with the 12-week baseline helps leaders see whether the current work mix has shifted enough to affect the next sprint. The goal is to bring the most recent capacity pattern into the planning discussion rather than assume the quarter-wide mix still holds.
The recent view doesn’t replace the longer-term baseline. It adds the context that a quarterly average alone cannot provide.
An unusual week where Admin, Reliability, or Deployments and Ops moves well above the recent baseline is worth flagging before the next sprint planning session. It may reflect a capacity event that is still resolving or could recur, and it deserves explicit discussion rather than being absorbed into the planning average.
The Larridin customer example shows why multiple signals matter. One engineer handled 29 of 46 incidents in the same week Deployments and Ops reached 56.4% of org effort. Together, those signals give engineering leaders more context for understanding what happened to capacity that week.
DORA metrics measure pipeline outcomes: how often code ships, how long it takes, and how often deployments fail. WorkGraph measures where engineering effort is going: what types of work are consuming engineering capacity.
The two views are complementary. DORA shows how the delivery pipeline is performing. WorkGraph shows what the engineering organization is spending its time on. Reading them together can help leaders distinguish a delivery-performance problem from a capacity shift caused by a changing mix of work.
There’s no single right answer for every team. A recent multi-week view — four weeks, for example — can give sprint planning more current context, while the 12-week view provides a longer baseline.
During high-volatility periods such as incidents, compliance events, or major infrastructure work, the most recent weeks may deserve more weight in the planning conversation.
Yes. The 12-week data in the Larridin customer example showed Deployments and Ops absorbing 32% of org effort versus Product Development at 27%. That is useful context for a broader resource-allocation discussion.
The distribution might be intentional, or it might indicate an operational burden worth investigating. Either way, the longer-term view helps leaders decide whether the current allocation reflects priorities or whether capacity needs to be rebalanced. WorkGraph makes the distribution visible so leaders can evaluate it deliberately.
WorkGraph classifies engineering work by intent rather than simply counting PRs. In this customer environment, categories included Product Development, Deployments and Ops, Reliability, and Admin.
The week-level distribution shows where engineering capacity went and how that mix changed over time.
Larridin’s WorkGraph gives engineering leaders week-level intent classification across the engineering organization, so capacity planning reflects what the org is actually doing rather than relying only on a smoothed historical average.
Book a discovery call to see your WorkGraph capacity planning view.