8.3 Decomposing Complex Epics into Manageable Stories

8.3 Decomposing Complex Epics into Manageable Stories

Quick Answer: Decomposing complex epics requires breaking large, multi-sprint initiatives down through the hierarchy: Initiative → Epic → Feature → User Story → Technical Sub-Task. Rather than horizontal slicing (splitting by database, logic, and UI across separate sprints), BAs must use vertical slicing to deliver thin, end-to-end increments of demonstrable value. Proven splitting patterns (based on Richard Lawrence's methodology) include Workflow Steps, Business Rule Variations, Happy Path vs. Exceptions, Data/Channel Variations, and CRUD Operations.

Enterprise Salesforce projects rarely fail because individual developers cannot write code or administrators cannot build flows. They fail because teams attempt to swallow massive, monolithic requirements whole. When an epic like "Automate Enterprise Quoting and Approvals" is shoved into a sprint without decomposition, delivery stalls, testing bottlenecks emerge, and business stakeholders lose visibility into progress.

Decomposition is the superpower of the Salesforce Certified Business Analyst. It is the analytical discipline of breaking large, complex, ambiguous blocks of business scope into small, discrete, vertically sliced user stories that can be estimated, developed, tested, and demonstrated within a single 1- to 2-week sprint.

---

The Agile Requirements Hierarchy

To decompose scope effectively, a Business Analyst must understand where user stories fit within the broader enterprise planning hierarchy.

Initiative (Enterprise Strategic Program across multiple quarters)
   └── Epic (Large Business Capability spanning multiple sprints or releases)
        └── Feature (Mid-Level Functional Capability within an Epic)
             └── User Story (Vertical Slice of Value completed in 1 sprint)
                  └── Technical Sub-Task (Tactical Admin/Developer work item in hours)

Hierarchy Breakdown & Salesforce Artifact Mapping

---

The Golden Rule: Vertical Slicing vs. Horizontal Slicing

When business analysts and technical teams begin decomposing epics, the most common trap is Horizontal Slicing (splitting by architectural or technical layer).

The Horizontal Slicing Anti-Pattern (Cake Layers)

Imagine a team attempting to build a three-layer cake:

• Sprint 1 (Database Layer): Create 4 custom objects, 80 custom fields, and relationship lookups.
• Sprint 2 (Business Logic Layer): Build 5 record-triggered flows and 2 Apex classes.
• Sprint 3 (User Interface Layer): Build the Lightning Record Pages, dynamic forms, and quick actions.

Why Horizontal Slicing Fails in Salesforce:

1. Zero Deliverable Value: At the end of Sprint 1, the business has a database schema that no user can see or interact with. Value delivered = $0.
2. Hidden Integration Defects: The team discovers that the database fields do not support the UI validation requirements only in Sprint 3—resulting in massive rework.
3. Blocked UAT: Business stakeholders cannot conduct user acceptance testing on a raw schema or headless Apex trigger.

The Vertical Slicing Best Practice (The Slice of Cake)

A Vertical Slice cuts through all architectural layers simultaneously—data schema, business logic, permissions, and user interface—delivering a thin but fully functioning piece of capability that can be demonstrated to stakeholders at the end of the sprint.

---

Richard Lawrence Story-Splitting Patterns Applied to Salesforce

Agile expert Richard Lawrence developed a renowned series of patterns for splitting user stories. Here is how a Salesforce Business Analyst applies these five core patterns to enterprise implementations:

Pattern 1: Workflow Steps (Decomposing Sequential Process Stages)

When an epic covers a multi-step business process, decompose it along the sequential stages of the user's workflow.

• Salesforce Context: Consider a Return Merchandise Authorization (RMA) process in Service Cloud.
  • Slice 1 (Initiate): As a Support Agent, I want to initiate an RMA request from an active Asset record, so that customer returns are logged with a unique RMA tracking number.
  • Slice 2 (Inspection): As a Depot Technician, I want to record physical inspection results and condition grades for returned assets, so that the return reason can be verified.
  • Slice 3 (Resolution): As a Billing Specialist, I want to issue an automated refund credit memo once an RMA inspection is marked 'Approved', so that the customer account balance is reconciled.
• Agile Benefit: The business can start testing and processing intake requests in Sprint 1 without waiting for automated refund accounting to be built.

Pattern 2: Business Rule Variations (Simplicity First, Complexity Second)

Enterprise processes often have a simple baseline rule accompanied by a web of complex exceptions, thresholds, and multi-tier approval matrices.

• Salesforce Context: A sales discount approval epic in Revenue Cloud / Sales Cloud.
  • Slice 1 (Baseline Rule): As an Account Executive, I want quotes with discounts of 15% or less to be automatically approved upon submission, so that standard deals close without management delay.
  • Slice 2 (First-Tier Escalation): As an Account Executive, I want quotes with discounts between 16% and 30% to route automatically to my direct Sales Manager for approval, so that moderate concessions receive managerial oversight.
  • Slice 3 (Multi-Tier Executive Matrix): As a Sales VP, I want quotes with discounts exceeding 30% or non-standard payment terms to require sequential approvals from Finance and the VP of Sales, so that extreme margin erosion is prevented.
• Agile Benefit: Slicing by rule complexity allows 80% of routine quotes to flow through the system after Sprint 1, while edge-case governance is layered into later sprints.

Pattern 3: Happy Path vs. Exception / Edge Case Paths

When building functionality, separate the primary "golden path" (the flow when everything goes right) from the numerous error handling and exception pathways.

• Salesforce Context: Lead conversion and account creation.
  • Slice 1 (The Happy Path): As a Sales Rep, I want to convert a qualified Lead into a new Account, Contact, and Opportunity when no matching records exist, so that I can begin deal negotiations.
  • Slice 2 (Duplicate Match Exception): As a Sales Rep, I want to be alerted when a Lead has the same email or domain as an existing Account or Contact during conversion, so that I do not create duplicate records in our CRM.
  • Slice 3 (Offline / Missing Data Exception): As a Sales Rep, I want the system to flag mandatory missing tax IDs during conversion and save the Lead as 'Pending Enrichment' rather than losing input data, so that I can collect missing details without restarting.
• Agile Benefit: Developers can establish the core data flow and UI quickly, validating basic functionality with users before investing weeks in defensive error handling and complex exception flows.

Pattern 4: Data Variations / Channel Variations

An epic frequently covers multiple types of data inputs, customer segments, or communication channels.

• Salesforce Context: Case intake in Service Cloud.
  • Slice 1 (Channel - Web-to-Case): As a Customer, I want to submit support inquiries via an online web form, so that my case is automatically logged in Service Cloud.
  • Slice 2 (Channel - Email-to-Case): As a Customer, I want to email support@company.com and have an automated case created with attached email threads, so that I can use standard email to seek assistance.
  • Slice 3 (Channel - WhatsApp / SMS Messaging): As a Mobile Customer, I want to message support via WhatsApp, so that I can receive real-time updates on my active service tickets.
  • Alternative (Data Variation - Standard vs Person Accounts): Slice 1 handles standard B2B business accounts; Slice 2 introduces B2C Person Account structures.
• Agile Benefit: Enables iterative go-live by channel or business segment, reducing deployment risk.

Pattern 5: CRUD Operations (Create, Read, Update, Delete/Archive)

When managing a new entity or object, avoid bundling the entire lifecycle into a single story.

• Salesforce Context: Managing custom Partner Certification records.
  • Slice 1 (Read / View): As a Partner Manager, I want to view active certifications and expiration dates on the Partner Account page, so that I can evaluate partner tier eligibility.
  • Slice 2 (Create / Submit): As a Partner User, I want to submit a new certification exam result via the Experience Cloud portal, so that our firm's partner credentials are updated.
  • Slice 3 (Update / Recertify): As a Partner Manager, I want to update certification validity status when renewal credits are verified, so that active records remain accurate.
  • Slice 4 (Archive / Revoke): As a Compliance Lead, I want expired certifications older than 3 years to be automatically archived, so that historical records comply with data retention policies.

---

Comparative Matrix: Lawrence's Splitting Patterns in Salesforce

---

Enterprise Case Study: Decomposing a Massive Epic

The Macro Epic

Epic Description: "Automate Global Partner Onboarding & Deal Registration in Salesforce Experience Cloud." Sized by the team at 40+ story points (spanning at least 4 months of work).

The BA's Step-by-Step Decomposition

The Salesforce Business Analyst conducts a story-mapping session with the VP of Alliances, the Experience Cloud Architect, and the Scrum Master. Using Lawrence's patterns, the BA decomposes this massive epic into five sprint-ready, vertically sliced stories:

1. Story 1 (CRUD - Create / Happy Path): Partner Self-Registration Intake
   • Narrative: As a prospective Channel Partner, I want to submit an initial onboarding application form on our public Experience Cloud site, so that our firm can be evaluated for the partner program.
   • Vertical Slice: Public Experience Cloud site form (UI), Guest User profile permissions (Security), Account/Lead record generation (Data), and email confirmation (Logic).
2. Story 2 (Workflow Step 2): Partner Application Review & Account Provisioning
   • Narrative: As a Channel Operations Specialist, I want to review submitted partner applications and approve qualified applicants with a single click, so that a Partner Account and Community User login are provisioned automatically.
   • Vertical Slice: Lightning Record Page review layout (UI), Flow for Partner User creation (Logic), and Welcome Email with password set (Output).
3. Story 3 (Business Rule Variation - Baseline): Standard Deal Registration
   • Narrative: As a Certified Partner Rep, I want to register a prospective customer deal on the partner portal, so that our firm locks in registered pricing discounts on deals under $100,000.
   • Vertical Slice: Experience Cloud Deal Registration Screen Flow (UI), Deal Registration custom object (Data), and auto-approval logic for <$100k deals (Logic).
4. Story 4 (Business Rule Variation - Complex Exception): Conflict Checking & Executive Approval
   • Narrative: As an Internal Channel Manager, I want deal registrations over $100,000 or deals matching existing direct accounts to route to my approval queue, so that channel conflict is prevented.
   • Vertical Slice: Duplicate Matching Rule execution, Approval Process definition, and push notification to Channel Manager.
5. Story 5 (Channel Variation): Mobile Deal Registration for Field Reps
   • Narrative: As a Field Partner Executive, I want to submit quick deal registrations using the Salesforce Mobile App, so that I can protect accounts immediately following on-site client meetings.
   • Vertical Slice: Compact page layout configuration, mobile quick action, and image upload for business cards.

Outcome: Instead of waiting four months for an all-or-nothing release, the business deploys partner intake in Sprint 1, launches baseline deal registration in Sprint 2, and layers in advanced governance and mobile access in Sprints 3 and 4!

---

Common Exam Traps & Real-World Pitfalls

• Trap 1: Slicing by Technical Sub-Task: On the exam, distractors often propose splitting an epic into: "Task 1: Write Apex trigger; Task 2: Build Visualforce page; Task 3: Run unit tests." These are sub-tasks, not user stories. A user story must always deliver an independent vertical increment of user value.
• Trap 2: Creating 'Orphaned' Exception Stories: When splitting by Happy Path vs. Exceptions, BAs sometimes write exception stories that fail to deliver standalone value because they lack context (e.g., "Display error 404"). An exception story must describe the user's alternate journey to recovery.
• Trap 3: Over-Splitting Into Micro-Stories: Splitting stories until they represent trivial 10-minute configuration tweaks (e.g., "Add one picklist value to Lead Source") introduces massive administrative overhead. Stories should be small enough to complete in a sprint, but substantial enough to represent meaningful user interaction.