Getting to done: Acceptance criteria and the Agile workflow

During the development process, how do you know when a product feature or service component is officially “done?” By adopting a user-focused mindset and providing open lines of communication between Product Owners and development teams, the path to Acceptance Criteria can be smooth.
Acceptance criteria (AC) helps us define how end users utilize the features of a product or solution. By placing parameters around project scope, AC plays an integral role in achieving successful outcomes, both in development and for users.

As with most things, clear and direct communication is essential. Ben Holland at KREE puts it in perspective by describing the development process without AC as a classic game of “telephone,” in which information changes and becomes less accurate as it passes from person to person. By the time it reaches a downstream stakeholder, it no longer resembles the original information at all, and can negatively impact the process, from missed deadlines, to QA confusion, to finalization of a feature or service!

By outlining the inclusions and exclusions to a user story, AC helps provide insight into both the “best-case” and “worst-case” scenarios of a given user path. At its most basic, AC establishes a Pass/Fail gateway that can be automated to verify or deny acceptance.

The function of acceptance criteria
Acceptance criteria is an important component of an Agile environment, and it serves several key purposes within a project:

  • Managing expectations for developers and stakeholders
  • Defining scope to keep projects on track and prevent scope creep
  • Reducing ambiguity by delivering a clear Pass/Fail for each user scenario
  • Informing QA testing with criteria
  • Outlining negative outcomes so they can be addressed proactively during development

Being proactive while avoiding surprises
Using well-written acceptance criteria helps development teams define concretely when a feature is “done,” based upon known user scenarios. By outlining criteria and outcomes clearly, teams can better understand the objectives of the project and work in alignment toward the common goal. It also helps avoid unexpected surprises!

Principles for building acceptance criteria
Developing effective AC for the Agile framework is an art, but is easy to do if you pay attention to four basic principles:

  • Make it testable so that engineers can easily determine when something is “done”
  • Make results apparent so there can be no misunderstanding the outcome
  • Make criteria crisp and simple, avoiding lengthy detail and explanations
  • Make it user-centric, always putting challenges in the context of the end user

Guidelines for writing acceptance criteria
Make sure that each item or story you’re writing for incorporates at least one acceptance criterion, and always develop AC before an implementation is rolled out to take advantage of the benefits associated with the process. Also make sure your AC is targeted on the end outcome (the “what”), not the approach (the “how), and includes functional as well as non-functional criteria.
Once the AC is written, it should be reviewed and verified by the Product Owner (PO). This reinforces that everyone shares the same vision.

Cause and effect: Examples of the scenario-oriented format
The scenario-oriented AC format is developed using the Given/When/Then (GWT) sequence, and will include statements such as:

Conclusion
Acceptance criteria is a key part of each user story that an Agile-focused team works on. By concretely defining scope, outcomes, and testing criteria for functionality that developers are delivering, AC represents one of the most efficient ways to ensure that both Product Owners and software engineering teams are on the same page.