The Structure of User Stories
User Stories have rapidly become one of the most popular forms for expressing Stakeholder Requirements on projects, in particular those that follow the Agile software development approach. Actually, this format lends itself well to expressing Stakeholder Requirements regardless whether your project follows an Agile approach. The most commonly suggested structure of a user story follows the mold:
As a(n) {role the author represents}, I/we can {do or have something} {with these qualities} to {achieve my/our ultimate objective}.
As such, this mold is a wonderful recommendation for the structure of a user story. Based on what I have seen on the web, many feel that this mold by itself is sufficient to explain how to write user stories. I believe there are still a few dimensions missing. For instance, look at two implementations of this mold:
Example A:
As a website visitor (role),
I can view all training (do something)
for which I qualify (quality requirement)
to prepare for the CBAP® exam (goal).
Example B:
As a human being (role),
I can differentiate sounds (do something)
in my native tongue (quality requirement)
to comprehend what others are saying (goal).
Note that both statements follow the mold and are by definition user stories. Whereas the first gives the developer great guidance, I question the value of the second. As a result, I have developed a set of guidelines (rules) for writing effective user stories that go beyond the mold and might help you.
Rules for Effective User Stories
An effective user story:1. Is a simple, complete, well-structured sentence
- States one outcome from the perspective of a specific role
- Does not contain conjunctions (and, or, but, . . .)
- Does not depend on other sources of information
- Contains the role, desired outcome, business value and appropriate qualities
2. Emphasizes “what” should be done, not “how” to do it
- Avoids preconceived solutions
- Describes business logic (rules), not the technology needed
- Expresses the what (destination), not the how (journey)
3. Is relevant to the project
- Defines an attribute of one or more components of the solution that the business community needs or wants
- Is within the project or Agile team’s authority to implement
- Has a short "tail" (does not create a cascading effect of changes that exceed the team’s mandate or charter)
4. Is understandable, unambiguous and clear
- Has a single possible interpretation for anyone playing the role
- Defines an outcome at a level of detail that provides business value
- Is written to the readability level of the target audience (both developers and business peers)
5. Is objectively measurable
- Clearly states the desired outcome in provable terms
- Defines acceptable qualities an acceptable solution must possess
The good news is that your user story does not have to be perfect from the get-go. When the Agile team selects a user story for implementation, the developers will spend time with you, the author of the user story, "elaborating" it. During the elaboration, they will be asking clarifying questions, determining the appropriate testing strategy, and trying to ensure that they truly understand the intent of the user story and not just the words.
The primary purpose of these rules is to assist the team in selecting the appropriate user stories for elaboration to minimize the time spent elaborating stories that they will not implement immediately. The rules are neither absolute nor are they universal. I believe, however, that they facilitate the elaboration process and form a good basis for a discussion on what specifically constitutes a good user story that fits the following:
As a User Story (role), I express what a stakeholder wants (do something) in understandable terms (quality requirement) so the developers can deliver the technology to meet my need (goal).
