Methodology Comparison

Methodology Comparison

Three approaches to organizing software work come up repeatedly:

1. Classic DevOps planning — the Azure DevOps (ADO) hierarchy of Epics to Features to Stories to Tasks.
2. Spec-Driven Development (SDD) — the Spec Kit flow this repository uses.
3. Research-Plan-Implement (RPI) — the autonomous loop from microsoft/hve-core.

They are often discussed as competitors. They are better understood as operating at different altitudes. This page compares them and shows how they compose.

TL;DR

	Classic DevOps (ADO)	Spec-Driven Development	RPI (HVE-core)
Altitude	Portfolio and program	Feature	Single task or change
Core unit	Work item (Epic / Feature / Story / Task)	Specification	A task to execute
Source of truth	The work-item tracker	spec.md + constitution	The codebase + research findings
Primary artifacts	Boards, backlogs, sprints	spec, plan, tasks (in repo)	Research doc, plan, changes log (in .copilot-tracking/)
Who authors	PO / BA / team	Human states intent, agent expands	Largely autonomous agent, human supervises
Lifespan of artifacts	Long-lived, audited	Long-lived, versioned with code	Working memory, often disposable
Best for	Coordination, reporting, compliance	Defining and building features	Executing changes in existing code
AI-native?	No (humans drive tooling)	Yes (agent-executed)	Yes (agent-orchestrated)

1. Classic DevOps: Epics to Features to Stories

The traditional Azure DevOps / Agile model organizes work as a hierarchy of work items in a tracker.

flowchart TD
    E[Epic\nlarge business outcome] --> F1[Feature\nshippable capability]
    E --> F2[Feature]
    F1 --> S1[User Story / PBI\nsmall increment + acceptance criteria]
    F1 --> S2[User Story]
    S1 --> T1[Task\nengineering step]
    S1 --> T2[Task]
    S2 --> B1[Bug]

Loading

How it works. Product owners define Epics and Features; the team breaks Features into User Stories (or Product Backlog Items) with acceptance criteria, then into Tasks. Work flows through sprints, boards, and queries, with velocity, burndown, and capacity for forecasting.

Strengths (classic DevOps)

• Mature and universally understood; deep tooling in Azure Boards and Jira.
• Excellent at coordination across many teams and a whole portfolio.
• Strong traceability and reporting for audit, compliance, and governance.
• Predictable cadence and capacity planning.

Limitations (classic DevOps)

• Work items describe what loosely. The real design and specification usually live somewhere else (a doc, a thread, someone's head), so the tracker and the code drift apart.
• Acceptance criteria are rarely machine-executable.
• Ceremony-heavy for small changes.
• Not AI-native: an agent cannot meaningfully act on an Epic. The hierarchy organizes humans, not implementation.

Altitude: portfolio and program. This is about what to build, when, and by whom across teams.

2. Spec-Driven Development: the specification is the source of truth

SDD operates one level down, at the feature. Intent is captured as a versioned specification, and the workflow expands it into a plan, tasks, and code. (See Spec-Driven Development for the full loop.)

flowchart LR
    C[Constitution] --> SP[specify\nspec.md]
    SP --> CL[clarify]
    CL --> PL[plan\nplan + research + data-model + contracts]
    PL --> TK[tasks\ntasks.md]
    TK --> IM[implement\ncode]
    IM -.iterate.-> SP

Loading

How it works. A human writes intent in product terms; the agent generates structured artifacts that live in specs/<feature>/; a constitution enforces guardrails at planning time; the agent implements directly from tasks.md.

Strengths (SDD)

• Intent is explicit, testable, and versioned with the code.
• Decisions and rationale are durable (research.md, plan.md).
• The constitution gate enforces non-negotiables automatically.
• AI-native: artifacts are executable by the agent; the human steers intent.
• Tight spec-to-test-to-code traceability (this repo's "exactly one featured episode" rule flows from requirement to test to implementation).

Limitations (SDD)

• Weaker at portfolio-level coordination across many teams.
• Less built-in reporting and forecasting than a work-item tracker.
• Newer; conventions still maturing.
• Quality depends on the agent and on the discipline of writing good specs.

Altitude: the feature. This is about capturing intent precisely and turning it into a working, guarded implementation.

3. RPI: Research-Plan-Implement (HVE-core)

RPI operates one level further down, at the individual task or change, and is designed for autonomous execution inside an existing codebase. It comes from microsoft/hve-core and runs as a loop of specialized agents.

flowchart LR
    R[Research\nTask Researcher] --> P[Plan\nTask Planner]
    P --> I[Implement\nTask Implementor]
    I --> RV[Review\nValidators]
    RV --> D[Discover\nnext work items]
    D -.continue.-> R

Loading

How it works. The flow is Research to Plan to Implement to Review to Discover:

• Research (task-research) — the Task Researcher investigates the actual repository, evaluates alternatives, and produces an evidence-based research document.
• Plan (task-plan) — the Task Planner turns research into an implementation plan plus a planning log.
• Implement (task-implement) — the Task Implementor executes the plan iteratively, recording a changes log, with optional phaseStop / stepStop controls for human checkpoints.
• Review (task-review) — validator agents (Plan Validator, Implementation Validator, RPI Validator) check the work against the research and plan.
• Discover — the loop surfaces follow-up work items to feed the next cycle.

Working artifacts live under .copilot-tracking/ (research/, plans/, changes/) and act as the agent's structured memory across a long autonomous run.

Strengths (RPI)

• Evidence-based: research is grounded in the real codebase before planning.
• Built-in review and validation phase, not just generation.
• Autonomous but supervised via stop controls; ideal for long-running tasks.
• Discovers follow-up work, chaining tasks together.
• Excellent for brownfield changes in a large existing repository.

Limitations (RPI)

• Task-scoped, not a product or portfolio process.
• Tracking artifacts are working memory (frequently disposable / ignored), not a long-lived product specification.
• Needs a capable agent and clear guardrails to stay on track.

Altitude: the task. This is about executing a specific change correctly, with research and self-review, inside code that already exists.

How they compose

These are not mutually exclusive. They nest cleanly by altitude:

flowchart TD
    subgraph ADO[Classic DevOps - portfolio]
      EP[Epic] --> FE[Feature] --> ST[User Story]
    end
    subgraph SDD[Spec-Driven Development - feature]
      SPEC[spec.md] --> PLAN[plan.md] --> TASKS[tasks.md]
    end
    subgraph RPIB[RPI - task]
      RES[Research] --> PLN[Plan] --> IMPL[Implement] --> REV[Review]
    end
    ST -->|a Story becomes a feature spec| SPEC
    TASKS -->|each task runs the loop| RES

Loading

A realistic combined workflow:

1. Azure DevOps holds the Epic, Feature, and Story for portfolio visibility, reporting, and cross-team coordination.
2. When a Story is ready to build, SDD captures it as a durable feature specification, generates the plan and the dependency-ordered tasks, and enforces the constitution.
3. For each non-trivial task, RPI runs a research-plan-implement-review loop inside the existing codebase, producing validated changes and discovering follow-up work that flows back up as new Stories or spec updates.

Choosing for a given situation

If you need to...	Reach for
Coordinate many teams, report to stakeholders, plan releases	Classic DevOps (ADO)
Define a new feature and capture intent as executable, versioned spec	Spec-Driven Development
Execute a specific change in an existing codebase with research and self-review	RPI (HVE-core)
Do all of the above on a large program	All three, nested by altitude

This repository's choice

spec-podcast-site is a greenfield feature built end to end with SDD. It is small enough that portfolio-level ADO planning would be overhead, and it was built fresh rather than changed in place, so the full RPI brownfield loop was not the focus either. SDD fit the altitude of the work: one clear feature, intent worth capturing, and an agent doing the implementation against a constitution.

Continue to Architecture to see what that produced, or revisit Why Spec-Driven Development for the motivation.