What are Acceptance Criteria, and do you need them?

Do you think a User Story in insolation is sufficient to be developed, or does something else need to accompany your story? I would argue that no User Story is complete with having defined Acceptance Criteria (also known as A/C – no, not air conditioning). Read on to learn what they are and why they’re critical.

What are Acceptance Criteria?

Having spent a good chunk of my early career creating more traditional software specification documents, I think of Acceptance Criteria as mini functional requirements, along with any non-functional attributes that also need to be satisfied. Acceptance Criteria also define the boundaries of a User Story. A/C generally contain all the details necessary for a Developer to pick up a story and run with it; it provides the Developer with a holistic picture of what they’re building and gives them guardrails so they don’t develop extra or unnecessary functionality.

How detailed should Acceptance Criteria be?

The question of how detailed your Acceptance Criteria should be is a tricky one, so I’ll give you my standard consulting response: “it depends.” As a writer, I know it’s always necessary to consider my audience, which is true in this situation.

I learned (the hard way) that not every Developer needs the same level of detail to deliver a User Story successfully. Finding the right balance is especially challenging when you have Developers of varying levels of experience on a team, so generally, you need to write for the lowest common denominator.

That said, if I know that specific stories will likely end up in the hands of a senior person versus a junior one, I’ll include only the bare-bones requirements because I trust the Developer to make sound decisions. If it’s a less-experienced person, I typically provide more detail to give context and ensure all the bases are covered.

But at whatever level you document your Acceptance Criteria, make sure you review them with your Developers to gain a shared understanding of what you’re trying to accomplish. You should get their blessing before marking any User Stories as “ready” for development.

When are Acceptance Criteria written?

Ideally, you write Acceptance Criteria well before any development has happened. If a User Story doesn’t contain fully fleshed-out A/C and a Developer starts working on it anyway, you will run into problems – guaranteed. The key is to write the Acceptance Criteria just in time – not too early (risking that they’ll become outdated or irrelevant), and not too late (so the Developer has a ton of questions and there’s not a shared understanding). You want to finalize your Acceptance Criteria at the “last responsible moment” so the information is fresh.

Who documents the Acceptance Criteria?

The Product Owner is typically the person who documents the Acceptance Criteria, but this is a general practice, not a rule. Product Owners tend to be busy in the real world, and they can rely on the team, delegating work when possible. In most cases, this falls to people with Business Analysis skills. BAs are very good at understanding the underlying business needs and detailing the Acceptance Criteria for a User Story. The one caveat is that BAs tend to think primarily about the “happy path” scenarios and often neglect considering everything that could go wrong. If possible, whoever is documenting the A/C should also consult with someone who has Quality Assurance skills to ensure the A/C provides complete coverage for all possible scenarios or conditions.

How do you know when your Acceptance Criteria are complete?

You know you’re done with your Acceptance Criteria when there are no more questions, and everyone present nods their head in agreement; this generally occurs during Product Backlog Refinement. When you reach a consensus, you need to get your Product Owner’s formal approval, either verbally or by changing the state of a User Story card and marking the User Story as “Ready.”

When reviewing a User Story and its Acceptance Criteria, you may discover that the story is too large. If you have a long list of A/C, with many different paths or scenarios, it’s a “clue” that the story is too large, and you should decompose it further. And this is okay! It’s pretty common to learn that a story is too big to be completed within a single iteration, and splitting it is usually the right thing to do.

Can you update your Acceptance Criteria after approval?

While changing Acceptance Criteria after the User Story is approved is not generally a good practice, in the real world, stuff happens sometimes, and part of being agile is staying flexible and adaptable to changing situations. If a story is already in development, but you learn something new, you may need to halt work, pull the story out of a Sprint, and move it into the Product Backlog to re-evaluate and re-prioritize. Or, you may work directly with the Developer to determine the new requirements, update the Acceptance Criteria, and continue the work. What you do depends on the situation, the urgency, the risk, the priority, and any other factors the Product Owner deems essential.

How can Acceptance Criteria be depicted?

There are numerous ways to depict your Acceptance Criteria. Here are some standard methods along with some less prevalent ones:

There is no right or wrong way to document Acceptance Criteria, and no two people will ever create the same set of detailed requirements. The key is to make sure that you have enough detail for development and have a shared understanding among the team of the User Story’s goal.

Why are Acceptance Criteria so crucial?

Without any Acceptance Criteria, there’s no way for your Developers to know when to stop building. Your A/C define the boundaries or the scope of the User Story, so only the required functionality is built. If you neglect to include any completion conditions, your Developers could go rogue and start developing all sorts of extra things that your Product Owner didn’t ask for and won’t need. It’s also common for more significant confusion and misunderstandings when you don’t have any A/C. There’s also a balance – too few criteria may mean the Developer can interpret things however they want; however, if you provide too much detail, you’ll curtail your Developers’ creativity. It’s a delicate balance, so walk the line carefully.

Final Thoughts

Acceptance Criteria are critical to the success of any agile project. You need just the right amount of detail, just in time – it doesn’t matter who write the Acceptance Criteria, but you should have them. Also, always consider your audience and provide a holistic view of the requirements so you have a shared understanding.

Now, it’s your turn! Do you use Acceptance Criteria? If yes, do you have any tips or tricks you would like to share? If no, then why not, and what problems have your experienced as a result? Also, if not, are you considering adopting this practice after reading my blog? I would love to hear what you think in the comments below!