Sprint planning: the two checks that change your estimates
Before committing sprint scope, two signals materially affect delivery predictability.
IFR (Intent-First Rate)
MTTCD (Mean Time to Change Decision)
If there are any pending CHIs for entities your sprint will touch, check how long CHIs have been taking to resolve.
Understanding why a PR is blocked
When a PR is marked blocked by rkito's CDA check, here is what it means and what unblocks it.
A BLOCKED CDA check means the code introduced a structural architectural change that was not declared and approved before implementation (UDR), or the change violated a design rule (Lens failure).
The architect reviews the auto-drafted Change Intention and either approves it (the structural change was legitimate) or the developer reworks the code.
Not to approve the CHI — that is the architect's job. Your role is to ensure the architect knows the PR is blocked and the sprint depends on resolution.
Reading DCS as a delivery leading indicator
A declining DCS sprint-over-sprint predicts incoming rework before it shows up in the sprint board.
DCS declining by > 5 points: more PRs than usual are failing design checks. These either get blocked (slowing delivery) or get exceptions approved (introducing untracked architectural debt).
Do not use this to pressure the architect to approve more CHIs faster. The right response is asking the VP Eng: “DCS dropped — what is the root cause and how do we address it before it compounds?”
Features with architectural dependencies — the right sequence
For features that require structural changes (new services, new interfaces, changes to existing component boundaries):
Before sprint planning, ask the architect: “Does this feature require a Change Intention?”
If yes: raise the CHI before the feature enters the sprint backlog. Do not put structural features in the sprint until their CHI is approved.
Track the CHI in /changecontrols/changeintentions. Once approved, the feature can enter the sprint with its architectural scope defined.
At sprint review, check if the feature's PR passed CDA cleanly. A clean CDA pass on a CHI-backed PR means the implementation matched the approved design.
This sequence converts architectural governance from a delivery blocker into a delivery enabler.
Quarterly: delivery health and governance correlation
Once per quarter, work with the VP Eng to correlate:
IFR trend over the quarter with sprint completion rate. Rising IFR should correlate with more predictable sprint completion.
MTTCD trend with blocker frequency in sprint retrospectives.
If these correlations are not showing up, the CHI process may be too slow to be useful at your sprint cadence — raise this with the architect.
Your role in Steering
Product owners are readers and communicators in the Steering layer, not authors. Your role is to ensure the team can find governance context before they code, and to document product-architecture decisions.
The product owner's Steering task before each sprint: navigate to the Pillar pages for the domains your sprint will touch, check active Lenses, identify any structural changes that will require a CHI, and surface them in planning. This converts governance from a mid-sprint blocker into a pre-sprint planning step.