When practicing Behaviour Driven Development (BDD), the details of the user stories are illustrated with BDD scenarios. But how many scenarios are enough for a good understanding? Rules can help. If you break down the user story to rules (acceptance criteria, business rule), collecting scenarios becomes easier, because you can collect them for the rules and not for the entire story. In this post, I am explaining what rules are and how they can help you.

The concept of rules is not new. Rules are essentially the same as acceptance criteria (AC) as it was defined by XP. A lot of teams use acceptance criteria, but not too many of them know what these acceptance criteria are really good for. In BDD, we simply call them  “rules”, so that we can avoid conflicts with the different interpretations of acceptance criteria. It does not matter, what you call it, understanding the concept behind is very useful for practicing BDD.

User Stories

Let’s start with defining the user story. User stories are not classic requirement elements, just like use cases were for example. It would be impossible anyway to summarize the expected behaviour of a feature in a single sentence. A user story is not the requirement, but a reminder for ourselves that we need to define the requirements of a particular enhancement of the application. Ron Jeffries defines the user story cards as “a token representing the requirement”.

There arise a lot of positive consequences from using such user stories instead of properly defined requirement artifacts. One of these benefits is that the user story becomes negotiable. As the details are not fixed, we can adjust them to the actual development context (capacity, budget, skills, etc.).

User stories can also be used to track the progress of the implementation. After having discussed the story the team then agrees to implement it. Implementing it until it is “done”. But how can we say we are done, if the user story is just a single sentence reminder? Whenever we discuss the details of the story, we have to agree on that! We have to agree on what conditions must be fulfilled by the created solution, so that we can accept it and stamp it with “done”. Conditions of acceptance, acceptance conditions, acceptance criteria… I guess you’ve got it.

Rules

The best acceptance criteria are simple statements or rules that have to be fulfilled by the application. Like this:

So far so good. The user story was used to define a topic or goal that we wanted to achieve, the rules have helped us to define the scope (extent) of the story.

Rules can be described at a higher level (e.g. the provided password should be secure) or at a lower level (e.g. the provided password should contain at least one uppercase letter). Defining them at a lower level seems to be a good idea at first sight but it is very easy to get lost in details. Defining the rules at a lower level is pretty exhausting and you might not use the domain knowledge the team might have already (e.g. they already know what “secure password” means in this app).  You need to find the right balance. But since the balance depends on the domain knowledge of the team as well, there are no fix recipes for that. Don’t worry, examples will help.

Examples

Examples are very efficient tools to make sure the entire team has the same understanding of a particular acceptance criteria. This is especially true, if the examples are not just presented to the team, but the examples are used by the entire team to discover the details. For discovering requirement details using examples, you don’t need any fancy tool:  with very simple facilitation techniques, you can become efficient in it. Matt Wynne has described a technique called Example Mapping that we also explained in detail in our book with Seb Rose: Discovery — Explore behaviour using examples (BDD Books 1). You can also check my other articles about Example Mapping: https://gasparnagy.com/tag/example-mapping/

Finding the right number and details for the examples that need to illustrate a particular rule is much easier than finding scenarios directly for the entire story. In the majority of the cases, a rule can be illustrated with 2-3 examples.

Scenarios

Examples have helped to establish a shared understanding, however, to be able to verify the expected behaviour of our application, we need Given/When/Then-based BDD scenarios that can be executed by BDD tools, like SpecFlow or Cucumber.

Fortunately, once you have good examples, it is also easier to write scenarios, because scenarios can be considered as documented or formulated examples. As a result, the breakdown of the user story with the help of rules will also serve as a grouping for the scenarios we write.

Stories, rules and scenarios

Through this brief explanation, you have seen how the requirements can be addressed with user stories, rules and scenarios. The following figure illustrates these elements and their relationship.

The core concept of agile requirement analysis is to delay the discussion and the finalization of requirement details to the time when we have more knowledge about the context and the domain. The most important element of this is the concept of the user story. With the concept of rules and BDD scenarios, you can amplify the values of stories and transform them into a living documentation.