One of the biggest challenges in satisfying the customer’s acceptance of a delivered product is eliminating ambiguity in defining what is to be developed. 

I was recently sitting in on a Sprint Review session, when the discussion occurred regarding what makes for successful acceptance criteria. This came up because the criteria listed in the Scrum user story did not address the specific product requirement that the Customer was expecting.  

So, I thought I would just point out here some of the essential factors for successful acceptance criteria. For purposes of understanding the comments in this blog, I assume each will have a basic knowledge of Scrum.  

Acceptance Criteria Defined

Acceptance criteria are a set of statements that describes the conditions a software product or a project deliverable must satisfy in order for the User Story to be accepted by a Product Owner, user, customer, or other stakeholder. Acceptance criteria are incredibly important in Scrum because they spell out what a development team needs to accomplish for a given Sprint. 

These criteria define the boundaries and parameters of the features that have to be met for a story to be assessed as complete or “done”. There is no partial acceptance…either the User Story is met or it is not. Therefore, acceptance criteria represent specific conditions of acceptance or satisfaction that will result in delivering business value. The product cannot be released unless the acceptance criteria are met during development. 

Key goals of acceptance criteria should be: 

• to clarify what the development team should build before they start work 
• to ensure everyone has a common understanding of what is to be built 
• to help the team members know when the User Story is complete and “done” 

Several benefits of acceptance criteria are: 

• getting the development team to think through how a feature or piece of functionality will work from the user’s perspective 
• removing ambiguity or vagueness from requirements 
• providing input into the tests that will confirm that a feature or piece of functionality is working and complete 

Proper acceptance criteria should answer the following questions: 

• What will be tested to confirm that the User Story is done? 

• What software or deliverable feedback will be received during product review? 
• Did we build the right product? Did we build the product right? 

What Characteristics Should Be Included and Not Included 

Acceptance criteria should state intent but not list the steps to produce the solution.  The criteria should be independent of the implementation and discuss WHAT to expect, and not HOW to implement the functionality. In other words, the acceptance criteria should not suggest or limit how the story should be developed. The development team decides how the story or product feature should be developed. 

One question that might be asked is “How many criteria is too many?” There is no standard answer…but as a rule of thumb, 3 to 5 acceptance criteria per story seems to be a reasonable range. Any more than that, then you should check manageability. Maybe the story could be broken up into smaller, more manageable stories. The goal should be providing as much “what” detail without sacrificing conciseness, clarity, and comprehension. 

Also, remember that Scrum always encourages working product over extensive documentation. While it is important to avoid spending too much time and efforts over comprehensive documentation, creating small, concise, and focused documentation (as in acceptance criteria) will aid the team in understanding a user story. The reality is that documentation should not be avoided, but at the same time it should not be lengthy and require too much effort in terms of resources required to complete it. 

Who Writes the Criteria and When 

Generally, Scrum acceptance criteria are initiated by the Product Owner with input from the user, customer, or stakeholder. But writing the criteria is not solely the responsibility of the Product Owner. Acceptance criteria should be developed as a joint effort between the development team and the Product Owner. 

The effort to build the initial set of user stories / acceptance criteria is led by the Product Owner with input from the customer during product planning. However, it is good for the development team to be involved as early as possible to assist in refining the initial set of acceptance criteria prior to starting development activities. 

Once the Sprint events have started, the team should continue to collaborate with the Product Owner, user, and stakeholders in maintaining the product backlog as part of the backlog refinement process. This approach allows the team to review (modify, if necessary) criteria a few days prior to each Sprint Planning event and as a result, become more prepared for development activities during the upcoming Sprint.  

Definition of “Done” 

One of the most important qualities of a high-performing team is a shared understanding of what it means for a feature or User Story to be “done.”  So, what does it mean to be “done?” 

The definition of “done” is a set of practices the Scrum team has agreed upon for all stories. The team defines what “done” means to them, working transparently towards completeness to create a product feature. It’s helpful to have the definition of “done” posted on a wall or easily visible in a team’s workspace. 

Unlike acceptance criteria, which change for each user story, the definition of “done” stays more or less unchanged over time. However, the team should periodically revisit their definition of “done” and check to see that it still suits their needs. A good time for this is during the Sprint Retrospective event. If a particular development consideration seems like it is often overlooked or not even addressed, it might be worth adding it to the definition of “done.” 

Wrap Up

As with many things in Scrum, writing effective acceptance criteria and understanding when something is “done” takes practice. 

If you are a Product Owner having responsibility for writing acceptance criteria, I strongly suggest you work with your development team to get their feedback and input on the acceptance criteria. With this type of collaboration, crafting successful acceptance criteria becomes achievable. 

By providing your development team detailed and concise acceptance criteria that both of you agree upon, along with their continual application of “done”, this will make the process of your product development more efficient.