The Transformer – From an Epic to the User Stories

The previous post was about assistants that turn a rough idea into a complete artifact. This one is about the operation that comes right after it — and that I first took for a variant of it: transforming.

The artifact already exists. It has to be converted into the next type.

The Starting Point

An epic is on the table. Approved, aligned, at the right altitude. What's missing are the user stories a team can work with.

That is not a creative task. It is a conversion: a defined input type, a defined output type, and in between a cut that has to be justified. And it is the same procedure a product team carries out every week:

That makes the transformer — like the creator — not one assistant but a family. I'm describing the case I learned the most from here: epic to user stories.

What makes this case so rewarding is a property that is easy to overlook: both ends are already standardised. An epic looks the same within the same team, and so does a user story. What changes from one item to the next is the content — not the form at the start, not the form at the end, and not the path in between. That is exactly the constellation an assistant pays off for: structure where something recurs.

Why This Isn't Creating

Breaking an epic down into user stories is not a variant of creating. It is a different task with different sources — it needs knowledge of the existing structure, otherwise you get cuts that don't fit the system. Above all, though, it carries a different main risk:

The practical point: the temptation to build one assistant that does "everything around requirements" is strong. It leads to the same result as a single prompt meant to handle analysis, concept and code all at once — half an answer to everything. Splitting into roles applies to assistants just as much as it does to agents.

Two Steps Instead of One: Enrich, Then Transform

The first version did it in a single pass: epic in, stories out. That works — and you cannot tell from the result what it rests on.

The reason lies in the nature of the source. An epic is deliberately incomplete: it describes the goal, not the routes. Between epic and stories sits knowledge that appears nowhere in the epic — existing system boundaries, neighbouring stories, defined terms, earlier decisions. Whoever transforms directly leaves it to the model to substitute for that knowledge. And it reliably substitutes something that sounds right.

Hence two steps with a visible intermediate result:

The intermediate result is the actual trick: it can be reviewed before it takes effect.

Step 1 — enrich. What is missing in order to cut at all? The assistant collects what the connected sources say about it: linked items, existing stories in the same area, interface descriptions, glossary. The result is not running text but a list — every line with its reference.

Step 2 — transform. Only on that basis comes the cut and the filling of the target schema.

The cost of that is one additional call. The gain is a place where a human sees within a minute whether the basis holds — instead of reading fifteen stories to find the same defect three times over.

Anatomy of a Transformation Assistant

Take-Away: The Template for a Transformation

The template deliberately describes only the path, not the destination: what a user story has to look like is defined in the template from the previous post — here it is used, not repeated. That is the same idea as in the toolkit itself: the target type is defined in one place, and every assistant producing it uses the same definition.

# Transformation: <source artifact> → <target artifact>

## Source
<Title and revision of the input artifact.>

## Enriched Context
| # | Statement | Origin | Relevant for |
|---|-----------|--------|--------------|
| 1 |           | <document, item, artifact — lookupable> | |

## Cut
<Two to four sentences: what was the cut made along, and why this way
and not another?>

## Coverage
| Section of the source | Target artifact | Fully carried over? |
|-----------------------|-----------------|---------------------|
| <Goal>                | <ST-1, ST-3>    | yes / partly + reason |

## Result
<The produced artifacts, each in the template of its own type.>

## Not Carried Over
| Content of the source | Reason |
|-----------------------|--------|

## Open Questions and Assumptions
| # | Assumption | Impact if it does not hold | Who decides |
|---|------------|----------------------------|-------------|

And the rulebook that goes with it:

## Rules for This Assistant

**Mandatory**
- Every statement in the enriched context names its origin.
  No enrichment without a named source.
- Every section of the source appears in the coverage table — including
  the one deliberately not carried over.
- Every produced artifact delivers business value on its own.
- The cut is justified.

**Forbidden**
- Cutting along technical layer, component, team or sprint.
- Silently dropping content of the source.
- Adding requirements while enriching that appear in no source —
  they belong under "Open Questions and Assumptions".
- Delivering a result without emitting the enriched context.

The origin column and the coverage table are the two sections I would not leave out. Why, comes now.

What Didn't Work in the First Draft

Problem 1: The assistant chopped rather than decomposed.

The first version reliably produced seven to ten stories out of an epic. Complete, cleanly worded, in the right schema. Only they were cut along the text of the epic: wherever a system was named, a story per system appeared.

❌ Story: changes in the booking service
❌ Story: changes in the user interface
❌ Story: data migration for cancellations

That is a construction plan, not a backlog. None of those stories delivers anything anybody can use on its own — they all have to be finished together, or nothing is finished. A team cutting this way loses exactly the property it cuts for in the first place: having something finished early.

What helped was not a better task description, but a list of prohibitions in the rulebook and a single mandatory question per story: what can somebody do after this story that they couldn't do before? Wherever the answer is "nothing, X is still missing", the cut is wrong.

The model hadn't come up with that by itself, by the way. It adopted what it saw in the reference examples it was given — and there, that had been the way of cutting for years. That is the uncomfortable flip side of good reference examples: they take effect even when they are bad.

Problem 2: Enriching turned into inventing.

I had built in the split into two steps early on. The intermediate result looked good — and that was precisely the problem. It contained lines such as "cancellations are possible up to 24 hours before departure". Not wrong. It just wasn't written anywhere.

Whether the assistant had taken that from a neighbouring story, inferred it from a passage of documentation, or simply considered it plausible was no longer visible in the intermediate result. Two steps later it had become an acceptance criterion, and that one looked like every other.

An enriched context without origins isn't enrichment, it's an assertion.

Hence the mandatory origin column, concrete enough to be looked up. What has no source must not enter the context — it moves under "Open Questions and Assumptions". A silent addition becomes a decision for a human.

That is the same idea as Open Questions and Assumptions in the creator, only one stage earlier: the creator surfaces what it had to assume. The transformer additionally surfaces how it knows what it knows.

Here, too, the side effect turned out to be the actual gain. The coverage table was only meant to evidence completeness — it turned out to be the fastest review instrument of the whole assistant. A row without a target artifact is a forgotten part of the epic, and in a table you see that immediately instead of missing it three weeks later.

Limits

A good cut is not unambiguous. Two experienced people decompose the same epic differently, and both cuts can be right. The assistant delivers a justified proposal, not an optimum — and the justification is the part that counts. Whoever only reads the stories and skips the cut section reviews the result without seeing the decision behind it.

It doesn't know the sequence. Dependencies it can derive from the material, delivery pressure it cannot. What gets built first is a decision with customers, deadlines and politics in it — that one it doesn't make.

Enrichment is only as good as what is connected. Without access to what already exists, step 1 stays a short list and the cut effectively comes out of the epic alone again. That is the same finding as everywhere in this toolkit — and the reason context gets a post of its own.

Conclusion

Of the four operations, transforming is the one that sounds least spectacular and delivers the most reliable benefit. Not because it is particularly hard, but because both ends are standardised and the task repeats for as long as the product exists.

The rule I take away: enriching and transforming are two steps. Pull them together and you don't get a worse cut — you get one you cannot tell the basis of. And what you cannot tell, nobody reviews.

The next post covers the opposite direction: reviewing. And the realisation that reviewing is considerably more expensive than creating.

→ The toolkit at a glance