How do you keep evil user stories in a shared product backlog when they have no happy path?

## Why the backlog resists them An ordinary story ends in a capability someone can be shown. An evil user story ends in an *absence*: a fraudster who cannot profitably card-test on the donate form, a courier who cannot mark a phantom delivery, a reviewer who cannot quietly learn an author's name. There is no screen at the end of it. Product owners are not being obtuse when they push back — the artefact genuinely does not fit the shape their planning process expects, and the usual response, a separate security backlog, is worse than the disease. ## Attach, do not park The strongest single move is to keep the evil story physically next to the feature story it inverts, and to size them in the same slice. A donate form and "a fraudster wants to test stolen card numbers against it" are one piece of work with two halves, and estimating them together means the cost of the feature is stated honestly the first time. Split them across sprints and the second half competes against new features forever, which is a competition it loses. This also fixes the *definition of value*. The feature's value is measured in donations completed; the evil story's value is measured in the same currency — chargebacks, the processor's risk review, the cost of a fraud incident on a charity's public reputation. Both are product outcomes. Neither needs to be argued in security vocabulary, and arguing them in security vocabulary is what makes a product owner file them under "compliance". ## Give it a done, without writing the fix into the story The complaint that an evil story "has no definition of done" is usually a complaint that the goal has not been made falsifiable. Convert the attacker goal into an invariant the team is willing to state: no bulk of low-value authorisations from a single source can be used to distinguish a live card from a dead one on this form. That is testable and arguable, and it leaves the choice of mitigation open. The mitigation itself is separate work that references the story; the story does not name it, or you lose the ability to compare options next quarter when the first one stops working. ## Volume discipline A team that adds three evil stories per feature is doing threat modelling. A team that adds thirty has produced a document. The list has to stay short enough that everyone in refinement remembers it, and short enough that declining one is a conscious act rather than a shrug. Being ruthless here is also the honest response to the fact that most inversions of most stories are not worth work — say so, and drop them in the room, rather than carrying them as unranked debt. ## When the answer is no Some of these should not be built, and pretending otherwise burns the credibility that gets the important ones built. The principal-level behaviour is to make the decline explicit and informed in the same conversation: what the exposure is, what it would cost to address, and what the product is choosing to live with. The decision belongs to whoever owns the product, not to the person who wrote the story. What you must not accept is silence — an evil story that is neither built nor declined, sitting in a list that nobody ranks, is the failure mode that makes the whole practice look ceremonial. ## Who writes them and when They come out of the design conversation for the feature, written by the people who wrote the feature story, with a security-minded facilitator asking who else is already inside the flow. Produced that way they arrive already attached to something the team is about to build, already in product language, and already sized. Produced the other way — a specialist arriving afterwards with a list — they are a gate, they are late, and they are exactly the stories a backlog rejects. ## The signals that it is working Evil stories appear in refinement without a security person prompting them. They get declined out loud, with reasons, as often as they get accepted. There is no second list. And the team can name the last one that changed a design, which is the only evidence that any of this is more than a documentation habit.