The Structure of User Stories
User stories are a without a doubt a great tool for expressing stakeholder requirements on an IT project. However, not all user stories are created equal. In particular, there is room for debate regarding the “best practice” structure for a user story.
A couple of schools of thought are:
“As a <role the author represents>, I/we can <do or have something> <with these qualities> to <achieve my business goal or objective>”
versus
“To <achieve a business goal or objective>, <roles> can <do or have something> <with these qualities>”.
What Is the Difference?
Whereas the first version focuses on the role, the second focuses on the goal. Like the “Chicken or the egg” question, we now have the “Role versus the goal” discussion.
As a business analysis instructor, I have taught thousands of students the “proper” structure of user stories derived from the original Connextra team recommendations (and modified to allow for quality parameters):
Example: As a website visitor (role), I can view all courses (do something) I need to qualify (quality requirement) for the CBAP® exam (goal).
I like the recommendation from Chris Matts that the value should come first and propose the following modified “proper” structure:
Example: To qualify for the CBAP® exam, website visitors can view all courses they need.
As a fan of minimal verbiage, I like the brevity and power of expression in this version. In addition, this phrasing ties the user stories directly to the business goals / objectives and completes a simple, 7 step Business Analysis Life Cycle:
- In the current situation, there is a business problem or opportunity.
- You (anyone wearing the Business Analysis hat) define business goals/objectives that would solve the problem or allow you to seize the opportunity.
- To achieve each goal/objective, you identify involved actors/users that create user stories expressing what they need/want <with certain qualities>.
- To validate that the actors/users get what they need/want, they define <acceptance criteria> for testing purposes.
- Developers do their magic (i.e., develop the solution – or pieces thereof).
- Testers (anyone wearing the testing hat) ensure that the delivered components pass the <acceptance criteria> and meet <certain qualities>, thus proving that the user story has been satisfied.
Validating all user stories that share a common goal/objective ultimately validates the goal/objective and, once you have validated all goals/objectives, you have a successful project completion.
End of story and a happy ending for all involved.
