The 5 Key Ingredients to Write Better Stories
Every time we teach a GSD Scrum Training workshop, one of the most difficult concepts for students to grasp is how to write a story.
On the surface, the concept seems quite simple:
Describe the user’s functional requirement from their point of view and include acceptance criteria, so quality assurance testers know the finished product meets the user requirement.
The story and acceptance criteria format below looks simple enough, right?
Story format:
As a <user role>
I want <to perform some function>
So that I can <achieve some goal/benefit/value>
Acceptance criteria format:
Given that <I am able to perform the new function>
When <I complete the function>
Then <something happens to show success/failure>
Then, why do so many people have trouble writing stories? We think it’s because scrum assigns the Product Owner responsibility for writing the stories, and most Product Owners have never written functional requirements. That’s why we recommend scrum teams include a Business Analyst or Systems Analyst to work with and train the Product Owner.
Even if an analyst helps write the stories, a story is a very specific type of functional requirement. I like to compare it to a mini use case. The story begins with an event and follows a process through to a successful or unsuccessful outcome.
Well-written stories meet the following criteria:
- Stories deliver a completed slice of working functionality.
- Stories describe the user experience, not how to build it.
- Stories contain clear functional requirements and acceptance criteria.
- Stories are small enough to be completed within the time allotted to the sprint.
- Stories do not leave the application in an unstable state.
An example high-level use case would be Customer Account Maintenance. A good way to identify the stories that comprise this use case is to brainstorm all the reasons that a customer would access the application to execute this module.
Some candidate stories for Customer Account Maintenance:
- Create a New Customer Account
- Update Customer Account Information
- Change Forgotten Password
- Retrieve Forgotten Username
Each candidate story is a single slice of functionality that represents a small slice of the overall functional requirement. Each story requirement is small, so it can be completed within the sprint boundary. The team can start by implementing Create a New Customer Account, and then add the new functionality described in the other three stories at any time. That’s because each story can stand on its own and, if described correctly, will not leave the application in an unstable state.
Let’s write a story together. We want to be sure to clearly describe the user experience and quality assurance criteria. Although traditional scrum says that acceptance criteria are optional, we disagree. Everyone needs to understand both the requirement and how to tell if the product works as intended.
A well-written story for Update Customer Account Information:
Story:
As a customer
I want the ability to update the personal information on my account
So that I can keep the system up to date and continue to receive timely statements and product offers.
Acceptance criteria 1:
Given that I have previously logged into the system
When I access the personal information update page
Then I am able to update my first name, last name, address, phone number and email address
Acceptance criteria 2:
Given that I have updated my personal information
When I click Save
Then the system checks the validity and format of the data entered. If there are no issues with the entered data, the system updates the database. If there are issues with the data, the system displays an appropriate error message(s) and does not update the database.
The requirement is clear. Everyone understands what the customer wants to do and what information is considered personal account information. In addition, the application validates the customer entry, so invalid data does not get saved to the database to ensure data integrity.
The completed story for Update Customer Account Information meets all our criteria and, if it passes quality assurance, it could be moved to production at the end of the sprint.
Another thing to keep in mind is that the story’s requirements cannot depend on another team to perform work in order to close it. If a high-level use case contains functional requirements with dependencies across teams, the Product Owners of the affected team must clearly divide the experience into independent functional descriptions.
Once you understand the rules, the art of story writing becomes more straight-forward. Be sure to read and review each story at Story Grooming before sizing, so everyone on the team understands the requirement.
Want to better understand how to successfully practice scrum in the real world?
Then you should read our GSD Scrum Handbook.
Cynthia Kahn
Cynthia Kahn
CynthiaK@gsd.guru 503.799.5500
Sometimes the PO needs to write “epics” that will later get broken down into implementable stories. Epics should have the same format, but will usually not meet the criteria given. Even acceptance criteria might be too much of a precommitment for the initial writing of an epic. Nevertheless, epics are valid stories.
Without epics, the backlog cannot provide an overview of what the product is intended to be. Breaking down all the epics into implementable stories would be waterfallish. We can start working on the implementable user stories from just one or two epics so we can establish velocity, identify impediments, and get technical and user feedback before committing to how the rest of the epics get broken down.