11

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?

4

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.

4

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 they get prioritized 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.

  • A quick explanation about epics – Ricardo Mar 17 '15 at 18:50
2

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.

1

The answer is simple, incorporate the business rules into acceptance criteria.

Trivial example just to illustrate:

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

I'll be satisfied when: * I can register the following fields: - ISDN - Author - Dewey Decimal blah blah * I can see confirmation the book has been registered by the system * I can view the book in the system

1

How to define complex business rules using User Stories?

That's not what user stories are for. They are not software requirements that capture all details or business rules needed for writing the implementation. They are just a description of what the application should do from the user's perspective.

Remember what is important: building the proper software. You use whatever is needed to do that and user stories are just so you make sure you have gathered the needed features the application should have so you can then talk about them, prioritize them, estimate them, etc. The missing part from the classical user story (as a... I want... so that) is about communication between those involved in building the software.

Having the details as acceptance criteria, sub-stories, technical tasks attached to the user story, in a specification document or whatever, goes beyond what the user story helps you with. The user stoy is just the "subject" of conversation when deciding how to build the software.

-1

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."

  • 1
    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
  • 1
    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

protected by gnat Aug 24 '18 at 8:49

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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