[ad_1]
Writing Acceptance Criteria in the Form of Business Rules
Business rules are a form of business requirements that, once created, do not require programmer involvement to be changed. They make excellent Acceptance Criteria.
For example, if a marketing department wants to give a 10% discount to students living in Florida during the winter season, it needs to specify this option in Business Rules. Marketing wants to be able to make these changes on the fly to adapt to current market changes and stay competitive. Business Rules give them that ability.
In their simplest definition, Business Rules are policies that define, trigger, or restrict business activities. They are an integral part of User Stories, and describe the processes, definitions, and constraints that apply to the business.
Business Rules are not just about technology – they relate to people, processes, business behaviors, and systems. They help the organization achieve its goals.
To clarify the terms:
- Business Rules give you the criteria and conditions for making a decision.
- A User Story or Business Requirement enables the implementation of and compliance with a Business Rule.
If you define the Acceptance Criteria for a User Story in the form of Business Rules, you can quickly clarify a complex Stakeholder Requirement. Here is a sample of this Acceptance Criteria type:
To reduce the abandonment rate, underwriters can accept or reject applications for automobile insurance within 3 business days.
When does the business day begin and when does it end? Are weekends business days? Until you know the answer to these questions, you can’t measure whether the software implements the User Story correctly.
The most common form of a Business Rule is a statement of fact. To ensure a correct implementation of this User Story, you could write the Acceptance Criteria to reference (or even quote) the specific Business Rule:
BR107: The business day starts at 8 am and ends at 5 pm UTC-7 Mondays through Fridays except on legal US holidays.
[ad_2]
Source link
