Decision models, user stories and acceptance criteria

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

Follow by Email

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>