PremierAgile

This article is all about the difference between a User Story and Acceptance criteria in Agile methodology. A User Story refers to a requirement for any feature or functionality that usually consists of 2-3 lines. For example, the presence of a camera icon in the chatbox of WhatsApp to capture and send photos to your family and friends simultaneously.

On the other hand, the Acceptance criterion is nothing but the set of business terms and conditions that the functionality should meet to be approved by the stakeholders or Product Owner. For example, an error message Camera could not be started appears when you find some issue with starting your phone camera while chatting with your friend.

User Story, though not a Scrum term, plays a crucial role in Agile methodology as they shift the focus from software goals to a user-friendly description of desired potentials. Similarly, it is also crucial to implement a clear set of Acceptance criteria in the Agile methodology to include discussions with the end-users. Now let us find further how the User Story is different from the Acceptance Criteria. 

What are the goals of User Story and Acceptance Criteria?

A User Story is used to shift the focus from what to why you are building. It is made to begin a conversation between the individuals who would apply the story and the owner of the product, who aims to solve the underlying business issues rather than just offering a requirement. The goals of a User Story are as follows:

User Story Goals:

• To begin a conversation on who needs problem-solving, what problem it is to be solved, and why it is to be solved.
• To concentrate on the business issues that require to be resolved.
• To make a small and vertical model functionality it only aims to go through each layer required at the moment.
• To exhibit a requirement as simply and shortly as possible.

On the contrary, the acceptance criterion is a set of precise details where the User Story allows the team to decide the precise information of how something would be built. Have a look at the goals of Acceptance Criteria, which are as follows:

Acceptance Criteria Goals:

• To make sure everyone understands the problem normally.
• To confirm what the team should form before they begin work.
• To assist in verifying the User Story through automated tests.
• To help the members of the team to understand when they should stop working on a story.

User Story: 

The User Story is mainly intended to invite a conversation. There is no specific format for User Stories since they are not official Scrum tools, but there is a common structure for it, and it is As an I want so that . Check out some of the examples of User Stories right below:

• As a user, I want to be able to enter my pin code when my transactions are above $50 so that I can stay secure although my card is stolen.
• As a user, I should be able to pay with the tap on my debit card so that it would take less time for me to check out the process.
• As a buyer, I want my debit card to be reviewed to make sure that they are valid, so I would not lose money on the acceptance of invalid cards.

Acceptance Criteria: 

It is very important to understand the Acceptance Criteria as well as all other conditions as compared to a User Story. It is because if a requirement is vague or incomplete, it can be continued to the next Sprint. However, if the Acceptance Criterion is found to be missed, then it is not possible to release the User Story. You can look at some of the examples of Acceptance Criteria just below:

Have a look at this User Story:

As a user, I must be able to pay with the tap on my debit card so that it would take less time for me to check out the process.

This leads to the following acceptance criteria:

• Tap is prohibited under $20
• Tap limit is $50
• The linked account is reviewed to ensure sufficient balance.

The problem with the above-mentioned Acceptance criteria is that they are full of vagueness. Hence, there is a popular method to describe Acceptance criteria, and it is nothing but Specification By Example. It can also be called Acceptance Test-Driven Development (ATDD) or Behavior Driven Development (BDD).

Note: User Story can sometimes be referred to as Product Backlog Item or PBI. In Agile Methodology, every User Story connected with its Acceptance criteria is verified against the Definition of Done to make sure that they are complete and correct.

Importance of Three C's of User Story in Agile Methodology

The three C's of a User Story are card, conversation, and confirmation. This formula is established by Ron Jeffries, and it assists in maintaining a contract between the technical team and the business on the meaning of the User Story. Each C has its elaboration of a story, which are as follows:

Card:

The User Story is made using a simple statement that fits on a 3 x 5 index card; however, it should follow the role-feature-benefit format. For example,

As a trainer, I should be able to include a new course so that the new students would get attracted to it.

Conversation:

Even though the User Story begins with a simple and brief statement, you should make the details appear before you start working on the story as a team. An Agile team should involve certain things in the document, including the Development Team itself, such as Business Analysts, Testers, Developers, etc., and representation from the company (generally the product owner). Some of the examples of User Story conversation include:

Developer: Is there a need for a trainer to upload the courseware onto a website?

Product Owner: No, the trainer just needs to include details about the course that would be rendered. Also, advertise the feature in a way that students would get on an interest list. This story offers the trainer the potential to advertise a course.

Developer: What columns should be added?

Product Owner: Date and times, abstract, location, course title.

Like this, various conversations can be added, and the User Story will be updated by the team with the details they have collected from the conversation. Afterward, they would discuss how to implement and accordingly they carry out certain tasks to complete the story. Even though the User Story is written from the viewpoint of the user, the tasks for the developers are written by the Development Team, and they even involve the technical implementation information.

Confirmation:

As a Development Team, you should have a good understanding of how the function would operate in distinct situations, no matter if it is an error condition. You should receive a confirmation in regards to the Acceptance Criteria from the Product Owner. You can go through some of the criteria given below that should be fulfilled to complete and accept the story.

• A trainer should be able to include a new course by filling in dates and times, abstract, location, and the course title in a form and clicking on the "add course" button.
• If any columns are found to be incomplete, or other details are invalid, an error message would pop up.
• If the course has been included properly, it will be exhibited publicly on the course website, and it would also have a button for a student to show interest.

The interested button would be added to let the user enter a name, phone number, and email address. Every student's information would be stored and connected with the new course.

What are the Responsible Roles of Acceptance Criteria and its Creation?

The Product Owner defines and writes a few of the criteria while he or she forms the Product Backlog. Then, the other details are further determined by the team at the time of User Stories discussions right after Sprint Planning. However, there are no specific conditions while selecting the individual responsible for writing the Acceptance Criteria.

If the client has enough knowledge of technical and product documentation, he or she can document them. During this time, the client prefers to negotiate the criteria while discussing with the team to get rid of mutual misunderstandings. Else, the Acceptance Criteria are formed by a Project Manager, Requirements Analyst, Business Analyst, or Product Owner.

Conclusion

You can even achieve a deep understanding of User Stories and Acceptance criteria by doing a deep study of them. Make a note that there is no course or tool obtainable in the market to carry out this. It is based on knowledge about the product, experience, and logical thinking. You can achieve this in any of the ways like talking to the Business Analyst, participating in pre-plan meetings actively, or studying on your own. If you make a lot of efforts, you can learn about the difference between a User Story and acceptance criteria in more detail.

References

1. https://www.softwaretestinghelp.com/user-story-acceptance-criteria/
2. https://warren2lynch.medium.com/what-is-the-difference-between-user-story-and-acceptance-criteria-9464e102f0aa
3. https://www.altexsoft.com/blog/business/acceptance-criteria-purposes-formats-and-best-practices/
4. https://techbeacon.com/app-dev-testing/agile-leaders-guide-writing-user-stories 

Useful Links:

Advanced-CSM Course Training Ghent, Certified Scrum Master Online Training Jacksonville, Leading SAFe Virtual Certification Training Raleigh, Advanced Certified Product Owner Training Brisbane, A-CSM Training Providence, CSPO Online Course San Antonio, Scrum Master Certification Boston, CSM Online Training Fayetteville, Scrum Master Online Course Adelaide, Certified Scrum Product Owner Certification Atlanta