All four teams hit every goal they set — 8 of 8, the first clean sweep on record — and completed 106% of capacity against a plan more than twice its size. Defect intake was matched almost one for one (0.94x), and Fusion's production releases are now measured, taking throughput coverage to 3 of the four teams. Two things to watch: feature development fell to 34% of completed work as verification and defect work rose, and merged MR volume is far less even between teams than the raw counts suggest.
Velocity came in at 105.7 points, 106% of capacity, above the 97% baseline, against total demand of 252% of capacity. Demand has sat near or above 200% for four PIs; per the proposal note it is the message behind investment allocation rather than a recurring KPI, so it is stated here once and not tracked weekly.
| KPI | What is reported | Target | PI 12 · S1 | Reference |
|---|---|---|---|---|
| 1 · Investment allocationIs capacity going to the right things? | Share of completed work by work typeIssue count, on the capitalization report's mapping | Mix agreed at PI planning — none set | 74.1% new capability | PI 11 78.3% |
| roll-up · Defects | Bugs and anomalies, not yet split pre- and post-release | — | 15.4% | PI 11 12.2% |
| roll-up · Run the business | Support, maintenance and operations | — | 4.5% | PI 11 4.4% |
| roll-up · Exploration | Spikes | — | 3.0% | PI 11 1.7% |
| roll-up · Not yet mapped | Change Request, Risk, PI Risks, CAPA | — | 3.0% | PI 11 3.5% |
| slice · Unplanned work % of capacity | Completed unplanned work ÷ capacity | — | 28.2% | PI 9–11: 24.2% · 30.7% · 32.4% |
| 2 · Delivery predictabilityDid we deliver what we promised? | Interim — sprint goal attainmentFor: PI objective predictability, business value achieved ÷ planned. Needs business owners to score objectives at PI planning | 80% | 100% (8/8) | PI 11 86% |
| 3 · Delivery throughputHow fast does change reach users? | Production releases · change lead timeNeeds release measurement for Mobile | 1 release per team per active sprint | 1 (Fusion) | 3 of 4 teams measured |
| 4 · Change failure rateDo our releases hold up? | Interim — defect fix ratioFor: share of production releases needing a rollback or hotfix. Needs those to be recorded against the release | ≥1.0x sustained | 0.94x | note's current 1.00x |
| 5 · AI-assisted deliveryIs AI-assisted engineering paying off? | Interim — merged MRs per engineerFor: the same count read with a rework guardrail and the agent-assisted share. Needs the agent-assisted label and its CI check |
No target, by rule | 4.8 | PI 11 pace 5.2 |
Completed work by type, on the same issue-type mapping as the engineering capitalization report, counted in issues. Points cannot be used — bugs, anomalies, requirements and specification items carry none, so measured in points defects would be 0% of the sprint. Epics and Initiatives are excluded as containers.
| Work type | Rolls up to | Items | PI 12 · S1 | PI 11 | Δ |
|---|---|---|---|---|---|
| Feature development | New capability | 68 | 33.8% | 41.2% | −7.4 pts |
| Design & specification | New capability | 43 | 21.4% | 28.2% | −6.8 pts |
| Testing & verification | New capability | 38 | 18.9% | 8.9% | +10.0 pts |
| Defects | Defects | 31 | 15.4% | 12.2% | +3.2 pts |
| Support | Run the business | 1 | 0.5% | 1.5% | −1.0 pts |
| Maintenance & ops | Run the business | 8 | 4.0% | 2.9% | +1.1 pts |
| Research | Exploration | 6 | 3.0% | 1.7% | +1.3 pts |
| Not yet mapped | Not yet mapped | 6 | 3.0% | 3.5% | −0.5 pts |
| All completed work | 201 | 100% | 100% |
New capability took 74.1% of completed work, against 78.3% across PI 11 — but the shape inside it moved sharply. Testing and verification roughly doubled its share, 9% to 19%, while feature development fell from 41% to 34% and defects rose from 12% to 15%. A single sprint against a whole PI is a weak comparison and a release sprint naturally carries verification work; S2 will show whether it holds.
Run the business stayed small at 4.5%. Almost all support work is raised in the Platform Engineering project rather than against these four teams, so it does not appear here.
Defects cannot yet be split pre-release from post-release, which is what decides whether they count as new capability or as running the business — 31 items, 15.4% of the sprint. They are shown as their own band until a release link or field exists for it.
No target mix has been set, so the percentages are a trend, not a pass or
fail. Four issue types — Change Request, Risk, PI Risks and CAPA — are not yet mapped; they are
3.0% of this sprint. The tech-debt label is not in use
in Jira, so technical debt cannot be shown separately.
Fusion's production releases are now measured, and the first one captured is xcures 1.1.0 on 19 October. Throughput now reaches Cloud, Fusion and Web. Mobile is still not measured — its only deployment targets are the TestFlight and Google Play internal tracks, which do not count as production releases; a release counts when a version reaches users on the store's production track.
Cloud and Web released nothing to production this sprint. Cloud's 3.17.0 went out on 2 November, inside S2. On the target of one release per team per active sprint, one of the 3 measured teams met it.
| Change lead time · median days to production | PI 11 | PI 12 to date |
|---|---|---|
| Cloudcloud-platform-environment | 31 | 24 |
| Cloudrest-api | 28 | 13 |
| Fusionxcures | — | 32 |
| Webprolaio-workbench | 53 | no production deploy yet |
Per project, never averaged across projects — lead_time_pi is grained
by team, project, environment and PI. PI 12 figures cover the PI so far, not S1 alone, and will move
as the PI runs.
Bug and Anomaly issues created and resolved inside each team's own sprint window, counting only those closed as Done and attributed by the Jira Team recorded on the issue.
| Team | Opened | Fixed | Ratio | Backlog start | Backlog end | Net |
|---|---|---|---|---|---|---|
| Cloud | 5 | 5 | 1.00x | 44 | 43 | -1 |
| Fusion | 0 | 0 | — | 7 | 7 | +0 |
| Mobile | 25 | 23 | 0.92x | 118 | 120 | +2 |
| Web | 1 | 1 | 1.00x | 7 | 7 | +0 |
| All four teams | 31 | 29 | 0.94x | 176 | 177 | +1 |
29 fixed against 31 opened — 0.94x. Cloud and Web each closed everything they opened; Mobile carried the volume, 25 opened and 23 fixed, and is the whole of the shortfall. The open defect backlog was effectively flat at 176 → 177, with Mobile holding 120 of it and Cloud 43.
9 further defects were raised in this window with no Jira Team set and are not counted above. Two belong to Platform Engineering, which is out of scope; the other seven sit in projects no team owns in Jira. Assigning them would make the measure complete.
A fortnight is a short window for this ratio — read it as the first point in a PI 12 series rather than a step change — and it stands in for change failure rate rather than measuring it.
Engineer-authored merge requests divided by the team's delivery roster. Automated dependency bumps are excluded. Cloud is the only team running an automated updater, and it produced 61 of Cloud's 93 merged MRs this sprint — two thirds of the team's count, and 198 of 458 across PI 11. Left in, they put Cloud at 15.5 per engineer and first by a distance; taken out, the ordering changes.
| Team | MRs merged | Dependency bumps | Engineer-authored | Per engineer | PI 11 pace | Δ |
|---|---|---|---|---|---|---|
| Cloud6 delivery | 93 | 61 | 32 | 5.3 | 7.2 | ▼ 1.9 |
| Fusion5 delivery | 6 | — | 6 | 1.2 | 2.6 | ▼ 1.4 |
| Mobile10 delivery | 76 | — | 76 | 7.6 | 7.3 | ▲ 0.3 |
| Web6 delivery | 15 | — | 15 | 2.5 | 1.9 | ▲ 0.6 |
| All four teams | 190 | 61 | 129 | 4.8 | 5.2 | ▼ 0.4 |
Mobile leads at 7.6 per engineer and Cloud follows at 5.3; Web is on 2.5 and Fusion on 1.2. Measured against each team's own PI 11 pace the picture is different again: only Mobile and Web are up, Cloud is down a quarter once its updater traffic is removed, and Fusion has more than halved — six merge requests in a fortnight on a roster of five, continuing the decline flagged at PI 11 close-out. Merge request size is not measured, so a team working in larger changes reads lower here; that is instrumentation item 3 in the note.
The KPI is three parts read together: the count, a rework guardrail (follow-up
commits by engineers on agent-assisted merge requests before merge) and the agent-assisted
share. Neither of the latter two exists yet — both need the agent-assisted
label and its CI check. Until they do, a movement in this count cannot be told apart from work
being split into smaller merge requests.
The level and the movement tell different stories, which is why both are shown. Cloud sits second on level while falling a quarter against its own history; Web sits third while rising a third. Points of comparison between teams are limited — team size, role mix and how work is split all move this number without the work changing.
Three of the eight were goals a team had already missed. Mobile's "Kick-off BYOD beta testing" was set and missed in PI 11 S4, S5 and S6, and "6.4.6.0 Release" was missed in S6 — both closed here, with the 6.4.6.0 final tag on 26 October corroborating the second. Cloud closed the ZBeats runbook it had missed in PI 11 S6.
The four teams set 8 goals against a PI 11 four-team average of 11.2 per sprint; Web set one, Fusion and Mobile two each. At that size a single miss would have taken the rate to 87.5%. The note's own caveat applies: this measures whether goals were met, not whether they were ambitious — which is why PI objective predictability, scored by business owners, is the KPI it stands in for.
Source. prolaio-engineering-metrics.metrics in BigQuery, pulled
5 November 2026. PI 12 S1 ran 14–28 October 2026; each team has its own sprint boundaries and every
window-based figure uses the team's own dates. PI 12 S2 is still in flight and is
excluded. Scope is Cloud, Fusion, Mobile and Web; Data Engineering moved to the AI
& Technology department and every baseline here is recomputed on the four-team basis, so figures
will not match the PI 11 close-out reports.
Definitions are those of Leadership KPIs — Proposal (updated 5 November 2026), not restated here. Interim readings are labelled with the KPI they stand in for. The baseline is the PI 11 per-sprint average over S1–S5, excluding the IP sprint.
Defects and work types. From issues, by each team's own sprint
window, attributed by the Jira Team recorded on the issue and counting only
resolution = Done. Issues with no Team set are excluded from the defect ratio
(9 in this window); the allocation mix also counts unassigned issues that sit in
these four teams' projects, since it is an engineering-level figure rather than a per-team one.
Figures are not comparable with runs before 5 November 2026, which attributed issues by Jira project.
Merge requests come from events joined to
dim_contributor, attributed to the author's team; accepted means merged.
Automated dependency bumps are excluded by title match; Cloud is the only team with
an automated updater. The PI 11 pace is that PI's window total divided by six sprints, because MR
data only exists at PI-window grain — per-sprint counts cannot be summed. Delivery roster =
engineers, QE and interns; PMO and Product Owners excluded. 27 across the four teams
against a PI 11 average of 26.4.
Production releases are successful deployments at tier production,
deduplicated on project, commit and date. Change lead time is the median days from
commit to production deployment, reported per project.
Sprint goals are parsed from the markdown checkboxes in
sprints.sprint_goal, verbatim, as of 5 November 2026, and may rise.
Known gaps. Mobile has no production release instrumentation. No rework or agent-assisted measure, so KPI 5 is a count alone. No business-value scoring, so KPI 2 is a goal count. No failed-deployment record, so KPI 4 is a defect ratio. No merge request size, no cycle time, no measure of goal quality.