PremierAgile

Scrum organizations have expanded in recent years as companies have transformed into Agile industries. Many organizations have chosen the Scrum Framework to integrate Agile Methodology as Scrum is lightweight and simple to understand. However, Scrum is also difficult to master and needs professionals who are well-versed in the principles, values, and practices of Scrum. Scrum professionals are trained to work in Agile environments and are encouraged to develop an Agile mindset. With all the benefits such as faster time to market, early return on investment, reduced risks, customer feedback along with customer satisfaction, and employee satisfaction, Scrum is one the most implemented framework in many industries, and also the first choice of companies who are planning to implement Agile in their organization. 

What is Scrum?

The Scrum guide defines Scrum as a framework with which people can address complex adaptive problems productively and creatively, such that they deliver the highest possible products and excellent value. Since the early 1990s, the Scrum Framework has been used to manage work on complex products. Scrum does not relate to a process, technique, or a definitive method, it is a framework within which various processes and work techniques are employed. The relative efficacy of the Product Management and work techniques are made clear by Scrum such that improvement of the team, product, and working environment takes place. The Scrum Framework consists of a Scrum Team with their associated Events, Roles, Artifacts, and Rules. Every component within the framework serves a particular purpose which is essential for the success of the project performed using the Scrum Framework. 

The Scrum Team consists of the Product Owner, the Developer, and the Scrum Master. Each of the Scrum Team members has their own roles and responsibilities. They collaborate effectively with each other such that a product can be developed as expected and can reap all the benefits as expected. The Product Owner is a professional who forms the vision of the product, manages the Product Backlog, and understands the needs of the customer. They communicate the requirements from the customer to the Developer and answer any queries related to the product requirements. The Scrum Master is a servant leader that guides the team during the development process. They solve any impediments faced by the team and facilitate Scrum Events such as Sprint Planning, Sprint Review, Daily Stand-ups, and Sprint Retrospectives, and help the Developer achieve their goals that lead to the success of the project eventually. The Developer is the backbone of the Scrum Framework as they deal with the technical process of product development. With the help of the Product Owner, Scrum Master, and other Stakeholders, the Developer designs the products as required for the customers.

What is Acceptance Criteria?

Acceptance criteria refer to the set of predefined requirements for a particular User Story that has to be completed so that the User Story can be termed as complete. They determine the scope and requirements that have to be executed by the Developers to label the User Story as finished. A Product Owner or a Product Manager may be responsible for writing the Acceptance Criteria for the stories present in the Product Backlog. Acceptance Criteria are a form of Agile requirements documentation. There are several ways of defining Acceptance Criteria, of which two of them are:

• Definition 1: conditions a software product must satisfy to be accepted by a user, customer, and other Stakeholders. ( Microsoft press definition.)
• Definition 2: Acceptance Criteria are pre-established standards or requirements a product or project must meet. ( Google definition)

Characteristics of effective acceptance criteria:

• Acceptance Criteria must be testable as these requirements help to give clarity for the Developers. The test results of these tests should not leave any place for interpretation and should reveal straightforward yes/no or pass/fail results.
• The Acceptance Criteria should be as simple and straightforward as possible. As the criteria are not comprehensive documentation it should be clear and concise.
• The Acceptance Criteria are written and should be understood by everyone. The Acceptance Criteria become useless if none of the Developers understand it. While formulating the Acceptance Criteria, if any point is not clear, proper time should be taken to task to make adjustments until things are clear. 
• The perspective of the user should be reflected in the Acceptance Criteria. As the criteria is a means of understanding the problems from the hand of the customer's standpoint, it should be written in the context of a real user's experience.

Purpose of Acceptance Criteria in a User Story

Acceptance Criteria have several purposes in cross-functional teams, such as:

• User Story leaves room for interpretation which can be eliminated by forming Acceptance Criteria. The criteria clarify the expected outcome of a User Story concretely and give Developers and Quality Analysts a clear-cut way to determine whether a story is completed and accepted.
• Acceptance Criteria can define the desired outcome before any kind of assumption is created by any members of the team. Promotion of alignment and shared understanding is created by formulating Acceptance Criteria and hence, reduces the likelihood of surprises in the future.
• Acceptance Criteria reduce ambiguity for the Developers and create a great defense against Scope Creep.

Who is responsible for writing acceptance criteria?

The Product Owner or Manager is responsible for writing the Acceptance Criteria. However, anyone on the cross-functional team could also write the Acceptance Criteria for User Stories or facilitate a discussion about it. The main idea while writing the Acceptance Criteria is to keep in mind the requirements of the customers. A product person such as the PO looks at the customer's needs from the perspective of the user and better understands what has to be written. However, it is better to keep the writing as a group activity which includes both Developers and QA representatives as it involves many benefits. A few of the benefits are communicating with the Developers and QA representatives and adding missing pieces or identifying dependencies that may have not been clear.

How to write effective Acceptance Criteria?

Writing Acceptance Criteria is an important responsibility and has to be done in a very clear and concise way. There are several types of Acceptance Criteria, which two of them are rule-oriented and scenario-oriented. The rule-oriented criteria offer the person a list of the factors that have to be completed such that the User Story can be termed as completed. The scenario-oriented Acceptance Criteria are one of the popular forms among the Agile teams. The Acceptance Criteria in this type are in the form of scenarios that illustrate each criterion. This helps the team to get across requirements, envisaging various use cases, and using scenarios for automated and manual acceptance tests. 

One of the most common templates that are used to describe the Acceptance Criteria using a scenario-oriented approach is the given/when/then format which is derived from the Behavior-Driven Development. This format helps to ensure that all the specifications are met and convenient for people (since it is written in a cause-and-effect manner which people are familiar with.) 

Example

Suppose we have a website that has logged-in users and guests, the Acceptance Criteria for a User Story that defines the sign-in feature for a logged-out user is:

As a logged-out user

I want to sign-in to a website

So that I can access my profile.

The Acceptance Criteria for the above User Story can be formed using the scenario-oriented approach such as:

Scenario: System user signs-in with valid credentials

'Given I'm a logged-out system user

And I'm present on the sign-in page

When I fill the username and password fields with my authentication credentials

And I click the sign-in button

Then the system signs me in.

The given/when/then template reduces the time in writing test cases as the system's behavior is described upfront. Writing the Acceptance Criteria with the first-person "I" helps the Agile team to talk from the perspective of the user's mind. 

Few important tips that will help a person write effective Acceptance Criteria are:

• The Acceptance Criteria should be well-defined so that all the members of the project understand it clearly and get the idea that is being conveyed.
• The criteria should be achievable and realistic. The minimum piece of functionality should be defined and should be delivered. However, every detail of functionality needs not to be defined since the risk of cluttering up the backlog and burying under the small tasks can be a problem.
• The criteria should be coordinated with all the Stakeholders and should be based on consensus.
• Measurable criteria should be created such that development can be adequately estimated and the company stays within the budget and time constraints.
• Providing checklists that enable the members to look at the User Stories that have met the Acceptance Criteria can also be a way to write the Acceptance Criteria effectively.
• Acceptance criteria should always be written before the implementation which is obvious yet is missed by many Agile teams.
• Make sure that each of the Acceptance Criteria should be testable and should have results that are pass/fail.
• Wherever relevant include both the functional and non-functional criteria.
• If the team members write the Acceptance Criteria, the PO has to approve it which shows that the Product Owner and the team members have a shared understanding of it.

Conclusion

Acceptance Criteria are one of the main factors for any Product Increments such as User Stories to be labeled as successful. Without having Acceptance Criteria, the Developers do not have a sense of direction while developing the product, which may lead them to produce the wrong products or products that are not relevant. Acceptance criteria keep the entire Agile team on the same page and make sure that they are aligned with the goal of the project. Writing good Acceptance Criteria is a matter of art and skill that every member has to master and is not only confined to the Product Owner or Manager. Practicing writing various Acceptance Criteria with different scenarios, following the tips mentioned for writing good Acceptance Criteria, and getting help from experts while writing may be a few of the great factors to follow to write effective Acceptance Criteria. When members of the Agile team write excellent criteria, the development and delivery of the product become hassle-free and products with great value are delivered to the users which give immense benefits to both the customers and the organization.

References

1. https://rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important
2. https://www.productplan.com/glossary/acceptance-criteria/
3. https://www.softwaretestinghelp.com/user-story-acceptance-criteria/