The User Story acceptance criteria may seem easy to determine. However, in digital product creation, communication issues represent a significant proportion of the problems encountered.
Especially when we are talking about fulfilling the requirements and determining whether a specific part of work or functionality is completed.
To avoid chaos, misunderstanding, and disputes, you need to share information, ideas, values, concepts, and plans as clearly as possible.
Expressing your expectations towards mobile applications, web applications, or any software is one problem.
Another one is to have clear acceptance criteria, which significantly help accurately and comprehensively determine the customer/user expectations towards a digital product.
In agile methodologies, the User Story acceptance criteria play an essential part. And it is necessary to devote sufficient time to them to ensure a much higher smoothness, productivity, and accuracy of work.
Remember that too-broad acceptance criteria that are too abstract are simply useless. Hence, User Stories and acceptance criteria make it possible to give general expectations specific forms, e.g., we want a product to be awesome and more measurable.
What is a User Story? How to write a User Story? What is the role of User Story in agile methodologies?
How to determine and create acceptance criteria? What is the Definition of Done?
If you want to know how to avoid or actually eliminate uncertainties and damaging ambiguities from a project and how to formulate User Story acceptance criteria clearly, read this article.
Enjoy reading!
What is a User Story?
A very good definition of a User Story can be found in the article "User stories with examples and a template," posted in the Atlassian blog.
Its author, Max Rehkopf, defines User Stories as an "informal, general explanation of software functions, written from the end user's perspective."
In his opinion, a User Story is used primarily "to determine how a specific software function provides benefits to the customer."
The observations in the article "What is User Story?", posted in the Visual Paradigm blog, provide an excellent addition to the above definition.
The authors associated with the Visual Paradigm note that in software development and product management, a User Story is a tool enabling you to grasp the meaning and capture the essence of a specific function from the end user's perspective.
User Story allows you to determine the following:
- What does the user want?
- Why do they want it?
In addition, User Stories provide a simplified description of the user requirements.
When looking at User Stories from yet another perspective, it must be emphasized that User Stories must not be confused with Use Cases.
Even though both Use Case and User Story are about defining, determining, extracting, and communicating user requirements of what the users will be able to do using the system, these two tools are not equivalent.
User Stories are derived from Use Cases. More about the similarities and differences between these tools can be found in the article "User Story vs. Use Case."
Without going into detail, let us just say that User Stories are further defined user requirements for a system, e.g., a web application.
For example, if a Use Case is:
"Online store - Add the product to favorites."
Then the User Story based on this Use Case will be:
"As an online store customer, I want to be able to add products to lists of favorites in order to be able to access them easily and purchase them faster in the future."
The general matrix enabling you to define User Stories takes the following form:
"As a (specified user type), I want to (perform a certain action) in order to (achieve a certain goal/get a specified outcome/realize a value)." As a more detailed variant of a Use Case, a User Story not only indicates the goal but also defines motivation, reason, benefit, plans, and capabilities offered to the user by specific functionality.
In practice, User Stories are written by various stakeholders, such as customers or design and development team members.
In agile methodologies, a User Story enables you to:
- Discover the end user needs
- Define requirements in Product Backlog
- Understand the end-user intentions
- Offer relevant and desired functionality usable for the end user.
The main goal to be achieved through a User Story is to define the roles played by the users in a given system.
User Stories also enable you to determine desirable actions from the end user's perspective.
User Stories also allow you to specify goals, determine what the end users want to achieve, and clarify what makes a given action successful and satisfactory.
In more general terms, in agile methodologies, User Stories constitute the basic method for identifying the real, not postulated or imagined, user needs.
How to write a good User Story?
When writing a User Story, using various templates and techniques is good.
Such as the most popular method in which a User Story answers the three most fundamental questions:
- Who? - Who interacts with the system, and in what role
- What? - What a user expects from the system
- Why? - Why a user interacts with the system, and what benefits and results do they expect?
The first question about the subject is also used to define the role played by the user in the system.
The second question relates to the system behavior, mode of operation, user actions, and system reactions.
The third question allows you to determine the real benefits and results that are non-functional or external in relation to the system.
When writing User Stories, you should also:
- Specifically define when a story is ready, when a specific task is completed, and upon the fulfillment of what criteria.
- Prioritize tasks, dividing them into primary and secondary tasks
- Employ user personas: User Stories should take into account the differences resulting from different user groups and different personas
- Write User Stories taking into account the process phase the user is in and the process phase the story corresponds to.
- Think about their complexity and the possibility of completing them in one Sprint.
It is also important to keep in mind that User Stories have their lifecycle. User Stories go through six statuses or phases in the digital product creation process.
A lifecycle of User Stories includes the following statuses:
- Pending
- To-do
- Discussing
- Developing
- Confirming
- Finished.
In each of these statuses or phases, a User Story takes a slightly different form and is characterized by a different level of specificity and detail. It is also the result of the varying team awareness.
Pending User Stories contain only a short, non-specific description of the user's needs. Such a story requires a discussion and recognition of its importance, which will be possible when the requirements for the system and its basic logic are predefined.
To-do User Stories are the stories that have undergone initial verification, and as a result of an equally preliminary discussion, potentially important story lists have been created.
Discussed User Stories are the stories in which the requirements are set out in much more detail.
Developed User Stories are the stories in which most user expectations are implemented.
Confirmed User Stories are the stories implemented in the test environment to confirm functions.
Finished User Stories are stories that are considered completed.
The effectiveness of User Story writing also depends on whether the team writing them:
- Consistently adopts the end user perspective. As a rule, if the people who write User Stories do not know who the users are and why they would use a digital product, they should not write the stories because the result will be more of a guess, a hypothesis, or a notion than a true reflection of the needs, goals, and motivations.
- Employs Personas to understand the needs and expectations of the end users better.
- Will consistently write simple and concise, easy-to-understand, and comprehensible User Stories.
- Will consistently stratify User Stories: will create general stories (Epic Stories) and increasingly detailed stories based on them, more easily translated into specific time-based tasks.
- Will include a clear and specific set of User Story acceptance criteria in the process of the division of Epic Stories into User Stories
- Will ensure their adequate visibility, availability, and comprehensibility so that every team member will be able to access them easily, almost directly, to get the big picture.
What are the User Story acceptance criteria?
User Stories are an important part of agile methodologies. They define the framework for the daily work of developer teams.
To streamline the work, it is necessary to clearly determine the conditions that must be fulfilled for a story to be considered complete. This is the purpose of defining acceptance criteria.
They allow you to align and coordinate the stakeholders' and developer team's ideas of a given functionality or a specific User Story.
With the documented acceptance criteria, the developers know how a system or a specific functionality should behave to consider its operation correct from the perspective of the expectations.
The User Story acceptance criteria and definitions of done are requirements to be met to consider a given story completed.
The requirements relate to the scope, context, and conditions to be met by software, or usually its part, to be accepted by the user and/or stakeholder.
Each acceptance criterion should be tested independently and have clear scenarios in case of both success and failure.
The usefulness of the User Story acceptance criteria is expressed primarily in their:
- Testability that should clearly determine whether the obtained result means acceptance or not
- Clarity, almost self-evidence
- Conciseness
- Simplicity
- Comprehensibility
- Focus on the user, their perspective, needs, and goals
- Realism: they should express the authentic user experience.
The User Story acceptance criteria, which possess the above qualities in a tangible way, help the developer teams to understand the product to be created.
Their advantage lies primarily in reducing uncertainties, ambiguities, errors, misunderstandings, and inadequacies.
The effective acceptance criteria enable you to:
- Obtain greater disambiguation as regards the expectations
- Minimize the risk of understanding the expectations differently
- Extract and clarify the customer and user vision
- Control the interpretations and discrepancies
- Define boundaries
- Decide whether an application is working as expected
- Align the customer and developer team perspective: both parties are familiar with the conditions and expectations and know how to create and evaluate the operation of a specific application function
- Test the system operation
- Plan tasks
- Prevent scope confusion, a situation where the lack of defined scopes and criteria results in a story being susceptible to changes, which affects the work schedule, budget, smoothness, work productivity, and the team atmosphere
- Avoid mistakes, failures, and misconceptions
- Improve communication: the team and stakeholders can devote much less time to mutual understanding.
The User Story acceptance criteria usually occur in one of the two basic variants or formats:
- Rule-Oriented Acceptance Criteria (checklist template)
- Scenario-Oriented Acceptance Criteria (Given/When/Then template)
The User Story acceptance criteria in the scenario-oriented format take the form of the following sequence:
- Taking into account the preconditions
- When I perform an action
- I expect a result.
Due to its cause-and-effect nature, this type of scenario allows you to collect requirements, predict various use cases, and perform automatic acceptance tests.
The advantage of this scenario is the reduced time needed to write test cases.
If you want to see some acceptance criteria examples, we recommend you the article "Acceptance Criteria for User Stories: Purposes, Formats, Examples, and Best Practices."
The checklist template usually employs the INVEST formula.
INVEST is a checklist (a list, a set of criteria) used to evaluate the quality of a user story, and it helps in writing good acceptance criteria.
In this formula, a good user story should be:
- I – Independent of other User Stories
- N – Negotiable: it should open a conversation, not close it; as long as it is a part of the Backlog, it can be modified and made more specific
- V – Valuable from the user perspective, it should provide the user with some value
- E – Estimable: only in such a formula can it be divided into tasks and scheduled
- S – Small: it should be possible to implement it in the shortest time possible
- T – Testable: it should result in a definitive decision: Completed/Not completed.
When writing acceptance criteria, you should make sure that they are:
- Comprehensible, realistic, and achievable
- Shared by all (developers and stakeholders): resulting from a consensus
- Measurable: enabling you to estimate the time.
To sum up, well-written acceptance criteria provide the team with a specified scope of work before the work starts. The team should know what it is building.
In addition, it allows you to work out a common platform for understanding needs, goals, and issues. The possibility of verifying the stories using automated testing is equally important.
Who writes acceptance criteria?
For the creation of the User Story acceptance criteria, the best results are achieved through the cooperation of the customer/stakeholders and the developer team. Therefore anybody from the cross-functional team can write acceptance criteria.
The acceptance criteria development process should involve teamwork from the business and pure design perspectives.
The criteria describe the user's needs. Therefore, all the acceptance criteria should be based on personas and created before the start of the development work.
This approach definitely allows you to much faster:
- Achieve the goal
- Confront the possibility conditions (e.g., if there are any technological limitations)
- Reach a consensus, e.g., between the Product Owner's standpoint and that of other stakeholders
- Align the perspectives
- Plan the work
- Develop design documentation.
The contractor usually delegates a need analyst and/or a project manager to write the User Story acceptance criteria.
But remember that there aren't any reasons not to engage the other team members, the entire developer team, in this work.
The more so that the recommended standard for achieving the desired result is teamwork or group work.
Mainly based on a dialog that allows you to probe the needs better, pick up the nuances, and further clarify the expectations.
What is the Definition of Done (DoD)?
Whether a specific functionality is completed/done is probably one of the most challenging decisions the teams developing digital products in agile methodologies must make.
The Definition of Done affects:
- Digital product quality
- Digital product excellence
- Its competitiveness
- Usability
- Faultless operation
- User Experience.
The Definition of Done is usually defined as a situation where all conditions or User Story acceptance criteria for a digital product have been met. A given functionality is completed if it meets the acceptance criteria and is ready to be verified and accepted by the users and stakeholders.
According to a different definition, which complements the above one, the definition of done is a list of requirements that a User Story must meet for the developer team and the stakeholders to consider it completed.
The difference between the set of the User Story acceptance criteria and the definition of done is that the User Story acceptance criteria refer to each individual story separately, while the definition of done is common to all User Stories.
To complete a given User Story, both the criteria set out in the Definition of Done and the User Story acceptance criteria must be met.
More specifically, a User Story can be considered completed in agile methodology when:
- All acceptance criteria are met
- The story is accepted by the Product Owner
- The User Story is implemented in the production environment
- The story has been successfully tested
- The functional tests have been successfully passed
- Non-functional requirements have been met.
The answers to the following questions are helpful in the development of the definition of done:
- Has the code been completed?
- Has the code been verified?
- Have the unit tests been passed?
- Have the functional tests been passed?
- Have the acceptance tests been completed?
User Story. Scrum acceptance criteria. Summary
- The process acceptance criteria, project acceptance criteria, and User Story acceptance criteria only appear easy to define.
- User Stories are informal, general explanations of software functions written from the end user's perspective.
- A User Story is primarily used to determine how a specific software function will provide benefits to the customer.
- The general matrix enabling you to define User Stories has the following form: As a (specified user type), I want to (perform a certain action) in order to (achieve a certain goal/get a specified outcome/realize a value).
- As a more detailed variant of a Use Case, a User Story not only indicates the goal but also defines motivation, benefit, and capabilities offered to the user by specific functionality.
- In agile methodologies, User Stories are the basic method for identifying real user needs.
- More detailed criteria should lead to an understanding of the goal. They should allow the developers to know from the beginning how a system or a specific functionality should behave to consider its operation correct from the perspective of expectations.
- In Scrum, in IT projects, the User Story acceptance criteria and test acceptance criteria are a set of requirements to be met to consider a given story completed.
- It allows you to avoid misconceptions already in the creation phase. As a result, when implemented, a story will not require necessary corrections, and the final product will enable the user to achieve their primary goals.
- For the creation of the User Story acceptance criteria, the best results are achieved through the cooperation of the customer/stakeholders and the developer team.
- To complete a given User Story, both the criteria set out in the Definition of Done and the User Story acceptance criteria must be met.
