Acceptance criteria 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. 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.
User Stories corresponding to rejected
deliverables are added back to the Updated Prioritized Product Backlog during
the Groom Prioritized Product Backlog process, to be completed in future Sprints. The
rejection of a 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.
The following diagram illustrates the how
Acceptance Criteria for the User Stories are used in the product increment flow
of a Sprint.
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
stakeholders and/or business representatives
The key difference between Done Criteria and Acceptance Criteria is that
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.
But as with the Acceptance Criteria, all conditions of the Done Criteria must
be satisfied for the User Story to be considered Done.
Here is a video on Acceptance Criteria and Done
Criteria: http://www.scrumstudy.com/watch.asp?vid=594
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.
Toward the end of any iteration, the respective business unit and
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 stakeholders is gathered, only the Product Owner
has the power to accept or reject a particular User Story as Done, according to
the agreed upon Acceptance Criteria and Done Critieria. Thus, Acceptance Criteria
and Done Criteria play a vital role in maintaining quality and need to be
clearly understood by the team.
