In 2012 one of my readers contacted me to ask whether business rules and user story acceptance criteria could be considered the same thing. I answered in a blog post that they should not.
However, in 2013 I learned decision modelling, specifically, The Decision Model (TDM) and I was taught by Larry Goldberg and Barb Van Halle. More recently I have learned Decision Model & Notation (DMN) from James Taylor.
Decision modelling dramatically changed how I view business rules. In a nutshell, business rules are not particularly useful on their own. For example, if the business has a rule that a person must be aged 18 or over in order to have an account, that does not give us the full picture. What decision is the business trying to make when taking into account a person’s age? What other data (fact types) does the business take into account when making that decision? At which points in which processes can that decision be made? What other decisions take into account a person’s age?
A decision model takes into account all the fact types needed (there may be hundreds), organises them into logical groups (e.g., relating to a person’s health, employment history, credit rating, etc.), relates those groups to each other and shows how they all drive towards the decision that needs to be made. TDM also goes down to the individual statements (rows) of logic beneath the groups of fact types (DMN does not, although it doesn’t stop you doing it). Each of those statements of logic is essentially a business rule. The corresponding process model shows at what point the decision is made and what the consequences are.
Decision models sit within business architecture. They are a technology-agnostic business asset that not only state what the business’s logic is in relation to particular decisions, but they also allow a business to experiment with and test changes to the logic before deciding whether to implement those changes. Bear in mind that decision logic is not always implemented by software. It is often implemented directly by human beings; for example, when you ask shop assistant whether you may get a refund on a purchased item, the assistant implements decision logic based on certain fact types (purchase date, current date, whether the item was bought in a sale, condition of the item, etc), the company’s policy and consumer legislation.
Atomic tasks in process models are a good source of candidate user stories and since decision models correspond to atomic tasks (of type “business rule” in BPMN terms), for each one that needs to be automated we would have a candidate user story along the following lines:
- As a [business role], I need the logic that allows me to decide Y to be automated, so that [expression of business value – this is essential, as it justifies spending money on automating the decision logic].
User stories are placeholders for conversations between the business and the people building and testing the software. In the case of a decision that is to be automated, the conversation needs to be about the logic of the decision. Of course, if the business comes to the conversation A) not knowing what the logic is and/or B) not having tested that the logic works, then it’s going to be a frustrating and fruitless conversation. The conversation needs to be about transferring trusted business logic to the software development team, not figuring out what that logic is.
That figuring out is called “decision modelling”. It sits entirely within the business domain and it should be done before the software implementation technology is even chosen. The logic should have been worked out and validated, and business test scenarios defined and executed against that logic. By doing so, when it comes to the software development sprint, all focus is on implementing the automation of trusted logic. Failure to do so means stepping into a sprint with unvalidated and untested business logic.
And so we come to acceptance criteria. Back in 2012 I argued that acceptance criteria were not business rules, rather they were test scenarios designed to check whether a software implementation executed business rules (in this case) correctly. My position on that has not changed. I’ve recently discussed this with Agile coaches and decision modellers and we agreed that acceptance criteria (for a decision model) are essentially the test scenarios that the business should already have executed against their decision model. However, because the logic behind a particular decision can be quite sophisticated, that sophistication must also be reflected in the corresponding test scenarios. Documenting all of them, potentially hundreds, as acceptance criteria within a user story strikes me as an unnecessary duplication of effort. Instead, I propose a single acceptance criterion to state that the software will be acceptable if it passes the same test scenarios that the business previously applied to the decision logic.
Not only does this approach avoid duplication of effort in documenting test scenarios, it also places the onus on the business to ensure that only tested logic goes into a software development sprint.
What are your thoughts?
Kind regards.
Declan Chellar
Hi – Agree that AC can be duplication and unnecessary. Hence, I bring in business rules into AC. What’s your thoughts on this and how would business rules be handled if not in a AC if it fits the software level?
Thanks for reading and commenting.
An individual business rule rarely paints the full picture of the decision that is being made by the business at that point of their process.
Take the following business rule (someone is applying for a bank account):
“Applicant must be at least 18 years of age on the day the application is submitted.”
To put it more formally:
“Application Submitted Date minus Applicant Date of Birth is greater than, or equal to, Minimum Allowed Age.”
Separately, Minimum Allowed Age would be defined initially as 18, thus making the rule configurable.
However, that one business rule is not the whole picture. The real question the business wants to answer is: “Do I approve this application for a new bank account?”
The rule about the applicant’s age is just one of many, potentially hundreds, that the business has to take into account to be able to answer that question. The question itself is a Decision task in a business process. A more formal name for this decision could be: “Determine Application Acceptability” and all its logic would be modelled by the analyst in a Decision Model and Notation on Wikipedia.
There would be a corresponding user story to implement the Decision Model. But, since the modelling notation is designed to put structure on the business logic, validate it and test it before even writing the user story, it would be a waste of time to then list all of the business rules as individual acceptance criteria.
What’s more, due to the flat nature of ACs, it would not be possible to show a complex decision that has been normalised into many “child” decisions.
Similarly, there is no point in trying to describe a business process as ACs, when BPMN exists as a notation for process modelling.
Whether process or decision, it is best to attach the model and have one AC that requires its implementation.
Where the model is complex and cannot be delivered in a single sprint, I would have one user story to implement each “component” of the model.
For example, in a complex process, perhaps one US for the “happy” path and one US for each alternative path.
In a complex decision that has been normalised into several “child” decisions, one US for each “child”.
I hope this helps.