Three PIs of recalibration · what actually changed

Six patterns

Output holds while the plan shrinks

Commitment fell from 952 story points in PI 8 to 842 in PI 10, having peaked at 1,075 in PI 9. Against that, velocity moved from 546 to 630, peaking at 676. Capacity rose 26% from PI 8 to PI 9 and then eased 2%, and velocity followed that shape closely (up 24%, then down 7%). Commitment did not: it rose 13% then fell 22%.

The interpretation that fits: demand on these teams is set by something outside the sprint plan. When the plan is smaller than demand, the difference arrives as creep. When the plan is larger, the excess simply does not get done and shows up as a low Completion Ratio. On either path the amount of work that lands stays close to how many people are available, which is what capacity measures. This is the reading that best fits three PIs of data; it has not been tested against an independent measure of demand.

In PI 8 roughly one story point in five that the organisation completed was never planned. In PI 10 it was closer to two in five. That is the single clearest change across the three PIs, and it happened while every headline throughput number stayed flat.

Commitment and creep, team by team

Web is the cleanest illustration

Web planned S5 with zero commitment. During that sprint the team resolved 41.5 story points, all of it classified as creep, and shipped three prolaio-ui finals (0.13.0 on 26 June, 0.14.0 on 6 July, 0.15.0 on 7 July). The work was real and it was valuable. It simply had no plan attached to it, so it inflates the creep ratio, contributes nothing to Completion Ratio, and technically breaches the "value delivered every sprint" goal because commit_done was zero.

Three separate metrics recorded a failure for a sprint in which the team shipped three releases. That is worth pausing on before drawing conclusions about Web from any of those three numbers.

Mobile is the counter-example that supports the pattern

Mobile is the one team that increased commitment in PI 10, from 158% to 200% of capacity, and it is the one team whose creep ratio fell materially, from 40% to 25%. Mobile also cut its bug count roughly in half. The team's Completion Ratio (39%) is the second lowest in the organisation, which is a direct consequence of committing twice its capacity rather than an indication of low output: Mobile resolved 157.5 points against 149 of capacity.

An alternative reading is worth stating. Mobile's creep fall might reflect better upstream planning by the product owner rather than the commitment level itself, and PI 9 was an unusually high-output PI for the team, so some of the PI 10 movement is regression to the mean. The pattern now holds in direction on all five teams and the rank ordering is consistent on both measures, which is a good deal stronger than a directional read alone. It is still five teams and three PIs. A common cause acting on both variables at once, such as a shift in what product asked for mid-PI, would produce the same picture, so this remains an association rather than an established mechanism.

Quality and release cadence

Mobile's bug count fell from 80 in PI 8 to 39 in PI 10, the largest single improvement anywhere in this dataset. Cloud rose from 10 to 21 and Data from 2 to 22 across the same window. Both rising teams shipped a significant platform version in PI 10, so a rise is not surprising, though Data's elevenfold increase from a very low base is worth a closer look at whether the PI 8 figure of 2 was under-recorded rather than the PI 10 figure being high.

On releases, the pattern is unambiguous once Cloud's CI noise is removed. Fusion went from zero final releases in PI 8 to nine in PI 10. Web went from five to eight. Data from zero to four. Teams are shipping more often while resolving roughly the same number of points, which is consistent with smaller batches reaching production faster. That is generally a healthy direction.

Cloud is the exception and it is the one release goal that clearly missed. Platform production deployments went 2, 5, 2 across PI 8 to 10, against a target of roughly one per active sprint. PI 10's two releases were 54 days apart. A third version, 3.10.16.0, was tagged on 3 June and never deployed before being superseded by 3.11.0 on 30 June.

Activity and review

The shape is the same on every team and on both measures. PI 9 was an unusually high-activity PI, PI 10 came down from it, and PI 10 still sits above where the organisation was in PI 8. Nothing in the story point data shows a comparable PI 9 spike, so more merge requests in PI 9 did not translate into more resolved points. That points at batch size: PI 9 saw more, smaller units of change moving through review.

Review depth is the most stable measure in the entire dataset. Approvals per merged MR were 1.93, 1.93 and 1.98 across the three PIs. Mobile runs conspicuously high at 3.14 in PI 10 and Web low at 1.22, a spread worth understanding, but the org-level figure has not moved at all while every other metric in this report has.

Team trajectories

Reading the table

Fusion is the only team improving on every planning metric simultaneously. Completion, Velocity vs Capacity and Creep Ratio all moved the right way in both PI 9 and PI 10. It is also the team that changed its commitment least. Two consecutive PIs at a perfect sprint-goal rate (16 of 16, then 17 of 17) with concrete, deliverable-shaped goals. Mobile's creep fell further in PI 10 (down 15pp against Fusion's 1pp), but from a much higher base and alongside a fall in completion.

Cloud has recovered from a weak PI 9 on completion and velocity, and hit every sprint goal in PI 10, but creep has risen in both PIs in this window (25% to 31% to 42%) and release cadence missed its target.

Web and Data both look worse than they probably are. Both cut commitment aggressively and both saw creep rise sharply over the same period, and both have sprint-goal data too sparse to read. Data's Completion Ratio actually improved slightly, from 34.6% to 36.6%. Web's Velocity vs Capacity dropped from 88% to 73% between PI 8 and PI 9 but has held at 73% and 76% since, and Web shipped more releases in PI 10 than in either prior PI. Web's merge activity also finished PI 10 above its PI 8 baseline, 97 against 83.

Mobile's picture is the most internally contradictory and the most improved on the things that matter to users: half the bugs, better goal hit rate, lower creep, four release candidates against a target of three. Its Completion Ratio fell because it committed 200% of capacity.

What the metrics can and cannot tell us

Completion Ratio is not measuring delivery

The org-level figure has been 45.1%, 47.1%, 46.4% while its denominator swung 13% up then 22% down. Per team, the ranking it produces mostly reflects how aggressively each team commits rather than how much it delivers. Mobile resolved more points than its capacity and scores 39%; Web resolved 76% of capacity and scores 45%. For a team committing at Mobile's PI 10 level of 200% of capacity, hitting 80% completion would require resolving committed work worth 160% of capacity. The closest any team has come in three PIs is Web's 64% in PI 8, still 16 points short.

Velocity vs Capacity is the more honest throughput read and it is stable, comparable across teams, and already in the warehouse. It is worth considering whether the shared target should move to it.

Sprint goal hit rate is becoming unreadable

Parseable goals per team went from 15, 7, 16, 22 and 7 in PI 9 to 16, 2, 17, 9 and 2 in PI 10 (Cloud, Data, Fusion, Mobile, Web in order). Cloud and Fusion held steady or rose. Data, Mobile and Web fell sharply. The cause is partly syntax: Data and Web wrote goals using [] with no space between the brackets, which the warehouse regex \[.\] does not match. Cloud and Fusion, the two teams with clean 100% rates, are also the two teams writing goals in the parseable format consistently.

This creates a circularity worth naming: the teams that look best on goal achievement are the teams whose goals the system can read. That is not the same as the teams that hit their goals most often.

DORA coverage is still partial

Deployment tracking covers only Cloud and Web, so DORA deployment frequency and lead time cannot be computed for Data, Fusion or Mobile. Two of five teams is not enough to say anything organisation-wide about deployment practice, and the two that are covered sit an order of magnitude below target, so the metric is not currently discriminating between them either.

Questions this raises

1. If commitment discipline was the goal of the last two PIs, did it work? Organisation-wide commitment fell from 952 story points to 842, and from 175% of capacity to 125%. Commitment came down on every team except Mobile, substantially on Data, Web and Cloud. Completion Ratio did not move: 45%, 47%, 46%. Creep rose on all three teams that cut substantially and fell slightly on Fusion, which barely cut, while Mobile, the one team that raised commitment, saw creep fall. The reading that best fits the evidence is that the recalibration changed the classification of work rather than the flow of it, though three PIs is a short window and other explanations have not been ruled out. The question for the room is whether that was the intended outcome, whether the exercise should continue into PI 11, and what a success criterion would look like that this data could actually detect. Why this matters · Two PIs of effort went into this. It is worth knowing whether it moved anything before committing a third.
2. Should the shared 80% target move from Completion Ratio to Velocity vs Capacity? Completion Ratio is bounded by commitment size, so a team can improve it by committing less rather than delivering more. No team has come close to 80% in three PIs. Velocity vs Capacity sits at 76% to 110% across the teams, is comparable between them, and measures total resolved work against available people. Why this matters · A target nobody can hit stops functioning as a target. Team leads have this in their OKRs.
3. Where is the unplanned work actually coming from? 38% of everything completed in PI 10 was never in a sprint plan, up from 21% in PI 8. The warehouse can tell us how much creep there is but not what it is. Without knowing whether it is production support, unplanned discovery, cross-team dependencies or late requirements, there is no way to decide whether it should be reduced or simply planned for. Why this matters · This is the largest single change across the three PIs and the one we understand least.
4. What is Fusion doing differently, and is it transferable? Fusion improved on completion, velocity and creep simultaneously, holds a perfect two-PI goal record, and went from zero to nine final releases. It is also the team that changed its commitment least, which fits the pattern that stability beats correction. Whether this is process, product owner engagement, team size or the nature of the work is not something the metrics can answer. Why this matters · One team is consistently doing well. Understanding why is cheaper than any process change.
5. Web's S5 recorded three metric failures for a sprint in which it shipped three releases. Is the goal wrong or the sprint? Zero commitment in S5 meant zero committed-done for that sprint, pushed Web's PI creep ratio to 122%, and technically breached the "value delivered every sprint" goal, all while 41.5 points were resolved in the sprint and three prolaio-ui releases went out. Either the sprint was planned wrongly or the goal is written in a way that punishes a legitimate way of working. Why this matters · Jeff's team goal is currently unfalsifiable in the useful direction. It can be missed by shipping.
6. Who owns metric pipeline health, and what would tell us the next gap is there? The warehouse has no freshness or plausibility check on any of its feeds. A feed can silently under-report for months and the only signal is a metric that looks wrong to somebody reading it. The GitLab events feed drives commit counts, MR throughput and review depth, so a gap there moves several metrics at once and in the same direction, which is exactly the pattern most likely to be mistaken for a real trend. Why this matters · Every agile and DORA metric in this report depends on a pipeline nobody currently monitors. A cheap row-count and contributor-count check per feed, alerting on a step change, would cover most of the risk.
7. What changed about batch size between PI 8 and PI 9, and was the PI 9 pattern better or just busier? PI 9 carried 3.3 times the merged-MR volume of PI 8 (2,108 against 638) for roughly the same story point output per unit of capacity: Velocity vs Capacity was 100% then 99%. The median contributor went from 14 merges to 34 and back to 19. Either work was being broken into smaller pieces in PI 9, or the same work was moving through more merge requests. The first is generally a good thing and worth keeping; the second is overhead. Why this matters · Smaller batches are one of the few levers that reliably improves flow, and we appear to have pulled it once without deciding to.
8. Should we extend deployment tracking to Data, Fusion and Mobile? DORA metrics currently cover two of five teams. Both covered teams sit an order of magnitude below the 0.5 per day production target (Cloud 18x, Web 9x), so the metric is not currently discriminating between good and bad, it is just uniformly red. Extending coverage would either confirm this is an organisation-wide pattern or reveal variation worth acting on. Why this matters · Deployment frequency is the DORA metric most tied to delivery outcomes, and we can see it for less than half the organisation.

Method

Scope. PI 8 (30 Oct 2025 to 3 Feb 2026), PI 9 (4 Feb to 29 Apr 2026), PI 10 (28 Apr to 5 Aug 2026). The warehouse's dim_pi ranges overlap by a day at each boundary; sprint-level assignment is used throughout, so no sprint is counted twice. Five teams: Cloud, Data, Fusion, Mobile, Web. Platform Engineering is not included as it does not run the same sprint structure.

IP sprints excluded. Every figure covers active sprints only, which is sprints 1 through 5 in each PI. The IP sprint (sprint 6) is excluded from all totals, ratios and per-day rates, following the standard convention. This means figures here will not match any report built on full-PI totals.

Definitions. Velocity is commit_done + creep_done. Completion Ratio is point-weighted at PI level, SUM(commit_done) / SUM(commitment), not an average of sprint ratios. Committed Done vs Capacity is commit_done / capacity. Velocity vs Capacity is velocity / capacity and can exceed 100%. Creep Ratio is creep / commitment. Bugs include both Bug and Anomaly issue types.

Source conventions. Cloud release cadence uses production deployment dates from the deployments table rather than GitLab tag dates, because tags can lag deployment by weeks. Deployment environments are deduplicated by team and environment before counting, to avoid double-counting rows that appear under both the jira and gitlab sources.

Activity metrics. Merged MRs, opened MRs, commits and approvals are counted from the GitLab events feed over each team's active-sprint window, so they are directly comparable across PIs. Per-day rates use active days in that window.