Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

2 Answers 2

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

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.