Here is a pattern I kept running into. A story looks done. It passes review. It ships. Then three weeks later it comes back, because compliance reads it differently than engineering did, and the version that shipped satisfies neither. Nobody lied. Nobody was careless. The story was never agreed on. It only looked agreed on.
That gap is where rework lives. And it does not close by writing more detailed tickets. It closes by changing what you think a backlog item is for.
What do I mean by "contract"?
When I say a story is a contract, I mean something specific and boring. A contract has parties, it has terms, and it has a definition of what "fulfilled" means that all parties signed off on before work started. A to-do list has none of that. A to-do list has one author and one reader, and they are usually the same person.
In a fintech product, a single story about an approval flow has at least three counterparties:
- Compliance, who cares whether the flow is auditable and whether it can be defended to a regulator later.
- Engineering, who cares whether the flow is buildable, testable, and doesn't assume a system that doesn't exist.
- The business, who cares whether the flow moves the number it was supposed to move.
If you write the story for only one of them, the other two will renegotiate it later. Except "later" means after it's built, which is the most expensive possible time to negotiate.
A story is not finished when it is clear. A story is finished when the people who will judge it later could not, today, disagree about what it means. If compliance, engineering, and the business would each sign the same sentence, it is a contract. If any of them would sign a different sentence, it is still a draft.
Why does this cut rework specifically?
Rework is almost never a coding problem. It is an agreement problem wearing a coding costume. Trace a piece of rework back to its origin and you rarely find a bad engineer. You find a sentence that two people read two different ways, and nobody noticed until the build made the disagreement physical.
So the leverage is not in writing faster. It is in surfacing the disagreement while it is still just words. Words are cheap to change. Shipped features are not.
Most teams try to buy speed by writing less. That is backwards. You buy speed by moving the argument earlier, to the cheapest possible moment, which is before anyone has typed a line of code.
On one platform I worked on, reframing stories this way was a meaningful part of cutting rework by about 30 percent. Not because the stories got longer. Some of them got shorter. Because the acceptance criteria stopped being my prediction of what "good" meant and started being a thing compliance and engineering had both already nodded at.
How do you write one?
I do not have a template to sell you, and I'd be suspicious of anyone who does. But there are a few habits that make a story behave like a contract instead of a wish.
1. Name the counterparties in your own head before you write
Before writing acceptance criteria, ask: who is going to judge this later, and by what standard? If you cannot name them, you are not ready to write the story. You are ready to go ask someone a question.
2. Write acceptance criteria as things that can be refused
Good acceptance criteria are falsifiable. "The approval flow is compliant" is not a criterion. It is a hope. "An approval over threshold X requires a second approver from a different role, and the record retains both approver IDs and timestamps" is a criterion. Compliance can look at that and say yes or no. That yes is the signature on the contract.
3. Get the objection early, on purpose
Do not write the story to avoid friction. Write it to attract the objection while it is still cheap. If compliance is going to hate the design, you want them to hate it at the story stage, in a sentence, not at UAT, in a build.
The goal of refinement is not agreement. It is disagreement, early, out loud, before anything is expensive.
What this changes about your job
If you accept the framing, the product owner's job shifts a little. You are less of a scribe who captures requirements and more of a broker who gets parties to agree, and then writes down what they agreed to in language none of them can later wriggle out of.
That is less glamorous than "product visionary." It is also most of the job, in any domain where getting it wrong has a cost beyond a bug report.
The next time a piece of work comes back as rework, do not ask "who built this wrong." Ask "which two people never actually agreed, and what sentence let them believe they had." Then go fix the sentence. That is where the 30 percent lives.