As part of SVPM team I got a better understanding of user stories, their purpose, their structure and benefits from writing a good user story.
First of all what is a user story? User story is a short description (one sentence) of a feature, described from the user’s perspective. It is the smallest piece of work that brings some kind of value to the end user and can be accomplished in the duration of one sprint.
Common form of a user story is:
As a (type of user/role or persona), I want to (an action/goal/need), so that (a benefit or value/why).
User stories need to be written in plain language, so that a non technical person could understand what feature/functionality is described and what should be developed. When writing user stories, we should be concentrated on the product and we should offer more information and clarification about the product/product feature that we are building, defining the what (what we are building) and not the how (how are we going to build the feature). That should be left to the development team.
Before writing a user story, we need to have a good understanding of the real users (end users) of the product, and think as a user. This can be accomplished through good user research. You can define couple of user personas representing different profiles, define their “problems” meaning their needs, and based on that you can start developing ideas about functionalities that would address those needs and resolve the “problem”.
Since user story does not contain details on the functionality, to give more clarity to the development team on what they should develop/build and the functionality should perform we create the Acceptance criteria. This will give clear information to the developers when are they done with development and also give information to the QA/testers how their test scenarios should look like and what result is acceptable. Also very important is that AC makes it easier for everybody from the dev team to get on the same page regarding the user story. In short it is a condition that confirms when a user story is completed. AC is very similar to DoD, and I would say that in order for a user story to be done, it need to meet both the AC and DoD.
Just like the user story, the acceptance criteria should be written in plain language. Acceptance Criteria/DoD is owned by the Scrum team, the POs have their input almost always, but at the end of the day it is owned by the Team, because the team is the one that will deliver the functionality/increment, and they know exactly how they will accomplish that.
Acceptance criteria can be Rules-oriented or Scenario-oriented. Rules oriented are written in a form of a list or bullet points and Scenario oriented, are as you guessed in a form of a scenario for each criteria that needs to be fulfilled. You can really use either one, they both work just fine. The scenario oriented AC is very popular among Agile teams because they use it to do manual and automated testing.
Most common scenario oriented acceptance criteria format is Given/When/Then derived from Behavior Driven Development (BDD), and the same format is used when writing acceptance test for a given feature/functionality. This format of writing acceptance criteria/DoD is also known as Gherkin Syntax.
Bellow I am offering my example of a user story and AC and DoD for the same. The example is referring to a search bar on our SVPM page.
-User story
“As a visitor to the SVPM page, I want to be able to search on the web page, so I can find blogs and information and stay informed about PM and Agile”
-Scenario oriented AC:
Scenario: Visitor user searches for information
“Given that I am a visitor user, When I open the SVPM web page and click on the Blogs tab, Then system shows me all the blogs posted, and the system shows me Search bar on the right top corner of the web page, When I fill in the search bar with key word about the information I need, and click the search button or press Enter on the keyboard, Then the system displays the links to all the blogs that contain that key word written in the search bar, and if the system does not have blogs with that key word, Then it displays message no blogs found.”
-Definition of Done
“Create a search option on the web page that will be able to search key words through the data base of all the blogs published on the SVPM page, and display all search results in a list. If there are no matches, display message no blogs found”
This is my short knowledge of user stories and acceptance criteria that I gathered since being part of SVPM team. If you have any additional information, or you want to offer your knowledge of User Stories, Acceptance criteria, Definition of done, or anything Scrum related, do not hesitate to write a comment and open a discussion. I am eager to learn, improve and be more Scrum-tastic 🙂
Thank you Ana, it’s a great article. It helped me get a better understanding of user stories, AC and DoD. Clarification of defination with example was great.
Today only I and Marina (my team member) were discussing about the same topic but we could not explain it in such a simple and clear definition .
I would like to thank Sam for the summary in the comments as well.
I am glad that you found the article usefull. I might include couple more examples in the comments, just to have wider range of examples.
This was such a great article and description of user stories, acceptance criteria and DoD that clarified my confusion on the concepts!
I’d like to share with you my understanding of the rules-oriented AC for the same user story:
User Story: “As a visitor to the SVPM page, I want to use a search field to type an author’s name, so that I could find matching blogs and information about PM and Agile.”
Search acceptance criteria:
• Search field is placed on the top bar
• Search is performed if a user types author’s name
• Search starts once the user clicks “Search”
• Search is in English, Spanish, Swahili, Tagalog, Guarani, Farsi
• The user can’t type more than 150 symbols
Thank you for not just clearly explaining the purpose and how-to of User Stories, Acceptance Criteria, and Definition of Done (DoD), but also giving an example we can easily try right here on the page!
I also love how you show the difference between the DoD and Acceptance Criteria – where DoD relates more to “what does it mean for this story to be done”, Acceptance Criteria gives clear instructions on how to validate that DoD was achieved.
I am not familiar with Gherkin Syntax, I will be looking that up next! My quick search produced this: https://cucumber.io/docs/gherkin/reference/ If you happen to have references you like better I’d appreciate you sharing them.
Also, if you are up for posting what a rules-oriented Acceptance Criteria for the same User Story would look like I’d love to see the difference. We keep learning!
Very “Scrum-tastic”! 🙂
Thank you Ana for the simple and clear examples! The scenario helps give contexts, and I can see the difference between the user story and AC. And gotta love the ‘scrum-tastic’ at the end!
Great summary and example. I tried the search and it worked – brought me to this blog and others that talk about user stories and their application.
Great to hear Nancy. Having more examples like this, or having workshops where people can practice creation of User Stories etc for different functionalities/features, can help a lot, just getting the grasp of the concept.