What is the term for an anti-user-story?

Question

I need to create some short narratives that capture the "who", "what", and "why not" to show some of our stakeholders why we need a minor policy change.

For example, imagine I'm designing a control panel for an evil overlord and I need to convince him that requiring a big red self destruct button on all main control panels is a bad idea.

As a dying enemy, 
I press big red self destruct buttons 
so I can foil Live Corp's plans for world domination.

Normal user stories specify how we want the system to behave. Here I am specifying how the system should not behave or how an undesirable system would behave.

What is the term for such things?

(to be clear, I probably won't write them in the 3-clause format when presenting them to the stakeholders)

Answer 1

First, I love your scenario - very fun. I think I've heard Mike Cohn actually call them "anti-user stories" in a talk.

Frankly though, I don't think it matters what you call them because they're a very short-term device. I wouldn't bother actually recording these anywhere because as soon as they're shared, they should result in real user stories that address the concern. For example, super-villain Dr. Terrible submits a user story:

As a super-villain, I would like my weapon to fire a death ray so that I can permanently vanquish my nemesis, Captain Mallet.

and to show this is a bad idea, you write the anti-user story:

As a super-hero, I would love for my enemy's weapon to have a simple death ray function so I can take it an use it against him.

This is useful to show a major flaw, but only for a moment until we create a real user story to account for it:

As a super-villain, I would like my weapon to verify my identity before firing so Captain Mallet can't steal it and use it against me.

In Real Life

Or, if you prefer a real-world example, the anti-story:

As a hacker, I would like the account login process to use a simple authentication method so that I can more easily break into accounts.

would quickly be replaced with:

As a registered user, I would like my account protected with two-factor authentication to provide an appropriate level of security to my account.

Answer 2

As an Information Security Architect, I am with you on the idea of anti-story, and I would counter Daniel and request that they do become permanent record.

In Archimate, you can model risk as events, then design security measures to counter them. The same approach could work well for user stories. This is similar to Daniels last approach, but retains the user perspective (let's be honest, almost no user cares for 2FA)

As a user, I would like to be confident that only I can access my account.

or

As the super-villain, I want that my death-ray can only be used by me.

There's a similar approach in linguistics. The idea is to negate the sentence while not negating its meaning.

You could also go all-in on the anti-story concept and formally define them as anti-stories, to be resolved when they have been fixed. That might be a tad unusual, but I can imagine that it would create some excitement in the team.

Answer 3

TL;DR

There's really no such thing as an "anti-story." Reasonable terms for the concept you're trying to express are probably one or more of the following:

• Threats.
• Threat models.
• Business risks.
• Non-functional requirements.
• Process or security controls.

Refactoring some assumptions about the way such a user story should be structured can help a lot. Rather than trying to describe an anti-feature, describe the feature as a process control instead.

Restate Your Feature as a Process Control to Mitigate a Risk/Threat

What you're really describing is a process control, e.g. you don't want your minions to be able to foil your plans by blowing up your secret base in their final moments. The problem with your "anti-story" approach is that double-negatives and complex inverted logic make user stories hard to follow. Instead, I would reconsider who the value consumer is, and what the context and value proposition are really supposed to be. For example:

As a criminal mastermind,
my secret base should include security measures that guard against sabotage
so that a dying minion acting alone can't blow up my base single-handedly or by accident.

This is not a user story about an anti-feature. In fact, it's a user story that clearly describes a threat model, a feature to address that threat model, and the actors involved (e.g. the criminal mastermind who is the value consumer, and the dying minion who is the target of the technical or administrative control).

If you conceptualize it this way, you end up with a valid (albeit amusing) story in Connextra format. This also results in a more straightforward and testable story.