How do you turn a user story into an evil user story a developer can act on?
answer
- same three clauses, hostile narrator
- who already has legitimate access?
- invert the benefit, not the verb
- asset lives in the so-that clause
- state the goal, never the fix
basics
~20 sKeep the three story clauses and make each hostile: the role becomes a named attacker persona, the capability becomes what they want the system to allow, and the benefit becomes their payoff. The asset stays in the final clause.
solid answer
~50 sI start from a real use case and ask who else can already reach that flow, then rewrite the same three clauses in their voice. Take a school app's "as a parent, I want to see my child's pickup roster so I know who is collecting them". The inversion is "as a non-custodial parent with a valid login, I want to read the pickup roster and its change history so I can be at the gate before the custodial parent". The persona is authenticated and low-privilege, not an anonymous internet attacker; the asset in the `so that` clause is a child's safety, not a table. I invert the *benefit*, not the verb, and I keep the fix out of the story — the story states the goal so any candidate control can be judged against it. On a misuse-case diagram that story is drawn as a misuse case that *threatens* the original use case.
go deeper
Be able to recite the three story clauses and show one inversion out loud. Knowing that the role becomes an attacker and the benefit becomes their payoff is enough at this level.
Expect to be handed a feature story and asked to invert it on the spot. Show that you pick a persona who already has access, keep the asset in the final clause, and leave the mitigation out of the story text.
Demonstrate judgement about which inversions matter: insider and cross-tenant goals over generic outsider attacks, and a short list that changes a design rather than a long catalogue. Be ready to say what a story-level view catches that an element-by-element sweep misses.
Own the question of where these come from and who writes them. Argue for the team authoring their own stories with security facilitating, and for a cap on volume, because an unreadable list of threats is the same as no list at all.
## The shape A user story is three clauses: *as a* `<role>`, *I want* `<capability>`, *so that* `<benefit>`. An evil user story (often called a misuse case or abuse case when it is drawn rather than written) keeps exactly that shape and turns each clause hostile: | Clause | Normal story | Evil user story | |---|---|---| | as a | a legitimate role | a named attacker persona, with the access they actually hold | | I want | a capability the system should offer | what the attacker wants the system to let them do | | so that | user value | the attacker's payoff, which names the asset at stake | It is a **threat** — a statement of what could go wrong — written in the vocabulary the delivery team already uses for work. It is not a vulnerability (the flaw that would let it happen), not a control (what you would do about it), and not a test. ## A worked inversion Use case, school parent-communication app: *as a parent, I want to see my child's pickup roster so I know who is collecting them*. Inverted: *as a non-custodial parent with a valid app login, I want to read the pickup roster and its change history so I can be at the gate before the custodial parent*. Three things make this usable. The persona is an **authenticated low-privilege user whose access is legitimate and whose goal is not** — nothing here is "hacked", every request is well formed and authorised by the current rules. The asset is a child's physical safety, which is what makes the story worth a design change. And the outcome is concrete enough that two engineers can disagree about whether a proposed change actually blocks it. ## The recipe 1. **Start from a real use case or story on the board.** Evil stories written in the abstract drift into a generic list of attacks. 2. **List who is already inside the flow's blast radius**: other tenants, staff and support desks, a partner integration, someone sharing the account, the person the account was handed to after they left the household. Most useful evil stories come from someone who is already legitimately in the system, because those are the ones an element-by-element sweep of a diagram does not flag. 3. **Invert the benefit, not the verb.** "I want to bypass the roster check" describes a broken control. "I want to know who collects the child" describes a goal, and stays true no matter which control you later add. 4. **Keep the asset in the `so that` clause.** Money, audit truth, availability, a trade secret, someone's privacy or physical safety. A story without an asset cannot be prioritised. 5. **Leave the fix out.** The moment the story says "…so the endpoint should check custody status", you have written a requirement and thrown away the ability to compare alternatives. 6. **Stop at a handful per feature.** The value is a short list a team argues about, not an exhaustive catalogue. ## Misuse case, abuse case, evil user story The terms overlap and teams use them loosely, but the literature does distinguish them. An **abuse case** describes a complete interaction between an actor and the system whose result is harm; it does not have to correspond to any use case you shipped. A **misuse case** is specifically the inverted twin of a use case, drawn on the same diagram as the use case model, connected by two extra relations. An **evil user story** is the backlog-shaped rendering of either — the same content in story clauses so it can sit in refinement next to the feature it inverts. On a misuse-case diagram, a courier app makes the relations concrete. The use case is *courier completes a delivery*. The misuse case *courier marks orders delivered without delivering them* **threatens** it. A new mitigating use case, *capture proof of delivery at the drop point*, **mitigates** the misuse case. Note the direction: `mitigates` points at the misuse case, not at the original use case, so the diagram reads as goal, counter-goal, counter-counter-goal. The asset there is money and audit truth — the courier is not stealing customer data, they are corrupting the record of what happened. ## Why bother writing them as stories Sweeping a design element by element is good at the mechanical threats — a data flow that can be read, a store that can be tampered with. It is weak exactly where every request is well formed, authorised and unremarkable, and the harm lives in the *sequence* and the *relationship between actors*. Narrative form is what surfaces that class. It also lands in a language product people can argue with, which is how the resulting work gets scheduled rather than filed. ## Common failure modes "As a hacker, I want to hack the system, so that I get the data" is the canonical bad one: no access level, no asset, nothing falsifiable. Making every persona an anonymous outsider is the next: the interesting stories on most products are insiders and other tenants. Writing the mitigation into the story removes the design conversation. And treating an evil story as a bug report confuses a threat with a vulnerability — nobody has claimed the flaw exists yet, only that if it does, this is what someone would do with it.
- What is the difference between a misuse case and an abuse case?An abuse case describes any complete interaction between an actor and the system that ends in harm; it need not correspond to a use case you built. A misuse case is narrower and notational: the inverted twin of a specific use case, drawn on the same diagram with threatens and mitigates relations. Teams use the words interchangeably in practice, and an evil user story is either one written in backlog clauses.
- On a misuse-case diagram, which way do the threatens and mitigates relations point?The misuse case threatens the use case it undermines, so that arrow runs from the attacker's goal to the legitimate goal. A mitigating use case mitigates the misuse case, so that arrow points at the attacker's goal, not back at the original use case. Reading it aloud gives goal, counter-goal, counter-counter-goal, which is also how you spot a mitigation that was drawn against the wrong thing.
- A team writes 'As an attacker, I want to bypass rate limiting on the login form.' What would you change?Two things. The persona has no access level or motive, so nobody can judge whether it is plausible for this product. And the capability names a control, not a goal — if we replace rate limiting with device binding, the story silently becomes obsolete even though the danger has not changed. Rewrite around what they are after: an attacker with a list of leaked credentials wanting to find which ones work here, so they can resell verified accounts.
- Who on the team should write evil user stories?The people who wrote the feature story, in the same conversation, with a security-minded person facilitating rather than supplying them. Engineers know the flows and the shortcuts; a security specialist handing over a finished list turns it into a gate and produces stories that misname how the system actually works. The specialist's job is asking who else is already inside the flow, and pushing back when the persona is a caricature.
It is the same script read by the understudy nobody cast: same stage, same lines about what the system lets you do, delivered by someone whose motive is the opposite of the one the writer had in mind.
saying these in an interview costs you the question
- Writes 'as a hacker, I want to hack the system'
- Makes every persona an anonymous internet outsider
- Names the fix instead of the attacker's goal
- Drops the so-that clause, so no asset is named
- Treats an evil user story as a confirmed vulnerability
- Produces dozens per feature instead of a short arguable list