Let us get to the point straight first: What Is Acceptance Criteria?
Acceptance criteria are a set of predefined requirements to be met to mark a user’s complete story. It is also called the “definition of done” as they determine the requirements and scope to be executed by the developers to consider a finished story.
If you are a product manager or owner, you must be responsible for the writing of the acceptance criteria for finished stories. Here are a few examples to help you define the acceptance criteria, to explore and practice writing. It is a form of agile requirements for documentation.
Traits of effective acceptance criteria?
- They must be testable. As they help formulate the definition of ‘done,’ for the engineers, it should be easy to test and must leave no room for interpretation. The tests must reveal a yes/no or pass/fail.
- It should be clear. These documents need to be as simple as it can get, and must be straightforward.
- Easy to understand. It makes no sense if it ain’t easy to understand. If you’re unsure of the documentation, take time to make adjustments.
- Must provide the user with a perspective. Acceptance criteria is a way of looking at the problem from the customer’s standpoint. Therefore, it must be written in the context of an experience.
Why Do We Need a user story Acceptance Criteria?
The Acceptance criteria serve many purposes for teams cross-functional. It leaves room for interpretation and clarifies the expected outcome of a user story. It also provides developers and QA with a clear way to determine if a story is “done.” The reason why you must incorporate these requirements into the process is as it defines your desired outcome even before the development begins. They help promote alignment and the shared understanding that reduce the likelihood of surprises. Along with helping people set and manage their expectations the acceptance criteria also help the developers. It reduces the added content ambiguity and creates a defense against creep. If you don’t have a requirement defined at the beginning, it becomes difficult to sneak it midway through. Acceptance criteria also define the fail/pass testing done to determine a story as complete.
Who is Responsible for the writing?
Anyone in the virtual world could write the acceptance criteria for user stories. However, It’s the product of the owner or the manager responsible for writing or facilitating the discussion. This is done to ensure that the requirements are written with customer needs in mind. It is good to write the acceptance criteria as a group activity that includes both dev and QA representatives.
Involving the developers and QA have their benefits-
- It helps communicate with the developers of the product strategy and vision.
- They can help find missing pieces or identify dependencies.
- Can help understand the product owner better and to know what the user stories would look like.
When should one write a User Story Acceptance Criteria?
Most of the product managers and owners choose to write as the backlog starts to groom and plan meetings to discuss and refine based on the feedback. At its best, acceptance criteria must be defined before the development begins. Or there are chances of missing the benefits but not too early as it may backfire too. The agile method encourages frequent reprioritization based on the findings meaning from sprint to sprint. Therefore, it is best to write the acceptance requirements as and when you decide to move into the sprint backlog. This will help with maintaining the time used on writing out specs for the user stories resulting in deprioritization. Then you can move ahead to define the requirements and finalize them in meetings.
How to Format the User Story Acceptance Criteria?
There is no one way of writing the acceptance criteria. One needs to first establish a format and then the procedure to create the acceptance criteria consistently for your team. If your new, expect a little trial and error and use one of two formats:
1. The Given/When/Then Criteria
This user story requirement is similar to the traditional formatting. It follows a standard user story template: “As an (intended user), I want to (intended action), so that (goal/outcome of the action).” In this format, the template followed is: “Scenario: (explain scenario). Given (how things begin), when (action was taken), then (the outcome of taking action).”
It might look confusing at first but a realistic example, it helps understand better. Here is an example:
User story:
- As a product manager.
- I want to score potential ideas.
- So that I can decide what to include in my product roadmap.
- Acceptance criteria for user story.
Scenario:
- The product manager ranks and adds potential ideas as best based on the benefit versus the cost.
- Added two or more ideas and scored them using the Benefit vs Cost model
- When I click the Rank button
- The ideas get sorted as the top-scoring ideas.
2. Verification List Acceptance Criteria
Having a checklist is another viable option for formatting the user story and is extremely straightforward. Work as a team to define a list of statements (pass/fail ) with meeting the functionality to be marked complete.
In the end, practicality matters more compared to the format of the acceptance criteria. If your team understands, it is an effective acceptance criterion despite how the format looks like.
To Conclude:
The Acceptance Criteria is an important component for the user story to be marked as complete. It helps define the scope, desired outcomes, and the testing for the functional piece for the delivery team working on it. The process itself is of creating and agreeing on acceptance criteria with invaluable communication opportunities between the product and the developers.
