7.1 Requirements Prioritization: MoSCoW, Kano & Effort vs. Value

7.1 Requirements Prioritization: MoSCoW, Kano & Effort vs. Value

Quick Answer: Prioritization is the disciplined process of ranking competing requirements by business value, urgency, effort, and risk to maximize delivery value within finite capacity. The four primary frameworks on the Salesforce BA exam are MoSCoW (Must Have, Should Have, Could Have, Won't Have—capped at 60% Must-Haves), the Kano Model (Basic, Performance, Delighter attributes and their decay over time), the Value vs. Effort Matrix (Quick Wins vs. Major Projects vs. Fill-ins vs. Time Sinks), and Weighted Shortest Job First (WSJF) (Cost of Delay divided by Job Size).

In any enterprise Salesforce initiative, business stakeholders generate far more requests than can be designed, built, and tested within the constraints of available budget, schedule, and team capacity. The natural tendency of department heads is to declare that every single operational wish is a top priority. When everything is deemed a priority, nothing is prioritized, leading to delivery bottlenecks, skipped testing, burned-out delivery teams, and catastrophic go-live failures.

The Salesforce Certified Business Analyst acts as the objective, data-driven facilitator who guides stakeholders away from emotional arguments and toward structured, transparent prioritization frameworks. By applying rigorous prioritization techniques, the BA protects project velocity, establishes clear Minimum Viable Product (MVP) baselines, and ensures that executive sponsors receive the highest possible return on investment (ROI) from their Salesforce platform.

---

The MoSCoW Prioritization Framework

Originating in the Dynamic Systems Development Method (DSDM) and widely adopted across Agile and hybrid software delivery, MoSCoW is the most frequently tested prioritization framework on the Salesforce Business Analyst exam. The acronym stands for four distinct priority classifications:

1. Must Have (M)

Requirements categorized as Must Have are non-negotiable capabilities essential for core business viability, legal compliance, or system security. Without them, the solution cannot be deployed to production, or the business cannot legally or operationally function.

• Evaluation Criteria: If this capability is absent on Day 1, can the business legally transact? Will business operations halt completely? Is there any manual or alternative procedure that could bridge the gap? If the answer is "no workaround exists and operations halt," the item is a legitimate Must Have.
• Examples: Enforcing strict Field-Level Security (FLS) on sensitive Personally Identifiable Information (PII) to comply with GDPR or HIPAA; generating a mandatory tax compliance invoice upon Opportunity closure; calculating core loan interest rates accurately before booking a contract.
• Project Impact: Must Haves define the boundary of the Minimum Viable Product (MVP). If any single Must Have is dropped or incomplete, the release date must be postponed.

2. Should Have (S)

Requirements categorized as Should Have are highly important capabilities that provide substantial business value or operational efficiency, but their absence does not render the solution unusable on launch day.

• Evaluation Criteria: Is the feature critical for optimal performance, but could the business survive the first 30 to 60 days using a temporary, documented, and acceptable workaround? If a viable workaround exists—even if it is labor-intensive, inconvenient, or spreadsheet-based—the requirement is a Should Have, not a Must Have.
• Examples: Automated Omnichannel Case Routing based on agent skill sets. If Omnichannel is not ready for Day 1, supervisors can manually triage and assign incoming support cases from a queue for the first two weeks post-launch.
• Project Impact: Should Haves represent the primary candidates for delivery immediately after all Must Haves are stabilized. However, if velocity slows during a release cycle, Should Haves can be negotiated or rescheduled without delaying go-live.

3. Could Have (C)

Requirements categorized as Could Have are desirable enhancements, convenience features, or "nice-to-have" capabilities that stakeholders would love to possess, but which carry minimal impact if deferred.

• Evaluation Criteria: Would this feature delight users or save small increments of daily time, but has zero negative impact on core business transactions if omitted? If the project team runs ahead of schedule or has leftover sprint buffer, Could Haves can be pulled into development.
• Examples: Custom Lightning Web Component confetti animations when an Opportunity moves to Closed Won; adding a third-party weather widget to the mobile Service Resource page; automated birthday notification emails sent to Account contacts.
• Project Impact: Could Haves act as the ultimate shock absorber in Agile capacity planning. They are the first items dropped whenever unexpected technical complexity or defects arise in Must Have components.

4. Won't Have (W)

Requirements categorized as Won't Have (or Would like in the future) are explicitly agreed by all stakeholders to be out of scope for the current release or project phase.

• Evaluation Criteria: Does the requirement represent valuable thinking that is either too costly, technically unready, dependent on upstream systems, or outside the current project charter? Documenting a requirement as a Won't Have provides immense stakeholder value: it acknowledges the validity of the user's idea, logs it in the backlog for future releases, and prevents perpetual re-debating during current sprint refinement.
• Examples: Integrating Salesforce with an on-premises enterprise data warehouse scheduled for retirement next fiscal year; implementing Einstein Conversation Insights before the telephony system is upgraded to digital CTI.

---

Operationalizing MoSCoW: The 60/20/20 Capacity Allocation

A critical exam concept and real-world standard is the operational capacity rule for MoSCoW. Many inexperienced teams label 90% of their backlog as Must Haves, defeating the entire purpose of the framework. A Salesforce Business Analyst must enforce strict percentage thresholds across the release plan:

Total Release Capacity (100%)
┌──────────────────────────────────────────┬────────────────────┬────────────────────┐
│         MUST HAVES (Max 60%)             │ SHOULD HAVES (~20%)│ COULD HAVES (~20%) │
│        Non-Negotiable MVP Core           │ Acceptable Work-   │ Elastic Contingency│
│        Operations halt if missing        │ around Available   │ Buffer (Dropped 1st│
└──────────────────────────────────────────┴────────────────────┴────────────────────┘
◄────────────────── Must Deliver ─────────►◄──────── Controllable Margin ────────────►

The Workaround Acid Test

When an executive or department lead insists that a feature is a Must Have, the Salesforce BA applies the Workaround Acid Test. The BA asks:

"If this specific automation or screen flow is not available on go-live morning, what is the exact operational consequence? Can an administrator or specialist perform this action manually using a standard report, list view, or spreadsheet for two weeks until Sprint 4?"

If the stakeholder concedes that a manual process can bridge the gap without violating legal statutes or losing enterprise revenue, the BA immediately reclassifies the requirement from Must Have to Should Have. This disciplined facilitation protects the 60% capacity cap.

---

The Kano Model: Mapping Customer Perception & Value Decay

Developed in the 1980s by Professor Noriaki Kano, the Kano Model categorizes product features based on how customers emotionally perceive them and the relationship between implementation degree and user satisfaction. While MoSCoW focuses on release viability, Kano focuses on stakeholder psychology, adoption sentiment, and market differentiation.

Satisfaction
      ▲
      │                 Delighters (Exciters)
      │                     / 
      │                   /   
      │                 /     Performance (Satisfiers)
      │               /     / 
      │             /     /   
      │           /     /     
──────┼─────────/─────/──────────────────► Implementation / Execution
      │       /     /         
      │     /     /           Basic (Must-Be / Dissatisfiers)
      │   /     /             
      │ /     /               
      │     /                 
      ▼
Dissatisfaction

1. Basic Attributes (Must-Be / Dissatisfiers)

Basic attributes represent the foundational, baseline capabilities of a system. Users take them completely for granted and assume they are built-in.

• Customer Dynamic: When present, they produce zero positive satisfaction (users do not praise a system for doing what it is supposed to do). However, when absent or malfunctioning, they cause extreme dissatisfaction and outrage.
• Salesforce Context: User authentication via Single Sign-On (SSO); data persisting correctly when clicking the "Save" button; record-level security preventing junior sales reps from reading human resource salary records; system uptime and reliability.

2. Performance Attributes (One-Dimensional / Satisfiers)

Performance attributes have a linear, direct relationship between implementation quality and customer satisfaction.

• Customer Dynamic: The more capability or speed provided, the higher the user satisfaction; the less provided, the lower the satisfaction ("More is better").
• Salesforce Context: Lightning page load times (loading in 1.2 seconds versus 6.5 seconds); global search response latency; the number of manual clicks required to log a customer call (2 clicks versus 9 clicks); batch data synchronization frequency (near-real-time vs. 24-hour batch delay).

3. Delighters (Attractive / Exciters)

Delighters are unexpected, innovative features that generate disproportionately high positive satisfaction when introduced.

• Customer Dynamic: Because users do not know these capabilities are possible, their absence causes zero dissatisfaction. However, when introduced, they spark immense enthusiasm, executive praise, and widespread adoption.
• Salesforce Context: Einstein generative AI drafting personalized email replies directly in the Service Console; dynamic Lightning record pages that automatically reveal relevant guidance based on predictive opportunity win probability; interactive map visualizations plotting field service routes to avoid heavy traffic.

4. Indifferent & Reverse Attributes

• Indifferent Attributes: Features that users simply do not care about. Allocating engineering hours to them yields neither positive nor negative sentiment. Salesforce example: Creating custom color palettes for report chart widgets when users only consume raw CSV exports.
• Reverse Attributes: Features that cause active frustration when implemented because they introduce unwanted complexity. Salesforce example: Introducing 25 mandatory picklist fields on the Lead creation page, which infuriates sales reps and results in dummy data entry.

Kano Decay: The Inevitable Erosion of Value

A crucial dynamic on the BA exam is Kano Decay. Over time, features inevitably migrate down the Kano curve:

$\text{Delighter} \longrightarrow \text{Performance Attribute} \longrightarrow \text{Basic Expectation}$

When mobile CRM access or automated email logging first entered the enterprise software market, they were breathtaking delighters. Today, if sales reps cannot access Salesforce on their mobile devices or if Outlook/Gmail integration fails to sync calendar invites, users are furious. The BA must recognize that maintaining legacy customizations that were once delighters may now simply be table stakes, and roadmaps must continually innovate to drive authentic delight.

---

The Value vs. Effort (Impact vs. Effort) 2x2 Matrix

When managing large backlogs during release planning or discovery synthesis, the Value vs. Effort 2x2 Matrix provides a rapid, highly collaborative visual sorting mechanism. The BA plots candidate requirements along two axes: Business Value (vertical axis) and Implementation Effort/Complexity (horizontal axis).

Business Value
      ▲
 High │   [ QUICK WINS ]            │   [ MAJOR PROJECTS ]
      │   High Value, Low Effort    │   High Value, High Effort
      │   • Do First (Sprint 1-2)   │   • Plan Carefully / Phase
      │   • Rapid ROI & Momentum    │   • High Architectural Focus
──────┼─────────────────────────────┼──────────────────────────────
  Low │   [ FILL-INS ]              │   [ TIME SINKS / MONEY PITS ]
      │   Low Value, Low Effort     │   Low Value, High Effort
      │   • Do Later / Squeeze In   │   • Do Never / Deprioritize
      │   • Backlog Buffers         │   • Avoid / Eliminate
      └─────────────────────────────┴──────────────────────────────►
          Low Effort                    High Effort        Implementation Effort

---

Weighted Shortest Job First (WSJF) & Cost of Delay

In scaled enterprise environments and Scaled Agile Framework (SAFe) implementations, subjective debates over "Value" often break down. To establish objective economic prioritization, organizations utilize Weighted Shortest Job First (WSJF). WSJF is grounded in the principle of minimizing the Cost of Delay (CoD).

The WSJF Mathematical Formula

$\text{WSJF} = \frac{\text{Cost of Delay (CoD)}}{\text{Job Size (Duration / Effort)}}$

Where Cost of Delay is the sum of three distinct business dimensions:

$\text{Cost of Delay} = \text{User-Business Value} + \text{Time Criticality} + \text{Risk Reduction / Opportunity Enablement (RR/OE)}$

1. User-Business Value: How much financial revenue, operational cost savings, or customer retention does this deliver compared to other features?
2. Time Criticality: Does the value decay rapidly if not delivered immediately? Is there a strict regulatory deadline, contractual cutoff, or seasonal market window (e.g., Black Friday or open enrollment)?
3. Risk Reduction / Opportunity Enablement (RR/OE): Does this feature de-risk future delivery (e.g., refactoring an overloaded Apex trigger into domain architecture), or does it unlock future strategic business capabilities?
4. Job Size / Duration: A proxy for development effort, technical complexity, testing duration, and deployment dependency, typically estimated in modified Fibonacci story points (1, 2, 3, 5, 8, 13, 20).

Worked WSJF Calculation Scenario

Consider four candidate enhancements competing for inclusion in the upcoming quarterly Salesforce release. The BA facilitates a scoring session with the Product Owner and Technical Architect, rating each factor on a relative scale of 1 to 20:

Economic Takeaway

Notice that Feature C (Field Service Scheduling) has the highest absolute User-Business Value (20) and a massive Cost of Delay (42). However, because its Job Size is very large (13 points), its WSJF score is only 3.23.

Conversely, Feature A (GDPR Compliance Flow) has an extreme Time Criticality (regulatory deadline) and high Risk Reduction (avoiding multi-million euro fines), yielding a Cost of Delay of 46 with a tiny Job Size of only 3 points. Its WSJF score is 15.33—nearly five times higher than Feature C! Under WSJF, Feature A is built first. It delivers massive risk mitigation with minimal effort, freeing up capacity for subsequent work.

---

Common Exam Traps & Real-World Pitfalls

• Trap 1: Treating Stakeholder Title as Priority Weight: On the exam, a scenario may describe a Vice President demanding a custom report widget while a customer service team faces severe data corruption during case creation. Candidates often select the option that yields to executive seniority. The correct BA action is to use objective criteria (regulatory compliance, operational viability, Cost of Delay) to guide prioritization, not executive hierarchy.
• Trap 2: Allocating 80% to 100% of Sprint Capacity to Must Haves: Exam distractors frequently suggest filling an entire sprint or release with Must Have requirements. The BA must enforce that Must Haves never exceed 60% of total capacity; violating this rule eliminates project contingency buffers and guarantees schedule slippage when unexpected complexity emerges.
• Trap 3: Confusing Low Effort with High Priority: Inexperienced analysts often pack their backlogs with "Quick Wins" and "Fill-ins" because they are easy to complete, while neglecting foundational "Major Projects" that yield the enterprise's strategic ROI. A Quick Win must still have genuine High Value to merit prioritization.