Focus on Acceptance Criteria for better Software Outcomes

Acceptance criteria have evolved significantly in software development. They started as functional, technical, and business requirements, then transformed into the Conditions of Acceptance or Acceptance Criteria we know today. These criteria, often vague or overly prescriptive, define the requirements or standards of a software project. Despite their crucial role as the DNA of a software project, they are only sometimes given the scrutiny and attention they deserve.

Unclear acceptance criteria can lead to many issues, including confusion, rework, and extended estimates. This vagueness often results in a back-and-forth with the product owner, which can be time-consuming and inefficient. Developers usually think they are done with a piece of work only to demo it and discover that their interpretation of the requirements differs from the product owners' or customers'. These missed expectations will require the developer to meet with the product owner again, get the actual requirements, and then work on developing the piece of code to the new expectations. Teams are lucky if this happens once, but often, there are several rounds of iterations before the software can be considered done. You might think, "This is Agile software development; iterations are expected," and you would be correct, but efficient teams keep the iterations low. Teams that use a repeatable process to limit the number of iterations will save time on rework and additional requirements meetings.

How do you prevent vague acceptance criteria? Define a process incorporating a consistent strategy to define requirements in low-level detail, such as field-level for web or mobile applications or functional-level for other software development use cases. Implement proven requirements and testing strategies like Behavior-Driven Development using the given, when, then pattern. If a user interface is involved, mock the UI design before writing code; having a visual representation of a screen will prompt many discussions about the layout and screen elements and is cheaper and faster than prototyping code. Remember, the level of detail in acceptance criteria should be transferable, meaning when passing the user stories between team members, there should be enough detail that doesn't require additional meetings about the user story to provide further clarification. Be aware that you can become over-detailed on acceptance criteria, and that's another mistake to watch out for.

Overly detailed acceptance criteria can also cause a massive drag on software projects. Agile's beginnings were about preventing an extensive define and analyze cycle up front in software projects, only to have it undone during implementation. Change is a necessity and a natural part of software development. Defining the perfect acceptance criteria for a user story is a losing game and should be avoided. Teams with this challenge generally have extended acceptance criteria with every detail considered, including those found in the project software conventions or definitions of done. Every detail must be accounted for, and changes to the acceptance criteria are fine during the analysis but are not acceptable once the work begins.

How could unforeseen changes occur with all the time spent defining the acceptance criteria? Software development is a very abstract process and exists primarily conceptually during design. Trying to account for every possibility in this phase isn't likely. The complexity in software development includes not only the code under development but all the code that runs the hardware, networking, OS, development platform, and all the 3rd-party libraries; it's amazingly, it all works!

How do you prevent overly detailed acceptance criteria? The best suggestion is to keep your user stories small, lasting one to three days for development. This strategy immediately keeps the complexity low by time-boxing the development effort. Then, take the suggestion from this post's vague user acceptance criteria portion and keep the acceptance criteria at a low level, like field or function level. Refrain from including information about a project's software conventions or definition of done items covered in the story. Allow modifications to the acceptance criteria while a user story is being worked on as long as it doesn't change the estimate. If it does change the estimate, add a new user story with the updated acceptance criteria. Acceptance criteria are the building blocks of a software project, and they should have just enough detail to define the requirement clearly.

At Karsarsoft, we took a new approach to acceptance criteria. We implemented a solution allowing easy input and a simple, straightforward method for completing, testing, disputing, and managing defects related to acceptance criteria while easily providing a story's status. We take each acceptance criterion seriously and ensure a thoughtful process occurs each time a builder and validator implement a requirement. This process yields the most transparent way to understand a user story's status without impeding the team with laborious manual status updates.

Other software management tools provide a big box that contains all the requirements in a block of text, making it hard to understand a story's status, what has been completed, and what still needs to be completed. It also requires time to figure out where someone left off when implementing a story. We wanted to fix these issues with a more thought-out user story completion process. We based this design on a checklist method used by surgeons, architects, and other professionals to ensure that every detail is observed and every requirement is accounted for. We also made the acceptance criteria initially read-only while being worked on to ensure changes are purposeful and deliberate. These strategies ensure teams using KS Status get the most efficiency and user experience, creating software using acceptance criteria while providing the best user story status in the market.