Business rules are a set of statements that indicate whether or not something can be done or provide criteria and conditions for making decisions.

Business rules are a set of statements that indicate whether or not something can be done or provide criteria and conditions for making decisions.

Splitting users stories can have a significant impact on how teams behave, and to an extent, the performance the team.  For example, the granularity of user story splits could lead a team to accept or not accept a specific story into a sprint, and if a large story is taken into a sprint it might not be completed causing the team to fail to reach the commitment they have made, thereby reducing motivation and productivity.  Splitting stories is not a trivial exercise.  Patterns application and user behavior are tools to help teams decide how to split user stories.  Business rules are a type of pattern than can be used to split user stories. Business rules are a set of statements that indicate whether or not something can be done or provide criteria and conditions for making decisions (from BRCommunity.com).

Using the time accounting application from Splitting User Stories by Workflow, we defined a large user story for logging time as:

  1. As a time accounting user, I want to log into the time accounting system securely so that I can log my time.
  2. As a project manager, I want to be able to review and approve time and expenses logged to my projects to ensure accurate reporting and billing.

There are several business rules that govern time accounting. An example of the business rules are governing the number hours that can be booked in a week:

  1. Employees must log at least 40 hours of work per week.
  2. Contractors may log less than 40 hours of work per week.

Applying splits based on the business rule examples for the number of hours booked would yield two potential stories. 

  1. As a business owner, I want employees to account for a full week’s work of at least 40 hours so that I can ensure all employees are busy delivering value.
  2. As a business owner, I want contractors only to enter the time they work so that I do not overcharge clients.

The first story is the most general and the second is more constrained, which suggests some dependence between the two stories. Either could be developed first, although it might be easier to go from general to specific logically.

A second set of of business rules governing who can approve the time entered include:

  1. Time entered for a specific project must be approved by the project’s project manager.
  2. An employee manager must approve time entered by contractors for payment.
  3. Executive managers can approve time when project managers are on short-term leave or vacation.

Restating each of the three rules as user stories would yield:

  1. As a project manager, I want to be able to review and approve time and expenses logged to my projects to ensure accurate reporting and billing.
  2. As a business owner, I only want employee managers to approve time entered by contractors to avoid the appearance of impropriety.
  3. As a business owner, I want to ensure that time can be approved when project managers are on short-term leave or vacation so that billing is not affected.

In all cases we would have to apply the INVEST criteria to determine whether the splits made were granular enough for the team.  Business rules provide team members with a framework for splitting user stories.  Just like splitting based on workflow, business rules as a pattern is just a different way at looking at a set of requirements.  

Advertisements