AI-Ready Backlog

I designed a new unit of product work from scratch, structured for AI instead of humans, and one module’s worth replaced what would’ve been 150+ traditional tickets. The Capability Brief is what product documentation looks like when AI is the reader.

Role:: Strategist
Dates:: 2026
Client:: Captivated

The Challenge

We’d adopted a 3-point story limit to improve velocity. It worked for human developers. It wasn’t going to work for AI.

The Problem with Stories

Stories aren’t hard to write. That was never the issue. The problem is what they’re built for: narrative framing, human interpretation, implied context. AI needs something different entirely. Boundaries, rules, constraints, dependencies, edge cases. Feed it a backlog of stories and you get noise. Feed it structured context and you get something it can actually build from. I researched where high-performing AI teams were heading and designed a better unit of work.

Two Problems, One Solution

The backlog wasn’t the only gap I was looking at. Captivated had a documentation problem too. Readme files were sparse, code comments were inconsistent, and onboarding new developers meant a lot of tribal knowledge transfer that shouldn’t have been necessary. I didn’t set out to solve both problems at once, but the more I thought about what good AI-ready documentation looked like, the more I realized the same structured format could feed both. A Capability Brief written well enough for an AI coding tool to build from is also written well enough for an AI to generate readme files and code comments from. One document, two problems addressed.

Where These Documents Live

I built the Capability Briefs in Confluence because that’s where the team already worked. But even while writing them, I could see that wasn’t the right long-term home. Documentation that developers need during a build belongs close to the code, not in a wiki they have to context-switch to reach. The right place for a Capability Brief is the repository itself, alongside the code it describes. Getting there was a later problem, but the brief format was designed with that destination in mind.

The Bigger Shift

The format was also a strategic bet on where the industry was heading. AI-assisted development was moving fast. Teams that figured out how to give AI structured context were going to outpace teams still handing it a backlog of disconnected stories. I wanted Captivated to be ahead of that curve, not catching up to it.

Finding the Alternatives

Before designing anything, I surveyed the landscape. I took the question to ChatGPT and the broader product community to understand how high-performing AI teams were approaching documentation. The pattern was consistent, outcome-driven development, capability-based backlogs, and product briefs over story queues. The teams shipping fastest weren’t writing more stories. They were writing better context.

That research didn’t produce a deliverable. It produced a direction.

A Different Kind of Design Problem

The Capability Brief is a designed artifact, it just doesn’t have a UI. The design decisions were about information architecture, document structure, and audience. The primary reader wasn’t a human developer, it was an AI coding tool. That single constraint changed everything about how the format was built.

Writing for AI means writing without ambiguity. No implied context, no assumed knowledge, no narrative shortcuts. Every rule has to be stated explicitly. Every edge case has to be named. Every constraint has to be declared, including what’s out of scope, because AI builds confidently in whatever direction you point it and a missing boundary is an invitation to go somewhere you didn’t intend.

The Structure

Each Capability Brief follows eight sections, in this order for a reason:

Problem — what’s broken or missing, and why it matters
Outcome — what the system must be able to do
Users — who’s affected and how
Functional Rules — explicit behaviors the system must honor
Edge Cases — failure states, race conditions, unexpected inputs
Constraints — what must not break, what’s explicitly out of scope
AI Implementation Context — architecture, dependencies, data model, key rules
Delivery Mapping — epics and vertical slices

The AI Implementation Context section is what makes this format different from anything that came before it. It explicitly tells developers and AI coding tools what the system depends on, what rules are non-negotiable, and how the data model should be structured. In Captivated’s case, that meant documenting the React frontend, Ant Design component library, and Rails backend as fixed constraints, so nothing got designed or generated in a vacuum. That section alone eliminated entire categories of questions before they were ever asked.

A Capability Brief — Capability Briefs are written for AI, not humans

A New Way of Working

The format took some getting used to. But once the team was working from briefs instead of a backlog of 3-point stories, the difference was noticeable. Developer handoffs were smoother. Fewer questions came back during implementation. Edge cases that used to surface mid-sprint were already being identified before a line of code was written.

The bigger shift was cultural. With a brief in hand, the dynamic became: AI writes the first pass, humans refine it. That’s a healthier model than asking AI to interpret a list of disconnected stories and hope it fills in the gaps correctly.

The Numbers

The first module, Authentication, produced 6 Capability Briefs covering identifier-first flow, authorization, session management, SSO, MFA, multi-org switching, and quick user switching. A traditional story approach for the same scope would have produced 150+ tickets, with far less coverage of edge cases, compliance constraints, and system dependencies.

The hard decisions got made upfront, not mid-sprint when they’re expensive. That’s the whole point. Those 6 Capability Briefs didn’t just prove the format. They became the foundation for the next project: Beyond the Login.