How Should Acceptance Criteria Be Defined In Scrum?
Wed 15 Jul 2015 00:10
In Scrum, the product owner reviews the user stories during the sprint review event, and checks whether their acceptance criteria is met before clearing them for a client demo. He or she will never clear a story if its acceptance criteria are not met. Scrum advocates that bug free and shippable user stories be developed through the product incremental cycles. Each product feature carries a certain business value. At the time of development, the feature should be developed so that its usefulness is sustained in the market i.e. the feature should function as per the product vision seen by the stakeholders. For this to happen, it is important for the development process to satisfy the technical terms and conditions as specified in the backlog items. The acceptance criteria specify conditions which need to be fulfilled by the team, so the feature can retain its business value in the market. Acceptance criteria are important for the scrum process. The product cannot be released unless the acceptance criteria of the backlog items are met during development.
How should acceptance criteria be defined?
The acceptance criteria should be expressed clearly in the product backlog items. It should be stated using a simple language so it becomes easy for the team members to understand and follow it. Moreover, the story should be described in a manner such that it can be understood without facing any ambiguities regarding its possible outcomes – what is acceptable and what is not - the technical team should be able to understand what is to be developed and delivered, in what manner, and what conditions should be satisfied so it can be considered as shippable.
What is the purpose of defining acceptance criteria?
The acceptance criteria helps the team to understand what a user story should ideally deliver in terms of a product increment, and what it should do to maintain the usefulness of the feature. End users have a final say regarding what is exactly required in terms of feature functionality. Based upon their feedback, the product owner ensures that the acceptance criteria reflects end user conditions, and conveys those requirements in the acceptance criteria.
The acceptance criteria:
Defines the limits or boundaries of a user story or feature in the product backlog
Helps the product owner to answer what is needed in the feature so the team can deliver the expected business value.
Helps the team to understand and share ideas regarding how the team should develop the feature.
Aids the team in testing the feature development so it can be accepted as “Done” by the PO and stakeholders.
Helps the team in understanding how much further development is required to finish the story.
What should the acceptance criteria actually include?
The acceptance criteria should be defined while maintaining its “scope”. To be effectual, the criteria should be written following certain guidelines.
It should try to explain the intent behind developing the product feature. It should not try to provide a non-debatable solution. Team members can argue regarding its acceptance while negotiating user stories with the PO during the sprint planning meeting event.
It should be independent of its implementation. The acceptance criteria should not suggest or limit how the story should be developed. The team decides how the story or product feature should be developed since it “owns” the sprint backlog.
It should be explained at a macro level and provide an overall picture about what is actually needed.
When to write the acceptance criteria?
The product owner is responsible for creating the product backlog at the time of project planning. All user stories depicting the product features as envisioned by the client are stated in the product backlog in the form of product backlog items. The product owner should write stories and acceptance criteria. However, as per the role of the product owner as suggested by the Scrum guide update, the PO is to be held accountable for creating and maintaining the product backlog. It does not necessarily mean that the PO should personally create backlog items and state the acceptance criteria in the stories. The development team can aid the PO in writing the stories and stating the acceptance criteria in it. The product owner, however, has the final say what the acceptance criteria should ideally include.