Lately, I’ve been working on an Agile project where all the requirements are written in the user story and acceptance criteria format. The acceptance criteria on this project are really the meat and potatoes of the requirements. They tell the developers what to develop and how the system should act in given circumstances. So it is important to get the acceptance criteria correct.

When I first started the project, I used the general process for writing acceptance criteria (the “Given that <some conditions>, system shall <take some action>” format) and this worked fairly well for the so-called “happy path” for each requirement and even major exception cases. But I was never really sure if I had documented everything of importance in the acceptance criteria. Until one day, I had an idea. RML has an exact model for this kind of thing, the Decision Table!

So, a little background: The Decision Table is an RML model the shows all the permutations of complex logic in a system. They are extremely useful in making sure you don’t overlook any combination of logic choices. Now, I give this background because the usual process for writing acceptance criteria is basically one column of a decision table, and I figured, if we created Decision Tables for each user story during grooming, it might simplify the requirements writing process (because the developers would know every case, even the ones in which the system does nothing and because each column then becomes a test for the testers).

Here is the template for the Decision Table:

In this, the conditions and outcomes would come from the acceptance criteria (in this case, we had written the acceptance criteria in long form for happy path and known exceptions)- then just make a column for each unique combination and the PO/Developers can determine which outcome is needed in each “Rule” (Note: the outcome could certainly be the system does nothing, that is important to test to ensure that your new requirements don’t break anything!).

For example, if you had a user story something along the lines of “As  a sales user, I want to be able to add an end user on an order so that my company can track who actually uses the products,” the Decision Table might look something like:

If you wanted to write out the acceptance criteria, they might look like: “Given that the order is an indirect order and that there is no end user on the opportunity, the system should require the end user to associate an end user to the quote, pass that information to downstream systems and allow the sales user to change end-user attributes.” (you could of course break that up J). You can see how this would then lead to 3 distinct acceptance criteria, including one that basically says “Given that the order is not an indirect order, the system should not require an end user.”

Now, a few caveats, I know this is not perfect. To put this detail in too early would be a risk to the conditions or outcomes changing and there is a training factor (people don’t always know how to use Decision Tables at first). However, we’ve found that this works fairly well once everyone knows how to read them and if this is done in grooming the requirements (sprint by sprint). The first set of these requirements with these Decision Tables are being developed and tested now, so we’re still awaiting news on if they were useful for the developers and testers, but we’re hopeful!

How have you used models on Agile projects to facilitate dialog?