Defining acceptance criteria: how to prevent misunderstandings in your team

What are acceptance criteria?

Acceptance criteria are specific conditions that a piece of software must meet to be accepted. They help your team understand, build and check the intended behaviour.

For a discount code, you might agree that:

• Code WELCOME10 gives a 10% discount on full-price products.
• Sale items receive no additional discount.
• An expired code gives no discount. The customer sees: “This discount code has expired.”

These are example rules. Your webshop may work differently, of course. What matters is that you can look at these criteria together and discuss whether this is actually what you want.

That’s already much more useful than “the discount code should work properly”. Although nobody is likely to disagree with that during a meeting.

The problem is often what you leave unwritten

Most misunderstandings happen without anyone trying to be unclear. People fill in missing information with what they already know. The product owner has known the discount rules for years. To them, excluding sale items goes without saying. The developer started working on the webshop last month and has never heard that rule. The tester has mainly checked whether valid and invalid codes are handled correctly.

Everyone is doing their job. And yet something still goes wrong. That’s why simply asking who forgot something after the demo won’t get you very far. A more useful question is: what could we have asked earlier? For example: “Which products does this discount actually apply to?” Good acceptance criteria often grow out of exactly these kinds of simple questions.

From “works properly” to something you can actually use

You don’t need to be a brilliant writer to write acceptance criteria. It mainly helps to notice when a sentence still leaves too much room for interpretation.

Take these examples:

• Before: The discount is applied correctly. 
• After: Code WELCOME10 gives a 10% discount on full-price products. 
• Before: An incorrect code produces an error message. 
• After: An unrecognised code leaves the order total unchanged and displays: “We don’t recognise this discount code.” 
• Before: The customer can only use one code. 
• After: Once a valid code has been applied, the customer cannot add a second code. They can remove the first code.

That last one is a good example. “Only one code” sounds like a clear rule. Until a colleague asks: “What if I accidentally entered the wrong one?”

Then you realise you also need to agree on removing or replacing codes. You haven’t written a line of code yet, but you already understand the intended solution better.

Put a shopping basket on the table

Is the discussion still a little abstract? Try a concrete example. A customer buys a full-price jumper for €60 and a pair of trousers on sale for €40. Delivery costs €5. They then enter WELCOME10.  What do they pay? Under our example rules, only the jumper gets a 10% discount. That’s €6. If the delivery charge stays the same, the order total comes to €99. 

“Hang on,” someone says. “Don’t we offer free delivery on orders of €100 or more?” Now it gets interesting. Is that threshold calculated before or after the discount? And do sale items count towards free delivery, even though they don’t qualify for an extra discount?

One shopping basket suddenly brings several rules to light. You don’t need an elaborate presentation for that. A few numbers on a screen will do. The product owner clarifies the commercial rules. The developer looks at how the calculations interact. The tester thinks of situations where the outcome might differ. That’s how you put the knowledge already in your team to good use.

Ask: “What happens just below that threshold?”

Some rules practically invite you to test them. For example:Orders of €50 or more receive a €5 discount.

You’ll want to know what happens at €49.99, exactly €50 and €50.01. In testing, this is called boundary value analysis: checking values around a boundary, because that’s where errors can easily occur.

But before you start testing, the rule itself needs to be clear. What counts towards that €50? Does it include delivery? Is it before or after other discounts?

And what happens if the customer removes a product after applying the code?

These aren’t far-fetched situations. People change their orders all the time. It would be nice if the discount kept up.

Do we need to think of every exception in advance?

You may already be picturing a meeting where, after 45 minutes, someone asks what happens if the customer places an order from Australia on a leap day.

Fortunately, every change doesn’t need a novel’s worth of acceptance criteria. Start with rules where misunderstandings are likely or could have significant consequences. For a discount code, that might mean the calculation, excluded products and combining codes.

Has a rule not been decided yet? Record it as an open question. “Check whether delivery counts towards the threshold” is more honest and useful than an assumption that somehow ends up looking like a final decision in the user story.

You’ll sometimes discover new things during development and testing. Discuss them and update the criteria. The aim is to have enough clarity to move forward responsibly.

Five questions for your next discussion

Want to try this out? Ask these questions when discussing your next user story:

1. What should happen? Describe the behaviour you expect.
2. Can we give a concrete example? Use an amount, an input or a familiar situation.
3. When should it not happen? Discuss conditions and exceptions.
4. What happens if something goes wrong? Think about incorrect input or a system that doesn’t respond.
5. Where do our expectations still differ? Make room for uncertainty before anyone starts building.

That last question often leads to the most useful conversation. Especially when someone says: “Oh, I thought…” You’ve just uncovered a difference that might otherwise have stayed hidden until the demo.

What does this have to do with TMap?

With TMap, quality is something you work on together. Acceptance criteria help make the intended behaviour concrete. They provide an important foundation, although they don’t automatically tell you everything about quality. Security, performance and operational needs may also require attention, depending on the change. Want to learn how to make these decisions together with your team? The TMap® Quality for cross-functional teams e-learning explores this way of working in more depth.