A business rule states a constraint or decision that determines an expected outcome. A request to credit a new member’s previous flights sounds simple until the team asks which flights count. A useful rule must make those decisions clear enough for business stakeholders, developers, and testers to check the same result. section 6.3 section 1.0
Discover rules together rather than treating a User Story as a complete specification. In Example Mapping, place the story above blue cards for rules, add green cards for examples and counterexamples, and record unanswered questions on pink cards. Ask “Is this always the case?” and “What if …?” An example may expose an exception, a new rule, or work that belongs in a separate story. section 6.4.1 section 6.4.2 section 6.4.3
The flight-eligibility table makes several rules visible at once: a flight must be recent, operated by the airline, completed, and already taken. The ineligible rows show why each case fails. section 6.3
Turn a discovered rule into behavior the team can verify:
- State the expected outcome in business terms. For example, European flights earn 100 points; flights outside Europe earn one point per 10 km; business flights earn an extra 50%. section 6.4.1
- Pair the rule with concise positive and negative examples. Include inputs and outcomes in a table when several data variations matter; record boundary details, such as when a 90-day eligibility period begins. section 6.3 section 6.4.2
- Write focused executable scenarios. Start with a simple case and generally test one rule, or one aspect of a complex rule, per scenario rather than combining search, booking, and payment checks. section 7.6.4
Keep the rule separate from the mechanics used to check it. An automated acceptance test can express the outcome in a feature-file scenario, while step definitions, reusable actions, and system interactions handle execution. Use a web test when the rule concerns what the user sees or can do on a screen; check UI-independent logic, such as which passwords qualify as strong, closer to application code. section 9.3.1 section 10.2.3
Rules also help investigate existing workflows. Map both successful and unsuccessful outcomes, then compare what should happen with what the system actually does; otherwise an automated test may preserve a defect. The goal is not merely to exercise an interface, but to verify that the system’s behavior obeys the agreed rules. section 14.1.5 section 15.1
