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?

Improve this question

7 Answers 7

Reset to default
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.

Improve this answer
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.

Improve this answer
1
  • A quick explanation about epics Commented Mar 17, 2015 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.

Improve this answer
2

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

Improve this answer
2

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.

Improve this answer
1
  • This! User stories are a magnificent tool for describing small parts of a big picture. They are the ideal way to handle the intersection between development and the other world (product management, user research, sales, ...) Commented Sep 12, 2019 at 13:21
0

What you describe as a "user story" (the "as a , I want <goal/desire> so that " part) is really the card, which is one-third of a user story. The other two parts are conversation and confirmation. Together, these are known as the Three Cs.

The card is a starting point for a conversation, but it isn't the end. The card allows you to order the work in some kind of backlog, remember the work for the future, and remind you who needs to be involved in the conversation. By having a conversation, you would learn about other things that stakeholders need.

There are different ways to capture the results of the conversation. If you're using an electronic tool for capturing user stories, you may be able to attach things like conversation or meeting notes, wireframes and mockups, decision tables, data dictionaries, roles and permissions matrices, and more. If you have physical cards for user stories, you may store this information in some kind of wiki or CMS and have a way to find the information relevant to the user story.

Exactly how and what you record about the conversation depends on the needs of the team and the context of the organization. This is the Agile Software Development values of "individuals and interactions over processes and tools" and "working software over comprehensive documentation".

Improve this answer
-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."

Improve this answer
2
  • 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?" Commented Mar 17, 2015 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. Commented Mar 17, 2015 at 16:11

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.