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 system pays everyone what they are owed.
- The system never pays anyone any more than they are owed. --> Not a UserStory
- The system never loses data. --> Not a UserStory
- The system, when asked "foo?", replies "mumble".
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?
might help. -- DickBotting
refused to have anything to do with this type of requirement.
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 ...
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:
- no query will compromise the system
might split to:
- queries will be taged as suspicious data
- queries beyond quota will be immediately denied
- a pre-parser will reject queries with non-alphabetic characters
- all queries will be logged for at least 45 days
- a log inspector will offer views by date, query type and requestor
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.
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
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
. -- 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.