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 relevant business stakeholders as they pertain to the proposed product or service. Each User Story will have associated User Story Acceptance Criteria, which are the objective components by which a User Story’s functionality is judged.

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 on User Stories. Acceptance Criteria are developed by the Product Owner according to his or her 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 objective conditions that User Stories must satisfy for them to be accepted by the Product Owner.

At the end of each Sprint, the Product Owner uses these criteria to verify the completed deliverables; and can either accept or reject deliverables. If deliverables are accepted by the Product Owner, then the User Story is considered ‘Done’.

Although Acceptance Criteria are unique to each User Story, they 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.

Let us now look at the key differences 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 and/or 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 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.