A heuristic for agent-executed work · proposed in Chapter 4 of Agentic SDLC
PRECISE
Precise · Reviewable · Evidenced · Complete · Independent · Small · Executable
The specification is explicit enough that an agent can execute against it without resolving material ambiguity through guesswork.
The specification, design, and implementation can be reviewed at the appropriate level of abstraction by a human. This replaces Negotiable: the conversation moves from "what should we build?" to "does this specification capture what we intended?"
The deliverable produces evidence that it was completed correctly: test results, verification output, change descriptions.
The specification includes acceptance criteria, error handling, constraints, and non-functional requirements — not just the happy path.
The deliverable can be verified and deployed independently of other in-progress work.
The deliverable can be specified precisely and verified completely as a unit.
The specification is structured such that an agent can act on it directly — not a vague description, but a directive that maps to concrete actions.
PRECISE is the heuristic proposed in Chapter 4 of Agentic SDLC as the successor to INVEST — Bill Wake's 2003 checklist for user stories. A good story, Wake argued, should be Independent, Negotiable, Valuable, Estimable, Small, and Testable. INVEST became one of the most widely adopted heuristics in Agile development. It is taught in Scrum certifications, printed on posters in team rooms, and embedded in the mental model of product owners and developers worldwide.
For human teams writing human-sized work items, it works. But INVEST was designed for an execution model in which a human developer reads a story, discusses it with a product owner, uses professional judgment to fill in the gaps, and implements it. When the executor is an AI agent, several of INVEST's properties require reconsideration — and one of them, Negotiable, may be actively harmful.
Negotiable: the most dangerous property
Negotiable means that a user story is not a detailed specification. It is an invitation to a conversation. The story captures intent at a high level, and the details are worked out between the product owner and the development team during implementation. This made sense when human communication was the bottleneck and writing detailed specifications was expensive: a five-minute conversation was cheaper than a five-page spec.
Now consider an agent picking up a story that says: "As a user, I want to reset my password so that I can regain access to my account." Should the reset link expire? After how long? Should the new password meet complexity requirements? Should the system log reset attempts? Should there be a rate limit?
A human developer would ask these questions during the negotiation conversation. An agent, absent that conversation, will guess. Some of its assumptions will be reasonable; some will be wrong. And because the agent does not know which assumptions are wrong, it will confidently produce an implementation that may not match what the product owner intended. This is not a failure of the agent. It is a failure of the specification. The problem is that inference is not negotiation.
Flexibility does not require ambiguity.
A specification can be adaptable — capable of evolving as requirements change — without being ambiguous. The problem with Negotiable is not that it values flexibility. The problem is that it equates flexibility with leaving things unsaid. In a human-execution model, leaving things unsaid was efficient; the conversation would fill them in. In an agentic model, leaving things unsaid means leaving them to the agent's inference. And inference is not the same as understanding.
The deeper principle
Humans negotiate because communication is expensive. Machines need specifications because execution is cheap.
When communication is the bottleneck — when the product owner's time is scarce, when meetings are costly, when writing documentation feels like overhead — the rational strategy is to minimize communication. Write less. Talk more. Fill in the gaps through conversation.
When execution cost collapses — when agents can produce code in seconds — the rational strategy shifts. The bottleneck is no longer communication between humans. It is the fidelity of the specification the agent executes against. A precise specification produces a correct implementation. An ambiguous specification produces a fast but incorrect implementation. In this world, investing in specification quality is not overhead. It is leverage.
The rest of INVEST, reconsidered
- Independent — still valuable, but the emphasis shifts. It mattered for enabling parallel human work. For agents it matters for verification: an independent deliverable can be verified independently, and its deployment doesn't risk breaking something else that is half-finished.
- Valuable — unchanged. If anything, more important: when execution is cheap, the temptation is to implement everything. But code is a liability, not an asset. Every line that doesn't deliver value must still be maintained, tested, and understood.
- Estimable — declining relevance. Execution is elastic; you can run more agents in parallel. The limiting factor is not human hours but specification quality. The question shifts from "how long will a human take?" to "is this specification clear enough for an agent to execute reliably?"
- Small — needs redefinition. The relevant measure is not whether the work fits in a two-week window. It is whether the work can be specified precisely and verified completely within a single execution unit.
- Testable — increasing importance. It becomes the single most important property: the property that constrains autonomous execution. Testable specifications are the interface between human intent and machine verification.
From INVEST to PRECISE
The difference between the two heuristics is the difference between optimizing for human-execution coordination and optimizing for agentic-execution governance. INVEST helps a team answer: "Is this story ready for a human to work on?" PRECISE helps a team answer: "Is this specification ready for an agent to execute reliably — and for a human to review meaningfully?" They are different questions, and they deserve different heuristics.
| INVEST property | What changes when an agent executes | PRECISE property |
|---|---|---|
| Negotiable | Ambiguity becomes guesswork delegated to an agent that cannot ask clarifying questions. | Precise · Reviewable |
| Valuable | Unchanged — and more important, because cheap execution tempts overproduction. | Valuable |
| Independent | Emphasis shifts from parallel human work to independent verification and safe deployment. | Independent |
| Estimable | The question shifts from human hours to specification clarity. Estimable gives way to Specifiable. | Specifiable (through Precise · Executable) |
| Small | Redefined: specifiable precisely and verifiable completely as a unit. | Small |
| Testable | Becomes the single most important property — the one that constrains autonomous execution. | Evidenced · Complete |
The bottom line
INVEST is not useless. It is a heuristic created for a particular execution model, and it works well within that model. It should not be treated as a universal law of software development — and it certainly should not be applied without modification to agentic execution.
Every practice has assumptions. Every heuristic was created in a context. The question is whether the context still applies.