Are Acceptance Criteria evil?
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.
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..
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?
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.
> 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.
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?
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
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.
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).