How to Write Effective User Stories and Acceptance Criteria

In the world of Software Development, the word 'Requirement' describes what the customer is looking for, what their goal is, or what they need to solve a specific business problem or need, which will ultimately help the organization boost its business.

Whether it's a product-based company that develops software products or a service-based company that offers services in the various types of software, the key point for all of them is the 'Requirement', and the success of the project or product is determined by how well the requirements are defined.

In this context, let's try to understand what user stories are and how to write them effectively to minimize ambiguity.

What is a User Story?

In Agile software development, a user story is a short description of the product functionality or feature from the perspective of the person who wants to use that functionality. A user story usually defines the smallest possible requirement and focuses on only one functionality or feature at a time.

The commonly used standard format in writing a user story is given below:

As a (user role/customer),

I want to (goal to be accomplished)

So that I can (reason of the goal)

Let's consider the case of a Supplier Portal that allows companies to manage and connect with 3rd party suppliers of goods and/or services. The web-based automated Supplier Portal handles registration, onboarding, and compliance, enabling suppliers to self-register and submit compliance and other required details such as VAT number, bank details, etc. Suppliers can raise invoices against the items/services they have provided and track their invoice status (pending, approved, rejected, paid, etc.).

Some user stories for the Supplier Portal from a Supplier's and Invoice Authorizer's view are given below:

1. As a Supplier, I should be able to register myself with the Portal so that I can raise invoices
2. As a Supplier, I should be able to raise invoices so that I can track the payment status
3. As a Supplier, I should be able to upload details of invoices using excel so that I can track the payment status
4. As a Supplier, I should be able to edit rejected invoices so that I can re-submit them for the approval
5. As a Supplier, I should be able to add invoice line details so that it can calculate the VAT amount automatically
6. As an Invoice Authorizer, I should be able to able to approve the invoices so that payment can be released to suppliers
7. As an Invoice Authorizer, I should be able to reject invoices with comments so that Suppliers can re-submit them

You must rely on the INVEST acronym for assessing a user story's quality.

Independent: A particular user story must be developed independently of other user stories - Avoid introducing any dependencies or combining user stories.

Negotiable: User stories are not contracts; hence it would need the flexibility to be adjusted based on how much gets implemented.

Valuable: How is it beneficial or what value it provides to users, customers, and stakeholders

Estimable: The team needs enough information to estimate the efforts

Small: It should be sized appropriately for completion within a Sprint (includes testing)

Testable: Meets customer needs, is understood by all and is clear enough to assess if the story is done. (it should be easily unit and acceptance tested)

What are Acceptance Criteria?

Acceptance criteria (sometimes referred to as the "definition of done") are the conditions that must be met in order for a user story to be marked as complete and be accepted by a user, a customer, or any other system. It is usually presented in the form of statements that can be verified as pass or fail. Each product backlog item or user story should have at least one acceptance criterion.

Good acceptance criteria should include

• Usability: Make sure to contain measures of usability in the acceptance criteria. It indicates how to answer the questions like: Is it easy to use? The important point is to identify the correct measurements and ensure each is quantifiable.
• Functionality: Acceptance criteria define what precisely must be developed by the development team. Once the team has exact requirements, they can divide user stories into tasks that can be estimated correctly.
• Error handling: Acceptance criteria may require the system to identify error cases and how each error should be handled. For example, Invalid password input or password format requirements. Acceptance Criteria should define these scenarios and explain how a system should react to them.
• Performance: Acceptance criteria should define system performance from the individual user perspective. For example, UI should be responsive, or it should navigate to a new page
• Stress tests: Acceptance criteria should describe how the system should respond when it is under stress because there are many users, transactions, volumes, or queries. Acceptance criteria should also define acceptable thresholds for stress testing. For example -The system responds within a 275-millisecond threshold when there are 100 users submitting queries simultaneously.

 Here are some good acceptance criteria for the user story that we discussed above:

"As a Supplier, I should be able to register myself with the portal so that I can raise invoices."

• The supplier user must provide information for every field marked as required.
• All fields should successfully pass validations (e.g., Name cannot contain numbers, phone number must contain a numeric value, etc.). Error messages must be displayed for incorrect data format.
• Users should be able to upload a profile picture.
• Users should be able to set preferences regarding a business.
• Users should be able to upload VAT certificates and Bank statements as attachments. The error message must be displayed if the uploaded file format differs from the format it must be attached.
• Upon clicking the "Register" button, the system must display the message "Supplier Registered Successfully".
• The system must send an onboarding email to the Suppliers upon successful registration.
• The system must send a copy of the onboarding email to the concerned team.

Conclusion

In a nutshell, writing effective user stories and acceptance criteria is a win-win situation for both clients and development teams; it not only helps the team know exactly what they have to do but also keeps the client informed of the development process.