What is Acceptance Criteria?
Acceptance Criteria is a term used in software projects for a deliverable that will list a set of pre-defined requirements in relation to a product, service, or feature. Such criteria must be met or approved so that it can be ultimately “accepted” by the end-user and therefore become a functional part of the organization’s solution or software. The criteria is specific to each User Story in Agile project management and are elaborated during planning phases so that once defined, the development team can use it as a guide for implementation and testing. It is highly recommended to have detailed and measurable criteria that is clear to all involved so that measurable outcome is obtainable.
Why is Acceptance Criteria necessary?
Writing requirements in the form of “Acceptance Criteria” has become the current day norm in Agile projects. Crafting these requirements as digestible deliverables is an integral way to help with a successful implementation. In doing so, using acceptance criteria is standard practice for requirement documentation and can easily align different teams to hold a common understanding of the ask.
It is extremely important that cross-functional teams hold a shared understanding since collaborating together highlights that they all have their own unique backgrounds, ideas, and interpretations which can lead to misalignment. Moreover, writing acceptance criteria can vary greatly per the author’s unique writing style. This is particularly evident on large projects when multiple individuals work on producing acceptance criteria.
Needless to say, we all have our own preference on how to write, but it’s important to remember that writing acceptance criteria is a skill that can always be refined and improved upon with the ultimate goal of producing a document that reduces implementation ambiguity, that is clear to understand by all parties involved and provides value to the project.
Acceptance Criteria & User Stories
The skill of writing user stories is well defined: understand the project scope, work on your personas, follow the INVEST mnemonic and you’re pretty much set. On the other hand, acceptance criteria is much broader and “open” in terms of definition. There is often a gap between theory and practice. Whilst working on requirement analysis, the real world often presents time constraints, no well-defined scope, and a lack of stakeholder engagement. User stories can reflect a specific goal but the acceptance criteria needs to showcase the behavior in detail so that the user story can be achieved.
As a Business Analyst in software projects, I am involved during all phases of design and implementation. However, countless times I have seen the expectation of having reached a shared understanding become dismantled at all stages of the project.
There are many resources out there that cover best practices, but I want to emphasize the importance of actively listening to questions or feedback when reviewing acceptance criteria with the scrum team. This is a critical aspect to know whether it is well written and achieves the goal of the user story. Nailing down a good set of acceptance criteria is a challenge and finding that sweet spot can make your requirements a masterpiece for the team.
The Goldilocks Principle
What is the Goldilocks principle?
The Goldilocks story can help us think about finding that middle ground on how to write effective acceptance criteria that is dependent on each project’s particular goals and needs. Aside from the blatant issue of home invasion, Goldilocks does teach an important lesson. Namely, when doing something, nothing at the extremes was “right,” not eating the porridge, sitting in the chairs, or sleeping in the beds. Yes, this might have been intended for you always to seek out that ideal balance in life, but also let’s think about it when writing acceptance. Too vague and it becomes a solution nightmare. Too detailed and it complicates the wiggle room needed for “issues” or design/tech constraints that occasionally pop up. Too lengthy can make it hard for QA to test effectively but too short might not reflect any implementation needs.
However, let’s go a step further. We don’t always have time to write well, and sometimes we don’t know the clear scope or vision of the stakeholders but have to start anyway, we might not have a strong technical lead, or we might not have access to the right stakeholders to get the information we need. These constraints can lead to unclear and difficult-to-read acceptance criteria.
In the past, I have assessed the project risks applicable to writing acceptance criteria, similar to the ones mentioned above, and devised a strategy on how I can best write them so that they become a valuable key piece of work used by the team.
Tips and recommendations to write good acceptance criteria
- Assess your timeline to deliver the acceptance criteria.
An aggressive timeline requires a fast output and more generic criteria. Details will need to be fleshed out further when reviewing the user stories (during scrum team refinement) and possibly during implementation. Not ideal, but is a real-world scenario.
A lengthy timeline gives more time to work alongside stakeholders and fully understand the requirement and its context. We should work on supporting documentation like process flows or designs to assist teams to understand the written criteria.
- Understand the project’s complexity.
A straightforward project involving simple development work and design gives us the opportunity to write in detail (always respect best practices – like 8-10 max criteria per user story) and call out the specifics. Such as errors, exceptions, or alternate behavior.
A highly complex implementation often involves integration/s, whereby it can actually be more beneficial to write more generically with the key details only since during development unforeseen limitations always arise. Work with what you know as a basis and any underlying constraints will naturally come to the surface.
- The audience: get to know your stakeholders, their engagement, and how invested they are.
If stakeholders do not display much product knowledge or are not very helpful in defining the requirement, they might need you to aid their decision-making. This is an extremely common issue in projects. If this is the case, writing acceptance criteria needs to be clear to them so as not to include too much technical jargon. This can be elaborated with the development team during refinement.
However, if stakeholders are overly involved and have a technical background, this might help you get what you need but they should not solve the “how” a criteria needs to be met. Here, we need to stick to writing acceptance criteria as statements and not describing how something needs to be achieved – even how obvious this can be.
Conclusion
All in all, we can add a lot of value to a project when writing acceptance criteria while also taking into consideration all the particulars and risks of a project. This analysis can be used before investing time, effort, and potentially rework to examine how you’re going to tackle writing the acceptance criteria. Always remember, although this is a generalization, it can help to get those acceptance criteria just right.
Check out our staff augmentation services.
