Writing Effective Business Requirements

Product Ownership and Technical Translations

A Feature (Business Requirement) should focus on the business outcome and value, not the technical solution. The goal is for it to clearly describe the business need, the user role, and the expected benefit using a format such as “As a Sales Representative, I need a consistent lead qualification process so that only sales-ready leads become opportunities and forecast accuracy improves.”

The Feature should include business scenarios and measurable acceptance criteria that define what success looks like. For example, in Dynamics 365 Sales, a qualified lead must result in the creation of an Account, Contact, and Opportunity, while non-qualified leads remain in the lead management process.

A Technical Product Backlog Item (User Story) defines how the approved Feature will be delivered through configuration, customization, extension, security, automation, reporting, or AI capabilities. For a lead qualification Feature, technical user stories may include configuring either the Sales Qualification Agent for AI-assisted qualification or a traditional Business Process Flow-based qualification process.

Each technical user story must trace directly to the originating Feature, contain detailed technical acceptance criteria, and be broken into implementation tasks.

Business Requirement / Feature Standards

A good Business Requirement (Feature) should:

• Follow the format:
  • As a [Business Role] (clearly define the expected access, and/or role-based entitlements for this requirement)
  • I need [Capability] (what are you trying to do?, scenario)
  • So that [Business Value] (Always provide the goal!)
• Focus on the desired business outcome.
• Avoid technical design decisions or details
• Include one or more business scenarios.
• Define clear, measurable, and testable acceptance criteria.
• Align to User Acceptance Test scripts
• Be clearly understandable by business stakeholders, product owners, testers, and the delivery team.

Example Business Requirement (Feature)

Feature

As a Sales Representative, I need a consistent lead qualification process so that only sales-ready leads become opportunities and forecast accuracy improves.

Business Scenario

• Leads are generated from events, marketing campaigns, referrals, and web forms.
• Sales representatives review lead information.
• Qualified leads are converted into an Prospective Accounts, Contact, and Opportunities.
• The organization may choose:
  • AI-assisted qualification using the Sales Qualification Agent, or
  • Traditional manual qualification using standard Dynamics 365 Sales capabilities.

Business Acceptance Criteria

• Given I am a sales person and a lead exists, when qualification criteria are met, then the lead can be manually or automatically qualified.
• Given a qualified lead, when qualification is completed, then a prospective Account, Contact, and Opportunity are created or an Account and Contact are created (Opportunity is optional)
• Given that the account and/or contact already exists when qualifying the lead then a new account and/or contact will NOT be created but the new opportunity will be associated to the existing account and/or contact
• Given a lead does not meet qualification criteria, when reviewed, then it remains unqualified.
• Given a completed qualification, when management reviews the lead, then qualification history is available for reporting and audit purposes.

Technical Product Backlog Item (User Story) Standards

Technical Product Backlog Items (PBIs) or Technical User Stories should:

• Support an approved Business Requirement (Feature).
• Describe how the solution will be configured or built.
• Include configuration decisions, security, automation, integration, reporting, or AI capabilities.
• Do not introduce NEW business requirements.
• Be traceable to the originating Feature.
• Include detailed, testable technical acceptance criteria.

Technical Product Backlog Item (User Story)

Parent Feature

As a Sales Representative, I need a consistent lead qualification process so that only sales-ready leads become opportunities and forecast is accurate or accuracy improves.

Technical Product Backlog Item / User Story

As a sales representative I need the sales app to be configured to support manual lead qualification capabilities leveraging the new Sales Qualification AI-assisted agent so that I can leverage the most efficient process for qualifying my leads and so that I can create more than one opportunity from any given lead and so that I can see a summary of my lead qualifying efforts.

Option 1: Sales Qualification Agent Configuration

Configuration Scope

• Enable Sales Qualification Agent.
• Configure qualification criteria.
• Configure lead scoring thresholds.
• Enable AI-generated lead research and recommendations.
• Configure seller review and approval process.
• Configure security roles.
• Configure qualification reporting and audit tracking.

Technical Acceptance Criteria

• Given the Sales Qualification Agent is enabled, when a new lead is created, then the agent evaluates the lead using configured qualification criteria.
• Given qualifying information is available, when analysis is completed, then recommendations are presented to the salesperson.
• Given qualification thresholds are met, when seller approval is provided, then the lead can be qualified.
• Given a lead is qualified, when qualification is executed, then an Account, Contact, and Opportunity are automatically created.
• Given qualification activities occur, when reports are reviewed, then agent actions are available for auditing and analysis.

Option 2: Traditional Qualification Process Configuration

Configuration Scope

• Configure Lead table fields.
• Configure Business Process Flow.
• Configure qualification checklist.
• Configure business rules and validations.
• Configure lead scoring fields.
• Configure security model.
• Configure reporting and dashboards.

Technical Acceptance Criteria

• Given a sales representative opens a lead, when required fields are completed, then the lead can advance through the qualification process.
• Given qualification criteria are met, when the user selects Qualify Lead, then an Account, Contact, and Opportunity are created.
• Given required data is missing, when qualification is attempted, then the process is blocked and validation messages are displayed.
• Given qualification is completed, when records are created, then data mapping follows approved business requirements.
• Given security restrictions exist, when an unauthorized user attempts qualification, then access is denied.

Agile Requirement Hierarchy example

Recommended Traceability Model

• Epic → Lead Management and Qualification
  • Feature (Business Requirement) → Consistent Lead Qualification Process
    • Technical Product Backlog Items (User Stories) → Configure Sales Qualification Agent
      → Configure Traditional Lead Qualification Process
      → Configure Lead Scoring
      → Configure Security Roles
      → Configure Data Mapping
      → Configure Reporting and Analytics
      • Tasks → Configuration, Testing, Documentation, Deployment, and Training activities required to complete each Technical Product Backlog Item.

This approach provides clear business-to-technical traceability while aligning with common Agile and Scrum practices of Epic → Feature → User Story → Task.