Articles

The Prioritized Product Backlog is a single requirements document that defines the project scope by providing a prioritized list of features of the product or service to be delivered by the project. The required features are described in the form of User Stories. User Stories are specific requirements outlined by various business stakeholders as they pertain to the proposed product or service. Each User Story will have associated User Story Acceptance Criteria (also referred to as “Acceptance Criteria”), which are the objective components by which a User Story’s functionality is judged. Acceptance Criteria are developed by the Product Owner according to his or her expert understanding of the customer’s requirements. The Product Owner then communicates the User Stories in the Prioritized Product Backlog to the Scrum Team members, and their agreement is sought. Acceptance Criteria should explicitly outline the conditions that User Stories must satisfy. Clearly defined Acceptance Criteria are crucial for timely and effective delivery of the functionality defined in the User Stories, which ultimately determines the success of the project.

At the end of each Sprint, the Product Owner uses these criteria to verify the completed deliverables; and can either accept or reject individual deliverables and their associated User Stories. If deliverables are accepted by the Product Owner, then the User Story is considered Done. A clear definition of Done is critical because it helps clarify requirements and allows the team to adhere to quality norms. It also helps the team think from the user’s perspective when working with User Stories.

User Stories corresponding to rejected deliverables are added back to the Updated Prioritized Product Backlog during Refine Prioritized Product Backlog Process, to be completed in future Sprints. The rejection of few individual deliverables and their corresponding User Stories is not a rejection of the final product or product increment. The product or product increment could be potentially shippable even if a few User Stories are rejected.

Writing Acceptance Criteria

Acceptance Criteria are unique to each User Story and are not a substitute for a requirements list.

It is important for a Product Owner to note that User Stories that fulfill most, but not all, Acceptance Criteria cannot be accepted as Done. Scrum projects operate in Time-boxed Sprints, with a dedicated Sprint Backlog for each Sprint. Often, the last bit of work might be the most complicated part of a User Story and might take longer than expected. If incomplete User Stories were given partial credit for being Done and carried over to the next Sprint, then the progress of the subsequent Sprint could be disrupted. Therefore, the Done status is black and white. A User Story can only be either Done or not Done.

Minimum Acceptance Criteria

A higher level business unit may announce mandatory minimum Acceptance Criteria, which then become part of the Acceptance Criteria for any User Story for that business unit. Any functionality defined by the business unit must satisfy these minimum Acceptance Criteria, if it is to be accepted by the respective Product Owner. The introduction of this Acceptance Criteria may lead to a cascading set of Acceptance Criteria for the portfolio, program, and project (see the figure below). The overall quality standards, guidelines, and templates for an entire portfolio are set by the Portfolio Product Owner while the minimum Acceptance Criteria at the program level are set by the Program Product Owner. Thus the Acceptance Criteria for a User Story in a project will implicitly include all the minimum Acceptance Criteria from the higher levels, as applicable.

Once the minimum Acceptance Criteria are defined, such criteria may then be documented in the Scrum Guidance Body documents and referred to by Scrum Teams as required.

Definition of Done

There is one key difference between “Done Criteria” and “Acceptance Criteria”. While Acceptance Criteria are unique for individual User Stories, Done Criteria are a set of rules that are applicable to all User Stories in a given Sprint. General Done Criteria could include any of the following:

• Reviewed by other team members
• Completed unit testing of the User Story
• Completion of quality assurance tests
• Completion of all documentation related to the User Story
• All issues are fixed
• Successful demonstration to business stakeholders/business representatives

As with the Acceptance Criteria, all conditions of the Done Criteria must be satisfied for the User Story to be considered Done.

The Scrum Team should use a checklist of the general Done Criteria to ensure a task is finished and the result meets the Definition of Done (DoD). A clear Definition of Done is critical because it helps remove ambiguity and allows the team to adhere to required quality norms. The definition of Done is typically determined and documented by the Scrum Guidance Body.

The required records and data to comply with the project’s documentation requirements can be generated as the team proceeds through Sprints and Releases.

The inclusion of activities such as holding review meetings and writing design documents can help ensure compliance with internal and external quality standards. The basic principles of Scrum such as short iterations, incremental building, customer involvement, adaptation to changing requirements, and constantly adjusting scope, time, and cost within the project will still apply.

Acceptance or Rejection of Prioritized Product Backlog Items

Toward the end of any iteration, the respective business unit and business stakeholders participate in a Sprint Review Meeting in which the product increment is demonstrated to the Product Owner, sponsor, customer, and users. While feedback from all the business stakeholders is gathered, only the Product Owner has the power to accept or reject that a particular User Story is Done according to the agreed upon Acceptance Criteria. Thus, the role of Acceptance Criteria in maintaining quality is critical and needs to be clearly understood by the team. It is the responsibility of the Scrum Master to ensure that the Acceptance Criteria for a User Story are not changed by the Product Owner in the middle of a Sprint. Partially completed User Stories are rejected as not Done and moved back into the Prioritized Product Backlog.