Show
Project Acceptance Criteria: Checklist and Examples17 min read · 28.07.2021 ·👍 Rating — 5 (1 vote) It’s hard to argue that any project’s ultimate results heavily depend on how well all the parties and team members understand each other’s needs and wants. Software development is not an exception. Creating technology solutions is usually a somewhat complicated process that often involves people with different backgrounds (i.e., CEO, CTO, tech specialists, marketers, etc.). How do all these people who speak different professional languages agree on a shared product vision? And what exactly do clients mean when they say they need stunning solutions to make their businesses work better? The answer lies in the acceptance criteria, and we will discuss them in detail in this blog post. What are the acceptance criteria? Who writes them, and who needs them? And the most crucial question – why? We will provide you with some examples to better understand how the acceptance criteria may look like in practice and capture their vital role in the project’s success. But let’s start from the basics and take a brief look at other essential components of specifications. Specifications, Epics, and User StoriesSoftware Requirements Specifications or simply “SRS” or “specs” is a document that describes all the product features and requirements. Specifically, it is used to define how the system is meant to operate and what functionality is required to satisfy user needs. Also, specs usually contain some non-functional requirements such as security, performance parameters, etc. Software development documentation SRS (Software Requirements Specifications) often consists of epics and user stories. Simply put, an epic is one big piece of product functionality. For example, registration and user profiles are epics. Specs are divided into epics that allow everyone involved to grasp the big picture and discuss high-level product details (for example, between tech leads and CEOs). The specific tasks within an epic are written in the form of user stories. they describe the required functionality from the user’s perspective. These are, for instance, “Sign-up with e-mail,” “Log out,” etc. As a rule of thumb, the following wording is used to create a user story: As a [type of user], I want to [action] so that [outcome]. So here is a user story to describe a task for a system when a user forgot his or her password: As an unauthorized user, I want to have an opportunity to recover my password using my email to have a new password for my account. Epics, User Story, and Initiatives However, as you may see, the above statement lacks many details and creates room for ambiguity. That’s why user stories usually go with a set of acceptance criteria. Let’s cover them next. In this video, you will learn about Agile User Stories and Acceptance Criteria. What are the Acceptance Criteria?In short, acceptance criteria are the conditions that a specific user story must satisfy to be considered as completed, you may think of them as a checklist that helps verify if a coding team built the right feature and whether it is completed correctly. Acceptance Criteria can include details such as:
To figure out the minimum set of actions your team needs to take, you must thoroughly understand the complexity of a certain function. If a new feature is involved, it will be essential for you to write as many detailed Acceptance Criteria as possible to help your team avoid confusion. There are no templates of acceptance criteria. Neither would you find an exhaustive list of requirements that should be covered by acceptance criteria associated with a particular user story. Every product is unique, thus, everything depends on the client’s demands and specifics of the system to be developed. For instance, acceptance criteria may describe the functionality, expected level of performance, constraints, restrictions, interaction with other features, etc. Let’s say a coding team needs to work on a “Reset password” user story. In such a case, the acceptance criteria might be the following:
The above example is oversimplified, of course. In practice, acceptance criteria may be written in different formats (for instance, bullet points or a table or scenarios). The only requirement is that they should cope with their primary task, i.e., show what exactly should be in place to make the system work as intended. Acceptance criteria for your solution Need to consult on acceptance criteria for your software project? Types of acceptance criteriaNow that we have further defined the acceptance criteria and figured out what functions they perform, let’s talk about their variety. There are three main types of acceptance criteria:
Scenario-oriented acceptance criteriaMany teams that work with the Agile methodology prefer the scenario-oriented type. This approach helps to overcome the requirements and involves manual and automated acceptance testing. This approach was inherited from behavior-driven development (BDD). A popular approach to writing acceptance criteria is the scenario-oriented Given / When / Then approach. This format is a structured approach for many test environments such as Cucumber. The Given-When-Then pattern allows you to automate a test to determine if a requirement is developed or not. You can describe Acceptance Criteria in paragraphs or immediately in the Given-When-Then format:
For example, if you create a website with two types of users (registered users and guests), the acceptance criteria will be written for the user story that defines requirements for the logged out user: Example of acceptance criteria: User story – Sign Up System user signs in with valid credentials “Given I’m a logged-out system user and I’m on the Sign-In page When I fill in the “Username” and “Pa password” fields with my authentication credentials and I click the Sign-In button Then the system signs me in” Given / When / Then helps reduce the time it takes to write test cases because when writing criteria, we describe the system’s behavior in advance. Rule-based acceptance criteriaUnfortunately, the Given / When / Then structure is not always suitable for writing acceptance criteria. For example:
In cases where Given / When / Then does not suit you, you can use the rule-based AC format. A rule-based form assumes a set of rules that describe the behavior of a system. Based on these rules, you can write specific scripts. Typically, criteria generated using this form look like a simple bullet list. For example: As a logged-out user I want to be able to sign in to a website So that I can find access to my personal profile Key functions of Acceptance CriteriaSo why are acceptance criteria critical? All participants of the development process take advantage of them in some way. So let’s take a look at how acceptance criteria contribute to the project’s success. Help reach consensusAs mentioned, software development usually involves people having different backgrounds. By formalizing the client’s expectations, acceptance criteria allow for sharing a product’s single vision to everyone in the project. They determine the set of requirements that is sufficient to build an envisioned and working solution. Allow for accurate estimationAcceptance criteria show how the product should function in great detail. It helps a development team correctly estimate the work in terms of time and costs. Also, acceptance criteria allow programmers to plan the process in the most efficient way. Define the minimum conditions for successA coding team relies on acceptance criteria to determine a detailed must-have feature scope. In other words, acceptance criteria constitute a list of minimum requirements for a user story to be considered “done.” Without them, there would be too much room for uncertainty, and programmers would have a hard time figuring out what exactly they have to build. Serve as a basis for testingAll acceptance should be testable, i.e., have precise pass and fail results. That’s why the quality assurance team uses them to check if a system works as it’s meant to work. On top of that, acceptance criteria come in handy when testing specialists write autotests. Importance of acceptance criteriaAs we have already figured out, acceptance criteria actually determine the desired outcome of a user story, show when it is completed, and is ready to be tested by QA specialists. If you still are not 100% convinced why acceptance criteria are vital, we would like to count some reasons that highlight the importance of acceptance criteria and prove that they influence the final outcome:
Who creates Acceptance Criteria?As a rule, acceptance criteria are written by a product owner or a business analyst (depending on the chosen project management methodology). However, all participants of the development process, including clients, can contribute. If a client documents acceptance criteria, they should be reviewed by tech specialists. It is required to ensure that there are no constraints from the technical perspective and all the requirements can be implemented. The development team has an opportunity to make some inputs to acceptance criteria during the discussion of a particular user story. Yet, there are two essential things to consider. First of all, acceptance criteria must be expressed in a simple and not technical language. Because, as we already mentioned, people with no technical background will use them. And, secondly, acceptance criteria should describe what to build rather than how to make it. Examples of Acceptance CriteriaHere you can find several more examples of how acceptance criteria actually look like as a component of a user story. How to write acceptance criteria?And of course, to make life easier, we will provide you some tips to create correct and convenient acceptance criteria from our Business Analyst:
Significant challenges and mistakes in writing acceptance criteriaAt first glance, it may seem to you that there is nothing complicated in writing acceptance criteria, but it is not. When, in practice, teams start working on them, they face difficulties. Let’s take a look at methods to help avoid future problems. Before starting development, you need to document the acceptance criteria to understand the customer’s needs clearly. Start by defining a small number of user stories to fill in the backlogs for the first sprints, once agreed by both parties. After all the edits and approvals of the documented acceptance criteria, the developers begin to plan the technical process. Properly written ACs should primarily define a reasonable minimum amount of functionality. But if you spray on the description of all the small details, there is a risk that the development team will get stuck with many small tasks. If ACs are too narrowly focused, developers will not move away from them to achieve the desired result. It is important to remember that acceptance criteria are intentional rather than rigid guidelines The team and stakeholders may have different visions of how to solve the same problem. Therefore, everyone involved in the product development process must confirm that they understand and agree with all ACs. This approach will allow testers to ensure that all requirements are met; otherwise, it will be difficult to understand if the user story is complete.
Overly broad acceptance criteria make the user’s story vague. Correctly written ACs, as we have said, must define the scope of work so that developers accurately allocate time and effort for development. When must Acceptance Criteria be defined?All acceptance criteria must be defined before development starts. No acceptance criteria could be added after a coding team begins to work on a particular user story. And this is a crucial aspect that has a considerable impact on the ultimate success of a project. In case acceptance criteria were not specified in advance, they would likely describe what programmers build currently without any previously defined plan. It is unlikely the developers’ actions will 100% fit the client`s requirements. As a result, a deliverable would not meet the expectations, and it is an entirely negative outcome for both a client and a coding team. Checklist: components of acceptance criteriaAcceptance criteria are tasked to provide developers with a clear understanding of how this part of the solution`s functionality should look, what aims it has, and what value it brings to users. We covered the core tips to help you make your acceptance criteria complete, valuable, and easy to understand for the development team and the stakeholders as well. Hence, acceptance criteria should include the following:
You can also download our checklist with acceptance criteria components and use it for your goals. The bottom lineAcceptance criteria play an important role in software development. In particular, they help all sides of a project (i.e., clients, partners, tech team, marketers, etc.) get a single vision of a product and stay on the same page all the way through. As a result, programmers know exactly what to build, and clients receive a decent solution that meets their expectations. There are no strict rules on how to write acceptance criteria, and all participants of the project are allowed to make their inputs. In practice, the same set and format of acceptance criteria depend on a project’s specifics, features of a product to be developed, project management methodology, and other factors. Have an idea of an app for your business and looking for developers to make it a reality? Anastasiia Kalachova What is included in the project scope statement?A project scope statement provides a detailed description of the work that must be done to deliver the output of a project on time and within the allotted budget.
What is acceptance criteria in scope statement?Acceptance criteria represent a specific and defined list of conditions that need to be met before a project can be considered completed and the project deliverables are accepted by the client.
What is the acceptance criteria for a project?Acceptance Criteria are the conditions of a project, product, or aspects within them (such as sprint user stories or test cases) that must be met before deliverables are accepted. Agreeing on good acceptance criteria upfront with a user reduces the risk that development will not meet expectations.
|