Acceptance Criteria In Scrum

Acceptance Criteria In Scrum
In Scrum, the product features are represented in the form of user stories or product backlog items, in the product backlog. The framework focuses upon delivering consistent product increments, and since user stories form the base of all developmental activities in Scrum, they should be properly stated and defined so the team can develop them as per the product vision was seen by the client. The DoD and acceptance criteria define what conditions must be fulfilled so the story can be considered as “complete” and deployable.

The Definition of Done “DoD” and the acceptance criteria play an important part in making a user story more effective. When these two criterions are carefully worked out, defined, and explained to the development team, successful product increments can be availed and shippable product features can be developed. The DoD binds the team to what the product owner actually desires in terms of a successful product increment. In many ways, it can be considered as a contract between the Scrum team and the client. The acceptance criterion helps to reinforce the DoD and ascertains that the team delivers product increments which meet predefined quality standards.

What are the acceptance criteria?

Acceptance criteria are quality standards required to satisfy the client’s expectations in terms of what kind of quality the client desires in the product, and what conditions should be satisfied so the client can accept the final product developed by the team. Basically, the acceptance criteria are statements that can be written down and evaluated as being either true or false as regards their outcomes. They generally have a clear “pass” or “fail” results and can be used to describe functional as well as non-functional requirements.

Acceptance criteria and goals

Acceptance criteria should have clearly defined goals:

  • To define what should be developed or built by the team. The definition activity should be done before the actual development process starts.
  • To make sure every team member understands and shares a common vision regarding the development requirement.
  • To help the team to decide that a story is complete and “Done”.
  • To verify the feature development using automated processes and methods.

When should acceptance criteria be created?

The criteria specify the prerequisites to be followed by the team to the development carried out can be considered as shippable. The team should know what conditions have to be met so it can start planning the technical process. Therefore, acceptance criteria should be mentioned in the user story before it is accepted for development by the team during the sprint planning event. Ideally, the criteria should be worked out well in advance at the time when the product owner creates the product backlog during the project planning phase. However, live working conditions indicate if the criteria are defined a few days prior to the sprint planning event, the team remains familiar with it and remembers it clearly. Some teams prefer to define the criteria when user stories are discussed, and at the time of product backlog refinement.

Should acceptance criteria be documented?

Scrum always encourages working process and principles over extensive documentation. While it is important to avoid the pitfall of spending too much time and efforts over comprehensive documentation, creating small, concise, and focused documentation can actually aid the team in understanding a user story. The point is documentation should not be avoided, but at the same time it should not be lengthy and require too much of efforts in terms of resources required to complete it.

Do you want to implement scrum?