June 16, 2020

Agile User Story Splitting by Business Rules

Post by: Rachael Wilterdink

Before I dig into this story splitting technique, let me give you a quick primer on what a Business Rule is. According to the BABOK®, a Business Rule is defined as:

“A specific, predictable, testable directive that is under the control of the business and that serves as a criterion for guiding behavior, shaping judgments, or making decisions.”

There are a couple of important things to know about Business Rules:

  • They are often discovered during the process of eliciting requirements, but they are not requirements; they are self-imposed directives of an organization.
  • Ideally, they should be managed outside of the systems against which the rules are applied.

Here are a few examples of business rules:

  • Customers must be over the age of 21 to purchase alcoholic beverages
  • Minors under the age of 13 may not open an account
  • Users cannot register without providing a valid email address
  • Etc.

Business Rules may also be more complex, with conditional logic.

So, how can Business Rules be used a tool to split User Stories? The key word that sticks out to me in the definition is “testable”.

Let’s say my fake Recipe app starts providing not just recipes, but also recommended food and [adult] beverage pairings. That is lovely for us grown-ups, but perhaps as an organization we don’t want to show that extra information to underaged users. We could apply a business rule to our system to check the birth date of the person on the account, and only show the beverage suggestion if the person is over 21. This can be tested in the app by adjusting the birthdates of users with accounts.

What stories could result from this split? 

This is a simple example (and honestly, I could argue for including this as part of one story’s acceptance criteria versus splitting it into two stories – but it’s just an example). Where this becomes especially handy is when the business rule logic is quite complex, with many branches.

Questions to ask:

  • What business rules apply to this story (and where are they documented)?
  • Are the business rules managed by an engine?
  • Are they complex, branching out in many different directions, with possibly different results?
  • Can you start with simple rules, and build off them over time?

As you evaluate using Business Rules as a story splitting technique, be sure that you remember what Business Rules are and how they apply to the work you are doing. Chances are you will uncover some and not even recognize them when you see them. If you’re lucky, your organization is on the mature end of Business Rules management. If not, be sure to watch out for conflicting rules.

Relevant Insights

Are You Falling into the Cloud Conversation Gap?

Most conversations about migrating services to the cloud focus on migration of application workloads and data. The vision is often...

How Aggregation Tables Improve Performance for Power BI Reports

In this blog, Marcus Radue, Solution Architect, offers high-level guidance in the advantages of aggregation tables in Power BI. For a...

Getting Started with Azure DevOps – Views

Like most Microsoft products, there are many ways to look at or perform the same activities. Azure DevOps is no...