Every story should be able to answer three questions: whose confidence am I earning, what tier am I earning it at, and how will we know when it’s earned?

The Development Backlog℠ is the execution layer of the framework. It takes the committed objectives from the Alignment Ceremony and turns them into the epics, stories, tasks, and bugs a team can actually build — with mechanical traceability back through the chain. A story links to an epic. An epic links to an objective. An objective is placed at an Impact Point tier. Nothing floats.

The authoring discipline here matches the Objectives Backlog’s discipline: stories are written as user problems, not implementation specifications. The persona and voice selectors enforce the distinction between want (creating value beyond what users have elsewhere) and need (reaching parity with what they already have somewhere else). Acceptance criteria are observable outcomes with units and thresholds, not implementation checklists.

The Development Backlog is not a replacement for your delivery tool. It’s the authoring and traceability surface that feeds it. Author and connect the work here; run the sprint in Jira, Linear, or ADO; export via CSV when ready.

Two things happen when work is traceable to an objective. First, the retrospective becomes meaningful — you can see not just what shipped but what confidence it was supposed to advance and whether the indicators moved. Second, and more immediately: the team always knows what to pull next. There can be a thousand items in the backlog, but the structure surfaces the work that moves the active objectives’ key measures — and keeps the team pulling from that set until those measures are met.

This applies to everything: new features, maintenance work, bug fixes, infrastructure tasks. The framework doesn’t distinguish between "strategic" and "operational" work — it asks the same question of each: which objective does this advance, and which tier of user confidence does that objective belong to? A bug fix that addresses a Reliable-tier gap is as strategic as a new capability. The traceability chain makes that visible and keeps the team methodically building and maintaining confidence rather than chasing whatever was most recently requested.

The traceability chain — story → epic → objective → tier — is also the audit trail that makes retrospectives meaningful. When you review what shipped last quarter, you can see not just what was built but what confidence it was supposed to earn and whether the indicators moved. The chain makes learning systematic rather than anecdotal.

• Author epics linked to committed objectives, with stopping conditions that make deliberate incompletion a principled choice rather than an exception
• Write stories with personas, want/need voice, and measurable acceptance criteria
• Import existing backlogs via CSV with smart field mapping from Jira, Linear, and ADO schemas
• Share read-only links with stakeholders who don’t need full platform access
• Export to your delivery tool when ready to run the sprint

Product managers and their engineering partners building out sprint-ready work. Teams that want to maintain traceability without abandoning the delivery tools they already use.

The Development Backlog is where strategy becomes tactics. It reads objectives from the Objectives Backlog, inherits tier context from the Impact Point, and treats stamped Five What-Ifs scenarios as the projection basis for each epic. When the team closes the loop — measuring whether indicators moved after shipping — the cycle starts again at the Capability Spectrum.