Agentic Scrum, Part 1 of 5: The Product Owner Is Not a Vending Machine

Agentic Scrum, part 1. 

My developers consume user stories faster than any product owner can write them. A story that used to fill a sprint now takes an afternoon, because a coding agent writes the code, the tests and a very confident commit message. The backlog looks like a fridge the night before a vacation. Some mustard, one lonely epic, and a login story that has been there since spring.

Asking the product owner to write more stories treats the symptom. When coding is nearly free, the scarce things are a clear statement of what to build and a trustworthy way to know it was built correctly. So I stopped feeding agents stories and started feeding them specifications, with humans owning the decision at every gate.

The pipeline

The product owner describes business value and nothing else. Who has the problem, what changes for them, how we will recognize success. No field lengths, no button colors. Developers translate that into technical requirements: constraints, interfaces, data volumes, the things that break at 40,000 records. A specification agent turns those requirements into agentic specs written for the coding agent. Developers validate the specs, and only then does the development loop start.

Once code exists, a QA agent reads the specs and the generated code and drafts test specifications. QA engineers and developers validate those first, and only after approval does the QA agent write the actual tests. In parallel, a security and compliance agent checks the code. The results of both go to developers, a security specialist and the product owner, each judging what they are qualified to judge. Developers look at technical soundness, the security specialist at risk, and the product owner at whether the original business value actually arrived.

Here is the whole loop in one picture.

Product owner and developers define value and requirements, a specification agent writes specs, developers validate, a coding agent builds, QA and security agents check in parallel, humans validate results, and any human or agent can send the process back to an earlier step. Product owner Describes business value Developers Write technical requirements Specification agent Writes specs for coding agent Developers validate specs Coding agent Runs the development loop QA agent Drafts test specifications QA and developers Validate test cases QA agent Writes the tests Security agent Compliance checks, in parallel Validate results Developers, security, product owner Human step Agent step Break the loop, go back.

Anyone can break the loop

At any gate a human can stop the process and send it back one step or several. A failed test may expose a vague spec, a vague spec may expose a missing technical requirement, and a missing requirement may expose a business value nobody can deliver. The rule is that the earliest artifact responsible for the problem gets fixed first, and everything downstream is regenerated.

Agents can break the loop too, and I want them to. An agent stops when the spec is ambiguous, when two documents contradict each other, when a limit is reached, when a test cannot pass without changing the spec, or when a security finding crosses a threshold. It writes down why it stopped and hands the problem to the human who owns that step. What an agent may never do is quietly rewrite the spec to make its own life easier. It can propose a change in a file. A human decides. Without this rule you get an agent that “fixes” a failing test by deleting the requirement behind it, which is efficient in the same way that cancelling your gym membership is a fitness plan.

Everything lives in the repository, and everything is markdown

Value statements, technical requirements, agent specs, test specs, handovers, guardrails and limits all sit in the same repository as the code, under version control, and all of them are markdown. Humans read markdown in a pull request diff without any tooling, and agents read it without a parser. Chat history is not a source of truth, because it disappears when the session ends and nobody can review it. A file in git has an author, a diff and a history.

It also settles who reviews what, now that humans no longer read generated code. People review pull requests that change specs, test specifications, guardrails and limits. Those files decide what the agents build, so they get the human eyes. A layout like this works for me. The names are my convention, not a standard, so adapt them.

AGENTS.md
specs/
  042-invoice-export/
    value.md
    requirements.md
    agent-spec.md
    test-spec.md
    handovers/
      01-spec-agent.md
      02-coding-agent.md
      03-qa-agent.md
      04-security-agent.md
guardrails/
  coding.md
  qa.md
  security.md
  limits.md
  controls/
    iso27001-mapping.md

Each agent reads a small, fixed set of files and writes a small, fixed set. The diagram shows which is which, in the order the work happens. Security runs in parallel with QA, so its row sits below only for the sake of the page.

A chain of human and agent steps with the markdown file each step produces between them. Guardrail files feed the agents from the side. QA and security run in parallel and merge into a final validation. Product owner Business value value.md Developers Technical requirements requirements.md Specification agent Writes agentic specs AGENTS.md agent-spec.md handover 01 Developers Validate specs Coding agent Development loop coding.md limits.md Code in the repository handover 02 QA agent Drafts test specs qa.md test-spec.md QA and developers Validate test specs QA agent Writes the tests Tests in the repository handover 03 Security agent Parallel to QA security.md controls folder handover 04 security findings Validate results Release or send back Human step Agent step File in the repository

AGENTS.md is a convention that several coding agents read from the repository root, and some tools use their own file name instead, so check what yours picks up automatically. The security agent reads the control mappings, which means a requirement from ISO 27001 or NIS2 becomes a check that runs on every change instead of a spreadsheet someone opens before an audit.

Guardrails and limits

Guardrails come in two kinds, and the difference matters. The first kind is text the agent reads, like “never add a dependency without approval”. That is a request to a model, and models usually comply but are not obliged to. The second kind is enforcement outside the model: tool permissions, protected paths, CI checks that fail the build, branch protection, and code owners on the guardrail files themselves. A guardrail that exists only in markdown is a polite sign on an open gate. Write the rule in the file so the agent understands it, and enforce it in the pipeline so it holds when the agent does not.

My limits.md is plain markdown with a heading per topic and one rule per line. This is a trimmed example.

# Limits for the coding agent

## Budget
Maximum iterations in the development loop: 5
Maximum changed lines per task: 400
Maximum wall-clock time per task: 60 minutes

## Forbidden
Do not edit files under specs/ or guardrails/.
Do not edit or delete a test to make it pass.
Do not add a dependency without approval.

## When a limit is hit
Stop. Write a handover with the reason. Do not try a different approach.

I picked those numbers as a sensible first guess, not from measurements, so tune them against your own teams. Changes to limits.md need approval from the security specialist through a code owners rule, which means the agents cannot loosen their own leash.

Handovers

Every stage ends by writing a handover file, and the next stage reads that file plus the spec, never the previous conversation. The handover has fixed sections: what was asked, what was done, what was deliberately not done, which files changed, which checks ran with their results, open questions, and the reason for stopping if the agent broke the loop. Chat context dies with the session, but files survive, which is also why a human can pick up any step cold after a weekend.

The trade I made

Humans no longer review code in this model. The attention moves upstream to specs and test cases and downstream to test and security results. That is a deliberate bet, and it has a cost. If a spec is weak or a test misses a behavior, nothing else catches it, because nobody reads the lines that slipped through. I have no data showing this holds across teams, so watch your defect and incident rates for the first few months before trusting the process.

The consumption rate drops because every gate needs understanding instead of a click on approve. The work spreads out. The product owner supplies value and judges outcomes, developers own technical direction and the specs, QA decides what deserves testing, and the security specialist stops being the person who says no on the last Friday before release. The agents still type faster than anyone alive. They just do not get to decide what is worth typing.

This is the first part of five. 

© Copyright 2026 Sorin Mustaca, All rights Reserved. Written For: Sorin Mustaca - Security & Technology

---

Want to work with me on this topic?
Check Endpoint Cybersecurity to see the consulting services we offer.