Agile as Code

Agile as Code (AaC) checks agile artifacts — PRDs, epics, user stories — into source control instead of tracking them in tools like Jira or Linear. By now most people have heard of Infrastructure as Code (IaC) and this idea is similar. The value of checking in your infrastructure, allowing for tracked changes and no more messy one-off scripts, is usually immediately recognized.

Ultimately we want to drive Functional Requirements into real features. What does this mean?

Here is an example of a functional requirement for this site snowboardcto.com that was originally defined in a Product Requirements Document (PRD.md):

From the PRD:

- **FR-20 — RSS feed.** At `/rss.xml`, conformant to RSS 2.0, includes all
  non-draft posts in reverse-chronological order.

We organize Functional Requirements into epics. Here is that same FR-20 detailed in an epic:

From the epic:

### Epic 3: Discoverability

Visitors who share a post on social media see a branded OG card; subscribers
who add `/rss.xml` to a reader get reverse-chronological updates.

**FRs covered:** FR-20

Now let’s look at it from the user story perspective:

From the user story’s Acceptance Criteria:

## Acceptance Criteria

1. Given Epic 2 left `@astrojs/rss` out of `package.json`, when this story
   lands, then `package.json` `dependencies` (NOT `devDependencies`) contains
   `"@astrojs/rss": "^4.0.x"`

Let’s dive a little deeper here to understand what is actually going on. The user story carries a specific formatting that I find interesting:

• Given this statement
• when these conditions happen
• then this should be the result.

That is how an agent breaks this down into a simple feature. It starts as a functional requirement. Epics scope it, user stories shape it into Given/When/Then, and an agent takes it from there. All checked into source control. No external system to track completion or get sign off from stakeholders. Progress is tracked by the code itself.