Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

A quick and dirty definition of User Story:

"As a <role>, I want <goal/desire> so that <benefit>"

In this commonly accepted definition there is little space for defining business rules, constraints or user input.

Trivial example just to illustrate:

"As a <librarian>, I want to <register new books> so that
<students can find their availability online>"

In this silly example, where would one define the fields needed when registering a book? Should it be written anywhere? Or should the required business rules be passed as word of mouth by the Product Owner?

share|improve this question
up vote 3 down vote accepted

The fields are part of the conversation that should be had. They may be written down if that is useful but that is a judgment call. Keeping the documentation up to date may be challenging whereas the working software could be seen as documentation to some extent.

User Story - A Promise to have a conversation would be a blog entry about this.

Your trivial example has a couple of points that I don't know how well you'd notice this. What does it mean to "register new books?" What is "Find their availability online?" Those are where the conversation begins and once the story is done there may be new stories as perhaps those registrations have to be kept on file or reports have to be generated periodically.

share|improve this answer

Typically on a broad encompassing user story that has many facets I try to get the most general example of the story, and then for specifics I create child user stories that inherit from it. Many Agile project management tools like RallyDev allow you to do this easily and I find it makes sense.

Registering new books is broad, so perhaps there are 10 other child user stories about how <role> would like books to be registered.

Extreme details of these things or bizarre fringe details I usually define in one or more tasks under that user story. The tasks help define development and design work that should be done (on a general level) to meet that user story (Eg. Write validtor to ensure input in description field is less than 50 characters...) EDIT: I just wanted to add that it is probably better to keep extreme details out of user stories because it likely isn't something that a user will really care much about. Users want to explain software in general terms and they are depending on software developers to figure out and hide the details from them.

This is just how I approach the problem but I am sure there a number of different ways.

share|improve this answer

The previous answers provide valid points, specially regarding a user story being a reminder to have a conversation. Other things to consider:

  1. If the story is too complex, it's probably an epic. You can split epics into smaller stories now or once the get priority on the product backlog
  2. Details that imply test cases are separated from the story itself. [Mike Cohn]

    You can add on the back of the story card, make small notes if they are really important or put them into the acceptance tests document.

As a guideline to evaluate if your user stories are good, you may follow Bill Wake's suggestion:

  • Independent (of others stories)
  • Negotiable
  • Valuable (to the user or customer)
  • Estimable (to a good approximation)
  • Small (enough to be estimable)
  • Testable

You may want to read te Chapter 2 "Writing Stories" of the book User Stories Applied, by Mike Cohn.

share|improve this answer
A quick explanation about epics – Ricardo Mar 17 '15 at 18:50

In the example given, there are many details of book registration that developers migt know little about, such as Dewey or other classification systems, ISBNs, acquisition numbers, duplicate copies/titles/authors, other editions, and so on. For a new system, such details must be provided by the customer (and a librarian, of all people, will certainly care about them).

To quote Steve O'Connell, "It's terrifying to contemplate how much business policy is created by developers who lacked the necessary detail in specifications so just made it up for themselves."

share|improve this answer
While these are valid points, they do not appear to address the OP's main question of "How to define complex business rules using User Stories?" – GlenH7 Mar 17 '15 at 14:52
Most of the text is not an answer, except for the tiny bit of information that "such details must be provided by the customer". Which IMHO points in the right direction: you cannot constrain any amount of complexity into the simplest form of a User Story. – logc Mar 17 '15 at 16:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.