Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Are Acceptance Criteria evil?

Last post 07:00 am April 30, 2014 by Ludwig Harsch
8 replies
Anonymous
08:52 am April 25, 2014

We often use Acceptance Criteria (AC) per stories to validate if a story is actually done. In our case the AC is equal to the ‘business rules’.
During the Sprint Review the team uses the AC as a guideline for their demo.

Example story:
As customer I want to purchase the goods in my shopping basket so that I can receive my products at home

Acceptance criteria:
• Orders below 10 dollars should be declined.
• Decline customers from outside the US.
• Reserve ordered products from stock for 48 hours.
• Automatically cancel orders for which I have not received payment within 48 hours.

Are AC evil? Instead of adding AC in a story I could also remove them and create separate PBI out of them.


10:34 am April 25, 2014

If you feel that your PBI is a little too large then you should break it down, and if your have good Acceptance criteria then this becomes a little easier. Hopefully each time you discover more and add more you should look at the PBI and say to yourself 'Did this just get too big?' If so... split it out..


Anonymous
10:39 am April 25, 2014

Posted By MrHinsh on 25 Apr 2014 10:34 AM
If you feel that your PBI is a little too large then you should break it down, and if your have good Acceptance criteria then this becomes a little easier. Hopefully each time you discover more and add more you should look at the PBI and say to yourself 'Did this just get too big?' If so... split it out..

So what you’re saying is that when you have good acceptance criteria, it’s easier to use those criteria to create smaller PBIs?


02:47 am April 28, 2014

Acceptance criteria:
• Orders below 10 dollars should be declined.
• Decline customers from outside the US.
• Reserve ordered products from stock for 48 hours.
• Automatically cancel orders for which I have not received payment within 48 hours.

From what I can see from above US is that your AC is covering the business logic of the story, rather than what is defined in the US. There is no doubt that US covers the business logic in most cases, but it is not guaranteed. Increasing the scope of AC by including business logic to have strong AC, adds more work hence, gives the impression that you could make a separate PBI for this US.

AC are pure bliss for us. So, I guess it comes to individual's experience and the way they deal with the situation.


09:19 am April 28, 2014

> Are AC evil? Instead of adding AC in a story I could also remove them and
> create separate PBI out of them.

In the example you give you probably should, because those AC's don't look appropriate for the story. The story describes what the customer wants to do, but the AC's address organizational constraints on order fulfilment. Those constraints point to a different story where value is delivered to a non-customer agent.


Anonymous
03:35 am April 29, 2014

Posted By Ian Mitchell on 28 Apr 2014 09:19 AM
> Are AC evil? Instead of adding AC in a story I could also remove them and
> create separate PBI out of them.

In the example you give you probably should, because those AC's don't look appropriate for the story. The story describes what the customer wants to do, but the AC's address organizational constraints on order fulfilment. Those constraints point to a different story where value is delivered to a non-customer agent.

Hi Ian,

Could you give me a couple of examples of good AC's for this particular story?


09:08 am April 29, 2014

I am no expert at this but I will kick off the list with the following - maybe they are not all correct/valid but it is food for thought

1) customer can pay using credit/debit/pay pal etc
2) Provide for standard or fast delivery service
3) Provide an ETA for delivery
4) ETA should not fall on the weekend


12:06 pm April 29, 2014

Hims gives good examples in 1, 2, and 3. However I'd question 4 unless these are business customers for whom weekend deliveries would be inconvenient.

The key thing to note is that AC's should reflect value from the subject's perspective, just as the story itself does.

For example, the earlier AC about declining orders below $10 may be a valid business rule but it doesn't belong in that story. After all, it's unlikely the customer would want any such restriction. It might be more appropriate to capture it in a story that expresses value from the organization's perspective. For the customer's story to be accepted, it would be reasonable to simply assert that orders can be processed at values of $10 and above, and to say nothing about what happens for lower values. Those criteria would be best asserted elsewhere.


07:00 am April 30, 2014

You have to make a compromise between two criteria for user stories: small and independent.
If you want to include all criteria into the story which are necessary to make it shippable, it can happen that the story becomes too large to be implemented within a sprint. If you split it into several smaller stories, these have dependencies: You cannot implement the story about declining orders below $10 before you have implemented the story about purchasing goods. You cannot ship the story for purchasing before you have implemented the story about declining (I assume - except your Product Owner says you can). If you have additional features to be shipped, you have to keep in mind that they will be delayed as well, or you have to find a way to "block" features (make them not accessible for the users).


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.