It's the opposite. In traditional agile, developers are dependent on the PO for context — they write a vague story, the developer has questions, they wait for a conversation. IDD front-loads that context into artifacts so developers can make decisions independently. The upfront investment in defining Intentions, Expectations, and Specs pays off as fewer interruptions, less rework, and faster execution. The measure of success is that a developer picks up a Spec and builds the right thing without a single clarification conversation.
IDD replaces specific agile practices (sprints, story points, velocity, the Epic–Feature–Story hierarchy) but preserves agile values — iterative delivery, working software, responding to change, and collaboration. Think of it as agile's next evolution for a world where AI changes the build equation.
Spec-Driven Development (SDD) focuses on the spec-to-code pipeline — how to give AI agents better instructions. IDD extends this by providing upstream layers (Product, Intentions, Expectations) that determine what should be specified and why, plus a process wrapper (flow model, roles, ceremonies, metrics) that governs how work moves through a team. IDD is compatible with SDD tools like GitHub Spec Kit, Kiro, and Tessl.
No. You can start with Markdown files in a Git repo and a simple Kanban board. The templates in this repo are designed for that. Purpose-built tooling helps at scale but isn't required for a pilot.
The completeness checklist verifies that every Spec block is present — it cannot tell whether the content is any good. The gap-check gate closes that hole: before execution, a reviewing agent simulates being the implementer and reports every point where it would have to guess — ambiguous Expectations, contradictions between blocks, filler edge cases, unverifiable validation criteria. Findings are classified as Blockers (implementations would diverge wrongly) or Warnings (implementations would be inconsistent), and execution requires ready plus a current passed gap-check with zero unresolved Blockers and Warnings. All eleven readiness items include actual human peer review; AI review cannot supply it. Crucially, the gap-checker never fixes anything: gaps are resolved in the Spec by its author, so the Spec remains the complete contract. In practice, the gate's biggest catches are confident factual errors — a Spec describing a codebase reality that doesn't exist — which no presence-based checklist can see. The gate also performs a coverage sweep — reporting files that reference the changed concepts but are owned by no Deliverable — because the most expensive gaps are often omissions, not defects: a published document that references a concept you renamed but was never assigned to any Spec will silently diverge from the release.
An author-accepted coverage omission remains visible as resolved only after the reviewer confirms its reason leaves no unmet validation dependency. Substantive content warnings cannot be waived by acknowledgment. Failed or interrupted checks invalidate old success; a prior report alone never authorizes a build. See the lifecycle contract.
The artifact an executing agent produces when it finishes a Spec: a restatement of the Boundaries it worked under, a self-verification table covering every Expectation (with its edge cases), every Boundary, and every Deliverable, and a mandatory "spec gaps encountered" section listing each point where the Spec was ambiguous or silent — even when the agent resolved it sensibly. That last section is the feedback loop: it tells Spec Authors exactly where the next Spec needs to be sharper.
IDD's artifact hierarchy (Product → Intentions → Expectations) is valuable even without AI agents — it provides clearer requirements and better acceptance criteria than Epics/Features/Stories. The Spec layer becomes essential once you're using AI agents, but the upstream layers stand on their own.
IDD uses Complexity ratings on Expectations (Low/Medium/High) as risk indicators, not effort estimates. Prioritization is driven by Intention priority and value, not estimated effort. Capacity is managed through WIP limits, not sprint commitment.
The Scrum Master role evolves. The facilitation skills remain valuable (running Spec Reviews, Flow Syncs, and Retros). The process enforcement role shifts toward ensuring spec quality and flow health. Some Scrum Masters may evolve into Spec Authors if they have the technical fluency.
Yes, during a transition. A team can adopt the IDD hierarchy (Product → Intentions → Expectations → Specs) while still working in sprints. Over time, as the team builds confidence, they can transition to continuous flow with WIP limits.
At the Intention level, dependencies are explicit (Intention A depends on Intention B). At the Spec level, the build order is managed through the Flow Board — a Spec that depends on another should not enter Ready until its dependency is in Done or near-Done. For MVP, this is managed manually; tooling can enforce it later.
IDD actually strengthens compliance posture. Every Spec has a defined author, a completeness checklist, a review gate, and a validation record. Phase transitions are logged with timestamps, users, and override reasons. This creates a more auditable trail than typical agile processes.
Not necessarily. On smaller teams, the Spec Author function can be shared among senior developers, BAs, or tech leads. The key is recognizing it as a skill that needs development, not assuming anyone can write a good Spec without practice.