Seasonal development patterns

Seasonal development patterns are the recurring, calendar-driven swings in engineering output that repeat at predictable times each year. The same months tend to be fast, and the same months tend to be slow, because the work is shaped by holidays, hiring cycles, planning quarters and on-call load rather than by the underlying capability of the team. A December slowdown around the winter break is seasonal. A sudden drop in a normally busy month is not.

These patterns matter because they change how you read every other delivery metric. A fall in merged pull requests in late December may be entirely normal, while the same fall in a peak shipping month signals a genuine problem. Without seasonal context, teams investigate normal lulls, set targets that ignore predictable dips, and credit or blame engineers for swings they did not cause.

Seasonality also drives planning. If output reliably climbs after a January hiring wave ramps up, roadmaps can be loaded accordingly. If a summer holiday stretch thins on-call cover, release freezes and reduced scope can be planned in advance rather than scrambled together when velocity drops.

You measure seasonal development patterns with a seasonal index that compares each period against its own long-run average. If a team averages 200 merged pull requests a month but December typically lands at 120, the December index is 60, meaning December runs at 60 percent of normal. A March that typically hits 240 has an index of 120.

You need at least two full years of history to separate seasonality from noise. Compare the same calendar period year over year: a swing that repeats every year is seasonal, while a swing that appears once is event-driven. Use a throughput measure that is hard to game, such as merged pull requests, completed story points, or deployment count, and divide actuals by the seasonal index to read the underlying trend.

1. 1

   Choose a throughput measure

   Pick a stable output signal such as merged pull requests, completed story points, or deployment frequency. Avoid lines of code or commit count, which reward churn rather than delivery.

2. 2

   Gather at least two years of history

   Collect the chosen measure by month or by sprint across two or more years. One year cannot tell a recurring cycle apart from a single unusual period.

3. 3

   Calculate the average for each calendar period

   For every month or sprint slot, average the output across all the years you hold. This baseline is what each individual period is compared against.

4. 4

   Compute the seasonal index per period

   Divide each period actual by its multi-year average and multiply by 100. An index near 100 is a normal period, below 100 is a seasonal lull, and above 100 is a seasonal peak.

A seasonal index tells you that output dipped, but not which part of the delivery system caused the dip. A metric tree decomposes engineering throughput into the drivers beneath it, so a seasonal swing can be traced to capacity, flow, or quality rather than treated as a single mysterious number.

KPI Tree builds this decomposition and attaches RACI ownership to every node, so each branch has a Responsible and Accountable owner. When the winter slowdown arrives, the team can see whether it came from reduced available capacity, slower review cycles, or a spike in incident load, and the accountable owner for that branch is pushed the change rather than discovering it in a retro weeks later.

There is no universal benchmark for engineering throughput, because team size, stack and definition of done all differ. What does generalise is the shape of the seasonal index across the year. Most software teams in the northern hemisphere see the same broad rhythm, with deep troughs around major holidays and recoveries in the planning quarters that follow.

Use the ranges below as a starting point for what a typical seasonal index looks like, then replace them with your own multi-year figures. A period that sits far outside its expected band, in either direction, is the signal worth investigating.

You cannot remove seasonality, and trying to force a holiday month to match a peak month usually just burns people out. The goal is to plan around the pattern so predictable dips do not derail the roadmap and so genuine problems are not lost inside expected lulls.

1. 1

   Calling one slow quarter seasonal

   A single low period caused by a reorganisation, a big migration, or an outage is event-driven. Labelling it seasonal bakes a one-off into every future forecast.

2. 2

   Using commit count as the measure

   Commit and line counts reward churn, not delivery, and noisy refactors distort the seasonal index. Use merged pull requests, completed story points, or deployments instead.

3. 3

   Ignoring seasonality in targets

   Setting the same flat target for every month makes good months look heroic and holiday months look like failure. Targets should follow the seasonal curve.

4. 4

   Letting a real regression hide in a lull

   A genuine drop in flow efficiency can be masked by an expected holiday dip. Always read the seasonally adjusted figure, not just the raw throughput.