Product Owner Playbook
Using rkito signals to plan predictable sprints and understand why delivery gets blocked.
Sprint planning: the two checks that change your estimates
Before committing sprint scope, two signals materially affect delivery predictability.
IFR (Intent-First Rate)
Navigate to /changecontrols/dashboard and check the last sprint's IFR.
Architectural approvals are happening before coding. Sprint scope you commit to has a low architectural surprise rate.
Structural changes in the last sprint started without architectural approval. Expect mid-sprint blockers at a similar rate this sprint. Build buffer or raise CHIs for all structural items before the sprint starts.
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.
Architectural decisions are resolving quickly. Minimal delivery impact.
A blocked architectural decision this sprint will sit for a week before resolution. Either resolve pending CHIs before the sprint starts or de-scope structural items.
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.
Navigate to /changecontrols/changeintentions and share the pending CHI link with the architect, along with the sprint deadline.
Reading DCS as a delivery leading indicator
A declining DCS sprint-over-sprint predicts incoming rework before it shows up in the sprint board.
Navigate to /changecontrols/dashboard — note DCS for this sprint vs last sprint.
- 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.
Quarterly: delivery health and governance correlation
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 signals behind the playbook
Percentage of structural PRs where design approval preceded the first commit.
Average time from a blocked PR to architectural resolution.
Percentage of PRs that passed all Lens checks. The headline conformance metric.
Percentage of structural changes with no approved Change Intention.