Agentic Scrum, Part 2 of 5: Describe the Value

Introduction

This is part 2 of 5 in the Agentic Scrum series. Part 1 explained the whole loop and why the product owner stopped being a vending machine. This part covers the first two steps, the only ones with no agent in them. Then we move on to specs and the coding agent.

The first two steps of the pipeline have no agent in them, and that is deliberate. This is where the most expensive mistakes get made, because a wrong sentence here is multiplied by every step downstream. A coding agent will build the wrong thing at full speed and with excellent formatting.

What the product owner writes

The product owner writes one file per feature, called value.md, and it fits on a page. It answers six questions:

1. who has the problem
2. what the problem is
3. what changes for them when we solve it
4. how we will know it worked
5. what we are explicitly not doing
6. which business constraints apply
7. Optional: are there any open questions, which we can’t or don’t want to answer now?

It does not say how the screen looks. It does not name a button. The moment a value statement contains the word “dropdown”, somebody has started designing, and designing is a conversation for developers and UX that happens later, with more information.

Here is a made-up example, so the numbers are illustrative. I have left many potential details that would make up a real feature definition on purpose. I am not trying here to define a new (imaginary) product, only to show you the format, the headings and the type of language to use.

value.md:

# Invoice export

## Who has the problem
Finance clerks at our larger customers.

## The problem
Closing the month means exporting invoices by hand, one customer at a time.
In interviews, clerks called this the slowest part of their close.

## What changes for them
They get all invoices for a period in one step, in a format their
accounting system accepts.

## How we will know it worked
Support tickets about manual invoice export drop. Time from "close started"
to "export done" falls under one hour for the customers we interview again.

## Out of scope
Scheduled exports. Formats other than the two named in requirements.md.

## Business constraints
Must never expose invoices across customer accounts.
Ships before our customers' fiscal year-end.

## Open questions
Do customers need credit notes in the same file?

 

 

I make “Out of scope” a required section, because agents are enthusiastic. Ask one for an export and it may also build a scheduler, a settings page and a small dashboard nobody requested. Writing down what we are not doing is the cheapest feature work in the whole process. The section “How we will know it worked” has to be observable too. A number, a ticket count, a behavior someone can watch. “Better user experience” is a wish, not a measure. That section comes back in Part 5, when the product owner checks at the final gate whether the value actually arrived.

What the developers add

Developers turn value.md into requirements.md. They do not rewrite the value, they translate it. Every requirement gets an ID, because Part 3 and Part 4 trace specs and tests back to those IDs, and that traceability is what lets us stop reading code. A good requirement is a sentence a stranger could check. The export contains all invoices of the selected period, and only those of the signed-in customer.

The file also holds interfaces and data, non-functional requirements for performance, security, privacy and availability, failure modes, assumptions and risks. This is where the 40,000 records question lives.

What happens with 40,000 invoices? With none? With the network dropping halfway? With a customer whose name contains an apostrophe and a snowman? Developers are professionally suspicious, and this is the step where that trait earns its salary.

requirements.md:

# Invoice export: requirements

## Functional requirements
R1 The user can export all invoices of a chosen period in one action.
R2 The export contains only invoices of the signed-in customer account.
R3 The export is available in the two named accounting formats.

## Interfaces and data
Reads invoices through the existing invoice service. No new tables.

## Non-functional requirements
N1 An export of 40000 invoices finishes within 5 minutes.
N2 Every export is logged with user and period.
N3 The export file is not stored after download.
N4 Only one export can be served at a time.

## Failure modes
F1 No invoices in the period: the user sees an explicit empty result.
F2 Invoice service unavailable: retry message, no partial file.
F3 Export interrupted: nothing is left on the server.

## Assumptions and dependencies
A1 Invoice service response times stay as they are today.
A2 The operator is already logged in and authorized to download.

## Risks
R1 Large exports may load the invoice service during month-end peaks.
R2 Export requests will by queued, potentially slowing down the overall delivery.

The gate between humans and agents

Nothing goes to the specification agent until requirements.md is approved by the product owner and by a developer who did not write it. I run this as a short value review of 30 to 45 minutes, with the product owner, the developers who will own the feature, and QA or the security specialist when the feature touches their areas. The product owner asks whether the requirements still mean what was meant. The developers ask whether the value is clear enough to build against.

The questions are boring on purpose. Can a stranger tell when this is done? Is there a number or an observable behavior under “how we will know”? Is any requirement a solution in disguise? Does “out of scope” contain something? Approval happens as a pull request on the specs folder. The merge is the approval, the discussion is the record, and nobody has to remember what was agreed in a meeting three weeks ago.

This gate is also the brake that Part 1 promised. Agents are fast, so the limit has to sit on the humans’ work in progress. I cap the number of features in flight per team, and I would start with two, which is my guess and not a benchmark. When both slots are taken, nothing new enters until one of them clears the final gate. The product owner no longer has to out-write the agents. The product owner has to stay two value statements ahead, which is a job a person can actually do.

 

Who writes the backlog now

The backlog now holds value statements, which cost far less to produce than the full stories of the old days. Developers draft them too, for technical enablers like refactoring, performance work and security hardening, because they see those needs first. The product owner keeps the one decision that cannot be delegated, which is priority, and approves or rejects what developers propose.

I also reserve a slice of every sprint for discovery. Developers read support tickets, talk to a customer-facing colleague or prototype an idea. The output is a better value.md or the deletion of a planned one. Deleting a feature before an agent builds it is the cheapest delivery you will ever make.

How this goes wrong

Three failure patterns show up early.

• The first is the value statement that is a design in disguise, usually something like “design a green page with a blue button in the middle of it called ‘Download'”.
• The second is requirements that copy the value text and add nothing, which means nobody did the thinking.
• The third is the absent product owner. If the product owner is not available, the pipeline stalls. That looks like a problem, but it is the system working, because an agent guessing the missing answer is far worse than a feature waiting a day.

 

Previous: Part 1, The Product Owner Is Not a Vending Machine. Next: Part 3, Write Specs a Coding Agent Can Actually Follow.

© Copyright 2026 Sorin Mustaca, All rights Reserved. Written For: Sorin Mustaca: Security-AI-Software

---

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