The user story's anatomy

Unfortunately there are different meanings for the term 'user story'.

The following items are usually called 'user stories':

• A well-structured sentence like 'as a blog author I want to be able to upload images in order to impress my readers'
• A card containing a well-structured sentence (like the above), enriched with user acceptance criteria and constraints
• The above card, plus some collaboration
• All of the above and additionally an estimate and a priority (aka backlog item)

The common denominator is that the usual scheme...

As a {role} i want to {ability} [in order to {purpose}].

...is called a user story.

A user story's scope is always to define some functional requirement, in some cases bounded by non-functional constraints. This is a major weakness in all agile processes, as the non-functional requirements - which drive the architecture and the system's cost - don't get enough consideration.


A user story card is a composition of...

1. A story (functional requirement, 'as a ... i want to ... in order to ...)
2. One or more user acceptance criteria
3. One or more constraints (non-functional requirements)

Depending on the user story's degree of maturity the user acceptance criteria or the constraints can be omitted. And of course the story's maturity will be driven by it's temporal proximity to the project's current sprint.


Example

As a blog author I want to be able to add diagrams to my blog posts in order to impress my readers.

User acceptance criteria:

• The blog author can upload an image in one of the following file formats: jpeg, gif, bmp and tif.
• The system must support image file sizes of up to 500kB.
  
• Uploaded images must be stored as the blog post's attachments.
  
• The image can be positioned within the blog post by adding a tag to the text.
• The image's alignment can be specified by adding a parameter to the tag.
• Images can be aligned to the left, to the right or centered.
• An image must be scaled to 80% of the blog's width.
• Removing the tag from the text must not delete the blog post's attachment.
  

Constraints:

• The GUI must be implemented in HTML 5.0
• The system must be implemented in Java
• The system must support up to 100 concurrent blog authors editing at the same time
• The system must support up to 5000 concurrent blog readers with a response time of at most 3 seconds

The above example illustrates the user story's written form, but of course many information that is required to implement the functionality won't be written down of the user story's card. It's an output of the collaborative process that precedes the story's implementation.

A user story as a sentence (the 'story') identifies - but doesn't specify - a software requirement. The difference between identification and specification is essential: A user story's purpose is to act as a placeholder for collaboration between the person holding the role (or a proxy) and the team. It's however not intended to be seen as a full (complete and unambiguous) requirement's specification. A good user story adds some purpose in order to get a feeling for the business value that the user story's implementation is likely to achieve.

A good model that might help readers with a background in software engineering is to think of the set of requirements as a hash table. The hash table's keys are the user stories. Simple, small, unique, of equal structure, but without much information content. The meat comes with the hash table's values: collaboration.
This collaboration between the role and the team is necessary to bring in the requirement's context, it's constraints, some acceptance criteria and of course the requirement itself.