User Stories are fine grained requirements described in a relatively informal simple format, typically as a structured sentence of the form "As a <type of user/system> I want <a requirement> so that <something of value results>". User Stories normally have attached Acceptance Criteria to help clarify their Definition of Done.
User Stories are frequently favored by agile teams for their relative informality, simplicity, ease of identification and ability to represent a wide range of requirement types. The general intention with Stories is to keep them small enough to be implemented in a short period of time, usually days, and certainly within a single iteration/sprint if using an iterative/agile workflow. User stories are usually qualified by a one or more acceptance criteria which help inform the definition of done for the story.
In theory, User Stories follow the standard sentence pattern of:
"As a <type of user> I want <a requirement> so that <something of value results>"
However, when using tools to track User Stories as part of a Backlog viewing many stories in that form can look a little messy to the eye, especially to dyslexic readers, as the sentence pattern creates a lot of repetitive visual noise. In many cases tools display stories in a single line or a small "post-it" note visualization and so the full text is truncated. For this reason, we recommend using a headline to describe the story and putting the full text in the item's description. As mentioned in the Requirements View we recommend being flexible in the format of requirements (at every level) to aid clarity.
When teams have lots of user stories they often need to refer to specific Stories in shorter ways than using the full sentence. Numbers from tools can be ok, but a bit unnatural so simple headline names work well for discussion.
One of the advantages of user stories as units of requirements is that they are a simple concept and relatively easy to identify. However we frequently see a number of anti-patterns that should be avoided.
User Story Anti-patterns
We strongly recommend any stories exhibiting any of the following characteristics be corrected or removed from the backlog.
No story value
"As a user I want the system to generate a finance report"
Often the result of a story, it’s link to Business Value, is missed out. This effectively makes the story a simple assertion which does not convey the reason why the story would be useful within the system, although this may seem a trivial point the omission has a significant effect on requirements understanding as time progresses, the original point of the story often becomes lost. We recommend understanding the "value proposition" of a story as if there is no value to the functionality the story should not be developed. The reason for omission of the value part is often given as the author taking "a short cut” - this causes longer term problems and should be avoided.
Invalid role in user story / Non-requirement stories
"As a requirements manager I want to ensure the requirements all have acceptance criteria"
It is common to see user stories where the role is abstract or simply a development team role rather than an end consumer of product value. These are not requirements. This is a symptom of people adopting the language of user stories (and often agile terminology) without understanding the concepts. This is a symptom of the "Backlog as WBS" anti-pattern. Activities that the team need to do and want to track on the Backlog, but are not requirements, are best represented by Objectives.
Backlog as WBS (Work Breakdown Structure)
A traditional approach to planning is the creation of work breakdown structures (WBS). A WBS decomposes activities into smaller and smaller units, with dependencies between them creating critical paths for planning. Although a WBS is a useful way of understanding what might need to be done it encourages false accuracy across chains of WBS items and removes responsibility for problem solving from team members into the hands of an elitist planner or Project Manager.
A common dysfunction we have observed in teams adopting Backlogs and User Stories is to adopt the terminology but actually still do WBS planning using these terms. A symptom of this approach is a backlog that is comprised of a hierarchical structure of "Epics" with child "Stories" (sometimes multiple levels of each) and finally child "tasks". This obscures the purpose and clarity of a genuine backlog and also makes the classic WBS harder to see devaluing both approaches.
Often User Stories do not have any acceptance criteria associated with them leaving out half of the requirement. Often acceptance criteria express the non-functional requirements that are necessary for a story, or elements that will be useful for testing, especially acceptance testing. Acceptance criteria are required to define the scope and specific instance of a user story, additionally helping the team understand what constitutes a story as being complete/done. The identification of acceptance criteria by team members and the product customer is a critical step in developing effective requirements, without acceptance criteria it is unlikely that the user story will meet the customer's actual needs.
Abuse of Story Points
Story Points are used to indicate relative effort across a set of stories. Applying techniques to normalize points across teams, or to fixed time units (e.g. mythical person-days) or complexity indicators is defeating the purpose of Story Points. This is especially dysfunctional when teams allocate story points for non-requirements.
Story Points are an abstract, arbitrary number associated with User Stories that indicates the relative effort (not complexity) required to complete the story development.
A compound anti-pattern we have often observed is non-requirement stories (in the “Backlog as WBS” anti-pattern earning story points. For example:
“As a test manager I want to get a testing environment this iteration” 20 pts
This is an invalid role and a non-requirement. The User Story is really a planning Objective, and so should not earn points or be used in progress extrapolation.
The following are some real examples of dysfunctional user stories taken from real projects.
"As the project I want the software to pass all non-functional requirements so that I know the quality is high"
This user story, although laudable in its intent to consider non-functional requirements, is remarkably bad. The "project" is not a consumer of value (a customer or integrating system) and this is not a requirement. Non-functional requirements must be addressed as part of the acceptance of functional user stories. Where non-functional requirements apply to multiple stories they should be addressed as cross-cutting acceptance criteria, potentially against Integration Scenarios. If non-functionals are isolated from functional requirements and really do make sense on a Backlog then put them there, but not as Stories. In this real life example there were not even a set of explicit non-functional requirements to refer to.
"As a Developer I want an automated build so that I can implement continuous integration”
Again valid in its intent, this story represents the intent of the development team to adopt effective development practices, the story does not of itself represent direct value to a consumer of the product. We often see stories in backlogs of this nature and strongly recommend that these are not considered as user stories but as team Objectives.
"As a Project Manager I want to manage all project risks"
This user story is possibly one of the worst examples of a user story we have encountered, mixing concerns of project management with a backlog of functionality to be delivered, the example also had a story point estimate and even worse the contractual arrangements were based on payment by story point!
Objectives represent non-requirement activities that must be done to enable successful delivery.
Objectives can be used to represent overhead, setup and team improvement activities on a backlog. These concerns should not be considered as user stories as they add no direct value to a consumer. Objectives, therefore, should not contribute story points to team velocity (for agile/iterative teams) as they are not part of the product scope and will be inconsistent in terms of effort, therefore extrapolation of their completion is meaningless. Instead Objectives are best thought of as overhead. Explicit representation of overhead vs. requirements means that teams can be transparent in discussions with Product Customers regarding the necessity of overhead activities and trade them in/out against requirements.