There Are No User Anti Stories

The example UserAntiStory, No user, however stupid or malicious, will be able to gain control of the queried computer system, has nothing to distinguish it [in planning or implementation] from any other story.

A story describes anything the customer wants:

The particular story looks different due to an accident of syntax. It might have been, The set of users who are authorized to gain control of the system is empty. Or The following users are allowed to gain control of the system: <none>.

What's the diff? The engineering tasks are different for each of these stories, but they aren't different in any substantive way. They might be harder to THINK of, but so are stories about performance or ease of use. -- RonJeffries

You can argue that any story that contains the words "will never" is a limit of a story with a phrase "will not for at least t time units" where t gets very large. Hence becoming NonFunctionalRequirements about a "mean time to failure". If so, OperationalProfileTesting? + MercilessTechnicalReview? might help. -- DickBotting

EwDijkstra refused to have anything to do with this type of requirement.

AntiStories? sound like another case of NonFunctionalRequirements, and I have to say that I am still not at all convinced that these can be UserStories.

I find AlistairCockburn's take in WritingEffectiveUseCases much more persuasive: he considers UseCases to be the core part - but only a part - of the total system requirements, with data requirements, performance, usebility, sizing, etc., also being part of the mix. -- RussellGold

I should have made more clear here that I don't care whether one thinks of a certain type of story as a UserAntiStory. Requirements of this kind do exist. All I'm saying really is, write them on a card, estimate them, schedule them by business value. -- RonJeffries

Ron goes on to remind us what a story is for ...

A UserStory is a story, told by the user, specifying how the system is supposed to work, written on a card, and of a complexity permitting estimation of how long it will take to implement. The UserStory promises as much subsequent conversation as necessary to fill in the details of what is wanted. The cards themselves are used as tokens in the planning process after assessment of business value and [possibly] risk. The customer prioritizes the stories and schedules them for implementation.

And then turns the anti-story question around by asking if there is any process that can address them differently than the above ...

Now sketch, please, another XP-style process, different from the above, meeting the same criteria of simplicity and ability to estimate, for AntiStories?. Show how these AntiStories? would be scheduled by the customer, based on business value, with particular attention to their use in the PlanningGame.

Show how writing UserAntiStories on cards, assigning them business value and [possibly] risk, and treating them exactly like stories, will not serve the need.

Anti-stories exist. But they can be transformed to stories by much the same process that any other large or ill-defined story is transformed to estimatable, prioritizable and implementable stories: by negotiating a split. For example, the anti-story:

might split to:

and so on. Of course the original anti-story never really goes away by this process, and that is why the split is a form of negotiation. Together the developers and customers decide what will be enough for now.

-- WardCunningham

Thank you, Ward, for the reminder that UserStories are phrased in the positive, while Anti Stories are phrased in the negative. A "wish", even a requirement, can be phrased in the negative, but "work" must be phrased in the positive, and it can take a lot of positive phrases to cover a single negative phrase.

I think this is the point that DickBotting is bringing up. That users or stakeholders have a wish - that wish can succinctly be stated in the negative, and that it is an act of creation, negotiation, reflection, to come up with the set of equivalent positive phrases. And Dick's point is that even after that negotiation, you may not be sure that you have covered the negative phrase. The user or stakeholder still has that wish, even if the set of positive phrases turn out to be insufficient.

How exactly to deal with this in the XP and UserStory context, I don't know. But Dick will always have the rejoinder that what the user "wants" is a negative guarantee, while what the designers can provide are always positive phrases that may or may not cover it. -- AlistairCockburn

You can say that for all infinite sequences of events in some finite input space, the result after each step in each sequence is in the defined acceptable output set; but you can't test it :-) -- James Cone

The UserAntiStory might have some value as a teaching or discussion tool, though. One of the challenges of working with a customer is the tendency to dwell on the negative. This makes a certain sense; the reason the customer needs to hire programmer/developer services is because there is some pain in the system that needs to be removed. The customer, like a patient in an emergency room, will be focused on the pain (the UserAntiStory). Helping the customer turn that into a positive description of an action (the UserStory) might be a powerful way to build a discussion.

So, the term might serve a purpose for the customer, if not for the programmer.

I'm assuming, of course, that the programmer is not being Pollyannaish about this (using "turn that frown upside-down!" kinds of rhetoric). -- RjLesch

It sounds like the UserAntiStory is something like "other products work like X, Y, and Z, which is a colossal pain". On it's own, this is useless information, but can be helpful in constructing the UserStory.

I set up LimitsOfUserStories to try to coalesce and sharpen the discussion that is now scattered over UserStory, UserAntiStory, TheExtremeProgrammingWayToHandleUserAntiStories, ThereAreNoUserAntiStories. -- Alistair

While it is not possible to prove that a system description lacks certain properties under all conditions, it might be possible to assert many UserAntiStories as positive properties under an agreed upon set of assumptions. These can be tested or proven. Thus, while "Never Loses Data" isn't a UserStory, "Maintains committed data under up to two-node simultaneous failure or communications outage" might be. However, I think one would need a well-designed constraint-based proof system to prove these sorts of things, as opposed to the straightforward testing.

EditText of this page (last edited November 10, 2006) or FindPage with title or text search