Suppose I have a user story like:
As a customer, I am able to browse products by specifying a category.
If the Product Owner wishes to list the types of categories available such as books, electronics, or clothing, how would that be captured in a user story?
A user story is not a specification. It is generally a placeholder that describes the outline (not the details) of a feature, and provides some context to guide design and implementation decisions. Important details can be provided as separate stories; minor details should be communicated directly or in ancillary documents.
Critical features should be separate user stories. Consider this advice:
Many of these details can be expressed as additional stories. In fact, it is better to have more stories than to have stories that are too large.
— Cohn, Mike (2004-03-01). User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series (Beck)) (Kindle Locations 489-490). Pearson Education. Kindle Edition.
So, you might have one story for adding a user-selectable book category, and another for limiting your scope to clothing. This is the right way to go if each feature really needs to be captured at the project level, because user stories are tracked on the Product Backlog.
When you are using Scrum properly, a user story facilitates communication about a feature, rather than functioning as a detailed specification document. For example, a good placeholder might be:
As a customer,
I want to be able to select a category
so that I can narrow the scope of products I am browsing.
Maybe the Product Owner and Development Team agree to hard-code the values, or perhaps a more dynamic approach where the marketing team can add or remove categories dynamically would be better. Both approaches will work; the main difference is in the level of effort required to implement the feature. This is a great negotiation to have during Sprint Planning if the scope and complexity of the story isn't already clear to everyone on the Scrum team.
Rather than writing all these details as stories, the better approach is for the development team and the customer to discuss these details. That is, have a conversation about the details at the point when the details become important. There's nothing wrong with making a few annotations on a story card based on a discussion...However, the conversation is the key, not the note on the story card. Neither the developers nor the customer can point to the card three months later and say, "But, see I said so right there." Stories are not contractual obligations.
— Cohn, Mike (2004-03-01). User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series (Beck)) (Kindle Locations 509-513). Pearson Education. Kindle Edition.
The point being made here is that in most cases adding prescriptive levels of detail to a story is a project smell that indicates that the Product Owner wants detailed, up-front specifications rather than truly iterative development. In practice, a story like yours might lead to some hard-coded values in one iteration in order to make the feature available, while future sprints might add additional categories or make the list of categories more flexible and dynamic.
Given your specific example, it might be easier just to rewrite the story to include the small set of hard-coded categories. For example:
As a customer,
I want to be able to browse books, electronics, and clothing separately
so that I only see the types of products I'm currently interested in.
On the other hand, if the list of categories is a lot longer, you could just use your original story, and the Product Owner could provide a separate document listing the categories he wants added. The list doesn't have to be part of the user story; in fact, if the list is a big one, it shouldn't be. The story just acts as shorthand to describe the outline of the feature, but the details can be fleshed out during Sprint Planning or Backlog Grooming, and be captured in additional project artifacts when necessary.
You can user Acceptance Criteria to make your user story look more broader and clearer.. Example
As a customer, I shall able to browse products by specifying a category.
Acceptance Criteria:
The user story is a collection of scenarios , use GWT(Given When Then) to write the scenarios . Also create a prototype and attach it with the screen
