Bifrost and CDP Goal-Led Kanban Transition

Scope + authority note (2026-07-12). This operating-model narrative covers both Bifrost and CDP but is homed under bifrost/delivery/ (the originating squad — the repo deliberately has no cross-team delivery root). The durable sprint doctrine it motivated is now canonical in .claude/reference/sprint-layer.md — where this narrative and that doctrine disagree, the doctrine wins; this file remains the transition rationale and history (why the shift, the WIP-field and status-column decisions, the working guide framing).

This document explains how Bifrost and CDP are using the existing delivery repo to transition from traditional sprint planning toward a goal-led Kanban way of working.

The intent is speed and clarity, not more ceremony. The sprint file remains what this repo already defines it to be: a time-boxed goal window and priority-ordered ready queue, derived from roadmap priority, staffing, capacity, and task-breakdown readiness. It is not a fixed backlog, not a capacity cage, and not a new operations framework.

Why we are shifting

Several Mekari tribes have moved toward Kanban because AI-assisted delivery changes the pace of work. Engineers can break down, implement, verify, and iterate faster than a traditional sprint backlog assumes. If a blocker clears, a task is discovered, a bug appears, or an AI-assisted slice finishes sooner than expected, waiting for the next sprint planning ceremony slows the team down.

At the same time, Bifrost and CDP still need a visible goal. Some monthly goals are effectively monthly sprints: there is an outcome the team must protect, even if the work items underneath it need to stay flexible. This transition keeps the goal and removes the hard work-item boundary.

The model is:

Goal-led Kanban: commit to the goal, keep the queue fluid.

What this means in this repo

The repo already has the right shape:

• Roadmap ## Priority is the canonical priority order.
• Initiative READMEs carry DRI, implementors, QA, effort, forecast, and Jira Epic.
• RFCs and task-breakdowns define implementation-ready work.
• Capacity gives sequencing context, not a hard sprint cap.
• Sprint docs under delivery/sprints/ are team-level, cross-initiative ready queues.
• Sprint review writes actuals back to dated status reports, roadmap mirrors, and decision records.

So this shift does not need new fields, new boards, or extra control sections. It needs the team to use the sprint SOT the way the repo already describes it: a render plus an envelope.

The sprint owns only:

1. sprint_start
2. sprint_end
3. sprint_goal
4. deliberate deviations from roadmap priority for this one window
5. the review notes that feed status reports and decisions at close

Everything else is derived from existing sources or mirrored back into them.

Part 1: Working guide for Bifrost and CDP

This part is for engineers, QA, EMs, PMs, TPMs, and anyone working from the Bifrost/CDP sprint-goals documents.

1. What changes

Before	Goal-led Kanban transition
Sprint backlog is treated as a fixed work-item commitment.	Sprint doc is a starting ready queue for a goal window.
New work entering mid-window is treated as exception handling.	New work can enter when it helps deliver the goal or unblocks higher-priority work.
Capacity fit can decide what is allowed into the window.	Capacity fit is advice; priority, readiness, blockers, and goal impact decide what to pull.
Jira board can become the planning source.	Jira mirrors the repo plan and the work actually being executed.
Sprint review compares original list vs done.	Sprint review records goal progress, pulled work, blockers, and decisions back into the repo.

2. What does not change

• The roadmap remains the priority source.
• The sprint doc must not become a second roadmap.
• The sprint doc must not redeclare staffing, effort, or priority as new truth.
• Task-breakdowns and RFCs remain the implementation contract.
• Jira tasks are still created for execution tracking.
• Blocked means a real external, governance, design, or cross-squad gate, not "the sprint is full."
• Work still needs PR/RFC/PRD/test evidence before it is considered done.

3. How to work from the sprint SOT

1. Open the current sprint-goals doc:
   • Bifrost: sprints/2026-07-06-sprint-01.md
   • CDP: ../../cdp/delivery/sprints/2026-07-07-sprint-01.md
2. Find your queue.
3. Start from the first item that is ready.
4. Read the linked initiative README, PRD, RFC, task-breakdown, and timeline before implementing.
5. If an item is blocked by a real gate, record the blocker and move to the next ready item.
6. If you discover work needed to deliver the goal, pull it in and make it visible in the sprint doc and Jira.
7. If the pull changes priority only for this window, record it in the sprint's deviations section.
8. If the pull changes priority beyond this window, update the roadmap Priority table or write a delivery decision record.
9. At close, write progress into dated status reports, reconcile actual pulled work against capacity/load and forecast movement, then mirror the latest progress into README and roadmap rollups where the delivery doctrine requires it.

4. How to decide whether to pull work

Pull the work when it helps the goal:

• it directly delivers the sprint or monthly goal;
• it clears a blocker for a higher-priority item;
• it protects a hard commitment date, customer promise, billing risk, security risk, or partner risk;
• it fixes a bug required before the goal can ship;
• it creates the missing PRD/RFC/task-breakdown/test/Jira structure needed to make implementation ready.

Do not pull the work when:

• it is unrelated to the current goal;
• it silently changes roadmap priority;
• it duplicates truth already owned by roadmap, capacity, README, RFC, task-breakdown, or Jira;
• it asks the team to invent scope without source docs;
• it creates Jira noise with no execution value.

Related work can still be the wrong pull when it makes the goal harder to finish. The deciding question is not "is there room in the sprint?" or "can an AI agent start this?" It is:

Does pulling this now move the goal forward better than finishing, reviewing, or unblocking the higher-priority work already in the queue?

If the answer is no, leave it in the queue or Jira backlog even if it is technically ready.

5. Jira use

Jira is still needed, but it is not the planning source of truth.

Use Jira to track the work the team is actually executing. The repo remains the planning and traceability source:

• initiative to Epic is recorded in the initiative README as jira_epic;
• sprint queues point to initiative Epics and task-breakdowns;
• Jira tasks should trace back to the work they implement;
• bugs discovered while pursuing the goal should link to the relevant Epic;
• do not trigger automated PRD-to-Jira sync for these initiatives unless the team deliberately reconciles the repo's manual Jira convention first.

6. AI-assisted execution

AI is one reason this approach exists, but the sprint doc should not become an AI orchestration document. The repo already makes work agent-readable through PRDs, RFCs, task-breakdowns, and the sprint queue.

For AI-assisted work, keep the lightweight rule already present in the sprint docs:

• point the agent at the sprint doc;
• choose the relevant queue item;
• read the linked task-breakdown/RFC/PRD before writing code;
• create or update Jira only when it mirrors real execution work;
• verify output against the source docs and tests.

An engineer may run multiple AI agents when useful. That does not require extra sprint metadata. The practical control is whether the work is still tied to the goal and source docs, not whether the repo has a new tracking system.

7. Why this does not add a WIP field

A common critique of this model is that removing the sprint cage should be balanced by a WIP limit. That critique is directionally useful, but the proposed fix does not fit this repo.

This repo's sprint layer has a narrow contract: the sprint owns the envelope, the ready-queue render, one-window deviations, blockers, and review. It must not redeclare priority, effort, staffing, or a new process control as fresh truth. Adding wip_limit_per_engineer would create another manual field that the delivery linter does not understand, the active sprint template does not require, and the team would have to maintain without improving the core source-of-truth flow.

The control in this repo is deliberately lighter:

• roadmap Priority decides order;
• task-breakdowns/RFCs decide readiness;
• blockers decide what can be skipped;
• capacity marks fit and likely carry-over, but does not block pull;
• the sprint deviations section explains one-window reorder decisions;
• sprint close reconciles actual progress, load, forecast movement, and durable decisions back into status reports, roadmap, and ADRs.

This still guards against "start everything" behavior, but it does so by making pull decisions answerable to the goal and the source docs rather than by adding another field to maintain. In an AI-assisted workflow, the more useful constraint is not a numeric cap on started items; it is whether the work is goal-relevant, source-grounded, reviewable, and worth doing before the higher-priority queue items.

8. Where in-progress visibility belongs

A smaller version of the WIP critique is to add In progress to the sprint queue's Status column. That avoids a new frontmatter field, but it still moves live execution tracking into the sprint doc. This repo draws that boundary deliberately: daily task and sub-task tracking stays in Jira, while the sprint doc is the reasoned plan, queue, blocker map, and review record.

So the sprint Status column should stay about readiness and blockers, not become a live state machine. Use it to say whether a queue item is ready, blocked, author-only, partially ready, or waiting on a named gate. Use Jira and PRs to see what is actively in progress.

The visibility split is:

• Sprint doc: what should be pulled, in what order, and what is genuinely blocked.
• Jira: what is currently being worked, reviewed, reopened, bugfixed, or carried.
• PRs/test evidence: whether implementation is actually reviewable or done.
• Status reports and sprint review: what moved, what changed forecast/load, and what decisions should persist.

This keeps the repo fast. The sprint SOT does not need row-by-row live updates every time an engineer or AI agent starts work. If over-pulling becomes a concern, inspect Jira and open PRs against the sprint queue; do not turn the sprint doc into the board.

9. Roles

Role	Responsibility
PM	Owns the goal, priority trade-offs, and stakeholder expectation.
EM	Owns execution sequencing, staffing reality, unblock decisions, and engineering quality.
TPM or delivery owner	Keeps roadmap, sprint doc, capacity, status reports, forecast movement, and decisions coherent.
Engineer	Works from the ready queue, pulls goal-relevant work, creates Jira tasks when useful, and verifies implementation against source docs.
QA	Follows goal priority, makes release risk visible, and records evidence for shipped goals.

Part 2: Explanation for broader Mekari readers

This part is for readers outside Bifrost and CDP who need to understand the shift.

What Bifrost and CDP are trying

Bifrost and CDP are not simply renaming Scrum to Kanban. The teams are deliberately testing a transition model:

• keep a clear goal window;
• stop treating the initial work-item list as a cage;
• use the repo sprint document as a lightweight source of truth;
• keep Jira aligned with execution;
• write actual progress and decisions back into the delivery layer.

This lets the team move faster when AI-assisted delivery changes the sequence of work during the window.

Why this is not pure Kanban yet

Pure Kanban usually works through continuous flow and a stable board. Bifrost and CDP still need a visible goal window because commitments, dependencies, QA focus, and stakeholder communication are still organized around goals. Some goals may be monthly; some may fit a two-week window. The key change is that work items under the goal remain flexible.

What stakeholders should expect

Stakeholders should expect less ceremony, not less accountability.

The team may pull new work during the window. The reason should be visible when it matters:

• the sprint doc shows the current queue and blockers;
• Jira shows the execution items;
• roadmap Priority changes when the priority really changes;
• status reports record progress and risks;
• decisions record durable trade-offs.

The question changes from:

Did we complete the exact list we guessed at planning?

to:

Did we make visible, goal-aligned decisions that moved the outcome forward?

Success signals

This transition is working when:

• team members know the goal they are protecting;
• engineers and QA can start from one sprint SOT;
• new Jira tasks exist because they help execution, not because a ceremony requires them;
• blockers are visible and owned;
• mid-window changes are not hidden in chat;
• sprint review updates the existing delivery docs instead of creating a separate report;
• stakeholders can see why the team changed course.

Anti-patterns

• Adding new metadata that duplicates roadmap, capacity, README, RFC, task-breakdown, or Jira.
• Treating the sprint doc as a second roadmap.
• Treating Jira as the source of priority.
• Freezing the sprint backlog while calling the process Kanban.
• Pulling unrelated work just because someone or an AI agent can start it.
• Using AI speed as a reason to skip PRD/RFC/task-breakdown/test evidence.
• Starting many goal-adjacent items while higher-priority ready work sits unreviewed, unfinished, or blocked without an owner.
• Leaving priority changes only in Slack or meeting notes.

Working agreement

For the transition period, Bifrost and CDP will use these rules:

1. Every window has a written goal.
2. Every window has one sprint SOT in the repo.
3. The sprint SOT owns only the envelope, queue render, deviations, blockers, and review.
4. The initial queue is a plan, not a contract.
5. New work can enter when it supports the goal, clears a blocker, protects a commitment, or makes implementation ready.
6. Capacity fit is sequencing advice, not an entry gate.
7. Roadmap priority remains canonical unless a documented one-window deviation is made.
8. Persistent priority changes move back to roadmap or a delivery decision record.
9. Jira mirrors execution work and stays aligned with the repo.
10. Sprint close writes progress, actual pulled work, load/forecast movement, risks, and decisions back into the existing delivery layer.

Manual checks during transition

The delivery linter now reconciles delivery/sprints/ against the roadmap Priority table and the initiative READMEs (lint-delivery.mjs CHECK GROUP I: priority/epic drift, queue order, envelope and Jira-identity validity) — so items 1–2 below are machine-checked: run npm run lint:delivery at sprint open and close instead of eyeballing them. The remaining manual checks cover what the linter cannot see (free prose, and the live board — which is sprint:reconcile's job):

1. Compare sprint queue order against the roadmap ## Priority table.
2. Confirm any deliberate reorder appears in ## Deviations from roadmap priority.
3. Search the relevant delivery folder for any resequenced initiative or assignee and reconcile the obvious mirrors by hand.
4. If over-pulling is a concern, compare Jira in-progress work and open PRs against the sprint queue; keep the sprint doc as the queue/blocker source, not the live board.
5. Run the available repo/system checks for frontmatter and delivery drift when the local system checkout exposes them.
6. At close, update dated status reports for initiatives that moved, including forecast or commitment-risk changes caused by what was actually pulled.

This is intentionally a check, not another planning gate. It protects the repo's source-of-truth loop without slowing the team down at pull time.

Naming

Use goal-led Kanban transition when describing the operating model.

Avoid saying the team has fully moved to pure Kanban. Also avoid saying this is a traditional sprint. The team is keeping goal windows while removing the fixed work-item cage.

Acceptable shorthand inside the team:

• goal-led Kanban
• monthly goal window
• sprint-goals SOT
• not-a-cage sprint

Open questions to revisit

These should be revisited after the first few windows:

• Should the goal window remain two weeks, move to monthly, or vary by initiative risk?
• Should Bifrost and CDP keep Jira sprint boards, or move to a Kanban board with goal labels?
• Which fields should be standardized in Jira for goal linkage?
• Should delivery/sprints/ be renamed later if the team fully exits sprint terminology?
• What minimum review evidence is required before a goal is considered delivered?
• What sprints/ drift checks should be added to lint-delivery.mjs, and what should remain manual?