9.4 Prioritization & Scope Techniques

9.4 Prioritization & Scope Techniques

Quick Summary: Prioritization determines the relative urgency, value, and implementation sequence of requirements. BABOK® Guide v3 details formal prioritization mechanisms (MoSCoW, Timeboxing, Voting Methods) alongside boundary and specification frameworks (Scope Modeling, Use Cases, User Stories) to ensure delivery within real-world constraints.

---

1. MoSCoW Prioritization

MoSCoW Analysis is a collaborative categorization technique that sorts requirements into four discrete priority buckets based on stakeholder value, regulatory necessity, and solution feasibility.

+-----------------------------------------------------------------------------------+
|                             The MoSCoW Framework                                  |
+-----------------------------------------------------------------------------------+
|  M - MUST HAVE:                                                                   |
|  * Critical, non-negotiable requirements essential for launch.                    |
|  * Without these, the solution is illegal, unsafe, or utterly non-viable.        |
|  * Recommended Capacity Allocation: <= 60% of total team effort.                  |
|                                                                                   |
|  S - SHOULD HAVE:                                                                 |
|  * High-value, critical capabilities with temporary, acceptable workarounds.      |
|  * Omission causes operational friction but does not prevent launch.             |
|  * Recommended Capacity Allocation: ~20% of total team effort.                    |
|                                                                                   |
|  C - COULD HAVE:                                                                  |
|  * Desirable "nice-to-have" features implemented only if extra capacity exists.   |
|  * First candidates to be cut if timeboxes or budgets experience pressure.        |
|  * Recommended Capacity Allocation: ~20% of total team effort.                    |
|                                                                                   |
|  W - WON'T HAVE (THIS TIME):                                                      |
|  * Explicitly agreed as out-of-scope for the current release.                     |
|  * Preserved in the backlog for future evaluation, preventing scope creep.        |
+-----------------------------------------------------------------------------------+

[!TIP] The Workaround Test: The definitive line between a Must and a Should is the presence of a viable workaround. If a manual workaround exists (e.g., customer service can manually email a PDF receipt if automated emailing fails), the requirement is a Should Have. If the business cannot operate without it (e.g., PCI-DSS encryption of credit card data), it is a Must Have.

---

2. Timeboxing and Budgeting

Timeboxing and Budgeting establish fixed delivery constraints for schedule or cost, allowing the scope of requirements to vary to guarantee on-time milestone delivery.

   Traditional (Predictive) Triple Constraint      Agile / Timeboxed Triple Constraint
   
            [SCOPE - Fixed]                                  [TIME - Fixed]
                /      \                                         /      \
               /        \                                       /        \
              /          \                                     /          \
      [TIME - Est.]    [COST - Est.]                   [COST - Fixed]    [SCOPE - Variable]

Scope Degradation Strategy

When schedule pressure threatens a timebox, the team does not extend the deadline or compromise technical quality. Instead, the business analyst collaborates with the Product Owner to systematically shed Could Have and Should Have items from the current iteration.

---

3. Voting and Allocation Methods

• Dot Voting (Multi-Voting): Each stakeholder is given a fixed number of dot stickers or digital tokens (e.g., 5 dots) to distribute across candidate requirements. Participants can place multiple dots on a single high-priority item or distribute them broadly, creating a visual heat-map of group priorities.
• Cumulative / 100-Point Allocation (100-Dollar Test): Stakeholders are allocated 100 points (or dollars) to distribute across a list of requirements. This forces stakeholders to perform realistic trade-offs (e.g., allocating 60 points to a single core feature leaves only 40 points for all remaining items).

---

4. Scope Modeling & Boundary Tables

Scope Modeling defines the precise boundaries of what is included and excluded from a solution initiative.

In-Scope vs. Out-of-Scope Boundary Table

---

5. Use Cases and Scenarios

A Use Case describes how an external actor interacts with a system to achieve a discrete, observable goal of value.

+-----------------------------------------------------------------------------------+
|                         Use Case Structural Anatomy                               |
+-----------------------------------------------------------------------------------+
|  USE CASE NAME   : Transfer Funds Between Customer Accounts                       |
|  ACTOR           : Primary: Authenticated Retail Customer. Secondary: Core Ledger.|
|  PRECONDITIONS   : Customer is logged in; source account has active status.      |
|  TRIGGER         : Customer selects 'Initiate Transfer' on dashboard.             |
|                                                                                   |
|  MAIN SUCCESS SCENARIO (Happy Path):                                              |
|  1. Customer selects source account, destination account, and transfer amount.   |
|  2. System validates sufficient available balance and daily transfer limits.      |
|  3. System calculates transaction fee and displays confirmation summary screen.   |
|  4. Customer confirms transaction.                                                |
|  5. System debits source account, credits destination account, and logs audit.   |
|  6. System displays success receipt with unique transaction reference ID.        |
|                                                                                   |
|  ALTERNATIVE FLOWS:                                                               |
|  3a. Transfer amount exceeds $5,000: System prompts for Secondary SMS OTP.        |
|                                                                                   |
|  EXCEPTION FLOWS:                                                                 |
|  2a. Insufficient balance: System displays error alert and halts transaction.    |
|  5a. Core Ledger timeout: System rolls back debit, logs fault, and alerts ops.   |
|                                                                                   |
|  POSTCONDITIONS  : Success: Accounts updated, receipt logged. Failure: State zero.|
+-----------------------------------------------------------------------------------+

UML Use Case Diagram Relationships

• <<include>>: A base use case always executes the included use case unconditionally (e.g., Generate Order <<include>> Authenticate Customer).
• <<extend>>: An extension use case executes only conditionally under specific guard conditions (e.g., Calculate Order Total <--<<extend>>-- Apply VIP Discount Voucher).

---

6. User Stories and the Agile Backlog

A User Story is a lightweight, conversational requirement representation written from the end-user perspective.

$\text{Template: } \textbf{As a } \langle \text{role} \rangle, \textbf{ I want } \langle \text{capability} \rangle, \textbf{ so that } \langle \text{business value} \rangle.$

The INVEST Criteria for Quality User Stories (Bill Wake)

The 3 Cs Framework (Ron Jeffries)

1. Card: The physical index card or Jira token containing the high-level story narrative.
2. Conversation: The continuous, collaborative verbal dialogue between the BA, Product Owner, developers, and testers to explore edge cases.
3. Confirmation: The explicit Acceptance Criteria (often written in Given-When-Then / Gherkin format) that prove the story is successfully completed.

---

Enterprise Scenario: Mobile Banking Wire Transfer Redesign

A digital bank executes a rapid 2-week sprint to deliver an upgraded wire transfer feature:

1. MoSCoW Scoping: Must Have: Domestic ACH transfers up to $10,000 with SMS verification. Should Have: PDF transaction receipt downloads. Could Have: Custom emoji tagging on payment descriptions. Won't Have: International SWIFT wires.
2. 100-Point Allocation: The product council allocated 55 points to biometric step-up authentication, ensuring engineering prioritized security over UI theming.
3. User Story Confirmation: A user story was drafted: "As a premier banking customer, I want to save recurring wire beneficiaries, so that I do not re-type account numbers monthly." Acceptance criteria were formalized using Gherkin: Given a verified beneficiary, When the user selects 'Repeat Transfer', Then the account and routing fields are auto-populated.

---

[!TIP] CCBA Exam Tip: Scenario questions love testing the distinction between <<include>> and <<extend>> in Use Case modeling. Remember: <<include>> is mandatory and unconditional, whereas <<extend>> is optional and conditional.

[!WARNING] CCBA Exam Trap: Be vigilant about the "Everything is a Must" trap in MoSCoW questions. If stakeholders categorize 90% of requirements as Must Have, the prioritization is invalid because it leaves no buffer for scope flexibility during schedule slippage. A healthy MoSCoW baseline allocates <= 60% to Must Haves.