I have been given a user story / epic which is display a web-page giving details about a retail store for a company.
Simply put, if the url was mywebsite.com/newyork it would display the new york store details
mywebsite.com/athens would display the athens details etc.
The things that would be displayed are things like opening hours, location, phone number
From my reading it looks like user story acceptance criteria are very high level. As such
I have 2 questions about acceptance criteria for my current project.
Questions
1) The product owner has put display Welcome to myRetailStore yyy where yyy is the name of the store page being displayed as a h1 tag at the top of the page underneath the main navigation bar
- is that a relevant acceptance criteria? should the part about h1 tag be in the detail?(as it seems not high level enough to me)
2) assuming that there were 400 stores does checking the fact that Welcome to myRetailStore New York is displayed for New York mean that story has passed its acceptance criteria or would it need to be checked for all 400 stores?
Personally, I would say an acceptance criteria of “Must be an <h1> tag” is not an appropriate acceptance criteria, unless the PO would be willing to reject the story if the team used some other tag and applied styling to make it look like an <h1> tag. In other words, is the use of <h1> truly a required part of the solution?
I would recommend engaging in a conversation with the PO to make sure what’s really important, and why. Maybe there’s a specific business reason for an h1 — to support screen readers, perhaps? Or maybe the PO knows only enough HTML to be dangerous and doesn’t realize that the tag isn’t as important as the final rendering.
As for the second part, I would say that just because it shows up for new york is not sufficient. As a PO, I would write the acceptance criteria such that it’s required that the proper greeting shows up for every supported store.
That doesn’t mean that you have to have 400 test cases, but it does mean that you have a sufficient number of test cases to prove that all the edge cases and permutations are covered.
Remember: the goal of acceptance criteria is to help the team — so they know when they are done. If being specific about tags helps the team, it’s an appropriate criteria. If it gets in the way of the team doing it’s job, it’s not.
It depends.
The level of details in acceptance criteria may very depending on the type of story. Consider creating a user story for a web page or for a new programming language? I suppose different level of details will be needed to accept the story (meaning it is done correctly).
I find that the more detailed the AC are, the less are the chances of misinterpretation of requirements by developer.
In case it matters how the greeting message is displayed, specify it, if not it can be omitted.
For 400 stores, if pages are templated – and store names are populated in, then the story should sound like “when I open a page for a specific store (newyork) correct fields are populated in the template (hours, name, etc)” – no need to repeat it for each store. As there would be another story about creating the data records for all stores with correct data.
I would recommend to take a look at tooling for ATDD. We’ve used SpecFlow and it was very useful in providing just the right amount of details.