With an objective to enable continuous learning and progression for our learners, PremierAgile curated several learning articles in the areas of Agile, Scrum, Product Ownership, Scaling, Agile Leadership, Tools & Frameworks, latest market trends, new innovations etc...
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.
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.
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:
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.
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.)
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.
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.