Better Understand the Purpose of Story and Acceptance Criteria
Some who practice scrum believe that acceptance criteria are optional. Others only write a one sentence summary and don’t even bother writing story requirements. These practices could be a recipe for disaster, because developers may not understand what to develop and testers may not know what to test.
At GSD Mindset, we teach that acceptance criteria are mandatory, and we spend lots of time helping those new to scrum learn how to write stories. The story describes the requirement for that next slice of functionality the team needs to build. The acceptance criteria describe how the product owner and team know that the functionality works; they also describe what happens when something goes wrong.
If story content so profoundly impacts the team’s ability to produce quality work, then why do so many teams write crappy stories? We get that it takes time to think through and document the specific functional requirement, plus also to think through how to tell that the function works. We get it that most teams write their stories the night before or the morning of Story Grooming. We get it: your team is busy.
How much busier does the team become when stories take too long to close? How much busier does the team become after they build the wrong functionality and they have to rewrite it? How much busier does the team become when the project gets behind schedule?
After high level design and Epic breakdown, writing good stories is one of the most important activities the team performs. Taking the time to write a clear, concise story with clear, concise acceptance criteria can be one of the most important predictors of green project status and excellent quality.
How Do You Write a Good Story?
The Story format is simple:
As a <user role>
I want <to perform some function>
So that I can <achieve some goal/benefit/value>
When you sit down to write a story, think about who will be using the functionality, even if the user is another automated process. From the user perspective, visualize what function the user will be performing and why this slice of functionality is important.
For example, think about the customer of a shopping website. If the requirement is to build the first slice of a search tool, think about how the customer wants to search. Suppose research shows that most customers are brand conscious. Then write the first slice to search by brand:
As a customer of this shopping site,
I want to enter my favorite brand name
So I can see easily see all the products available for sale and quickly browse the list.
The requirement for this slice of functionality is clear. The reader understands what the customer wants to do and why: Because they came to the website with a specific brand in mind.
Yes, there are other ways customers search: by price or clothing type or gender, etc. But agile scrum stories only describe a slice of functionality. Every one of those other search parameters should be described in separate stories.
The acceptance criteria format is simple too:
Given that <I am able to perform the new function>
When <I complete the function>
Then <something happens to show success/failure>
How does the tester know that the brand search is working?
Given that the customer enters a brand name,
When the customer clicks to search,
Then the website returns the list of clothing in stock for that brand and displays a list that includes: small image, product name and price.
What does the website do if there is no clothing in stock for the brand?
Given that the customer enters a brand name,
When the customer clicks to search,
If there is nothing in stock for the brand, the website returns a message that includes the search parameter and offers the customer options to search for similar brands (e.g., people who search for A also search for B).
The effort to write a complete story that clearly describes required functionality and what to look for when testing does not really take much more time than writing a crappy, incomplete story. If your team is not writing stories complete with acceptance criteria, I urge you to try writing complete stories for at least 3 sprints.
I’ll bet you love the results!
Cynthia Kahn
Cynthia Kahn
CynthiaK@gsd.guru 503.799.5500