What is Functional Criteria and how does it impact Acceptance Criteria? When using the Agile scrum framework for the delivery of a product, quality can be defined in in one of two ways:

• That a product is fit for purpose and
• That a scrum team produces exactly that which they understand has been requested.

Quality is met by developing user stories including acceptance criteria. User stories are the guidelines and roadmap that a scrum team (Agile Scrum Master, Scrum Product Owner and Scrum Development Team) uses to produce features. User stories are definitions of requirements that are used to produce a set of estimates that are organized as story points. A user story is short and told from the viewpoint of the end user. They generally start off with “As a user of X” and end up with “I want to be able to draw a line” for example. User stories can be written using a varying level of detail depending on the complexity of the related feature. 

Measurements of quality can be defined through user stories by adding acceptance criteria. Effective user stories must include acceptance criteria to demonstrate that the scrum team has delivered to the user specifications.

Acceptance Criteria

Acceptance criteria represent a set of conditions of satisfaction or constraints that must be adhered to. The Acceptance criteria are used as the basis for defining test cases that both the scrum developers and testers utilize in test driven development. Three components of acceptance criteria that should be included are:

1. Functional Criteria
2. Non-functional Criteria and
3. Performance Criteria.

Using a consistent structure when writing acceptance criteria is beneficial. Acceptance criteria should not focus on how to define the solution for delivering the feature but, on what is required. The intent is to describe what the user story will accomplish once delivered. A good format to use is given/when/then.

              Given a certain condition,

                When I perform an action,

                     Then the result should be.

Acceptance criteria that are well written provide a strong foundation for definition of estimations that the scrum team provides for execution. These criteria partnered with user story requirements can also aid a scrum team in an evaluation of complexity to determine if a user story should be further segmented to fit within the time boxed scrum execution window.

Functional Criteria

Functional criteria in Agile are best defined as acceptance characteristics that tell the story of what a feature should do, perform, or externally look like. The Functional criteria are specific in nature describing the action that the end user expects. 

It is important to structure user stories and supporting acceptance criteria so that they are simple enough that the functional criteria can be met. Scrum teams should review the functional criteria with the product owner at the Sprint Planning Meeting, and demonstrate them during the Sprint Review Meeting. This is to determine that all parties understand the deliverable and to ensure the deliverables have been met. This is a good time for clarification and to test basic assumptions about feasibility of delivering the requested feature.

Functional criteria can also include any negative scenarios that if found will make the user story invalid in meeting the objectives of the product feature. These acceptance criteria are just as important to note to avoid misunderstandings in delivery.

A functional criteria statement can be written as follows:

• Given that a user logs into the XYZ application, when the preview page appears, then the blank case title, date, automatic ticket number and blank area to fill in the description of the case should be displayed.

We found these books great for finding out more information on Agile Scrum:

Non-Functional Criteria

Heavy emphasis is always placed on functional acceptance criteria. Equal emphasis should be placed on the nonfunctional acceptance criteria that can determine acceptance and adoption of a new feature. Ignoring nonfunctional acceptance criteria can lead to a system that displays all external features desired by the end user but, one that is unusable or scalable into the future.

Nonfunctional criteria can be related to reliability, organization coding standards and an ability to maintain the feature. Nonfunctional criteria can best be described as an attribute or characteristic. They should also be thought of as constraints that provide prescribed measurements of success.

Dependencies with other features and user stories should also be taken into consideration when developing nonfunctional acceptance criteria. The goal with identifying these constraints is to minimize technical debt and maximize the return on investment of the product.

A nonfunctional criteria statement can be written as follows:

• Given that the Customer Service departments from around the United States will be using the XYZ application from 7am – 8pm in their respective time zones, when Customer Service representatives login to the XYZ application then the application must support at least 500 concurrent users during all United States time zones starting at 7am and ending at 8pm.

Performance Criteria

If there is an assumption of a certain level of performance than this should also be included in the acceptance criteria. All too often organizations leave performance testing as an afterthought or ignore it waiting to see what will happen once the product is in production. Examples of performance criteria are response time for data searches, system availability, and are the users geographically dispersed making network bandwidth a constraint.

A performance criteria statement can be written as follows:

• Given that up to 500 concurrent users can be logged into the XYZ application, when a user completes the blank case title, completes the blank case description and hits submit, then the automatic ticket number should be sent to the end customer within 2 minutes.

Acceptance criteria are the specific instructions or constraints communicated from the view of the end user to the scrum team. They should be defined before any work begins in developing features. Some organizations develop acceptance criteria at the time that user stories are initially developed. Others do so during the planning of each sprint as part of the backlog refinement. Well written acceptance criteria are part of the effort to determine when a feature is successfully delivered or “done”.