The decision package: the business case, the traceable backlog, and the workshop that actually decides

Your team already has the build-the-business-case, break-requirements-into-a-backlog, and turn-workshop-chaos-into-decisions playbooks — the worked recipes for costing an initiative, tracing requirements into stories, and recapping a session same-day. This module is the layer above the recipe. It’s where you master the judgment that decides whether those three documents survive contact with a skeptical CFO, a delivery team hunting for scope gaps, and a room of stakeholders who all remember the meeting differently — build all three for a real initiative, and prove, against a real rubric, that you can.

It’s Module 3 of the certifiable Business Analyst track. Where the earlier stages of the BA work get you to a signed-off requirements doc and (in a sibling module) a recommended option, this module is where analysis turns into a decision — the funded, buildable, cross-team-aligned package that actually moves an initiative into delivery.

A well-argued business case and a business case that survives being challenged are not the same document. The gap between them is exactly what this module teaches: which numbers you can stand behind, which stories a developer can actually build without guessing, and which workshop outcomes were truly decided versus merely discussed.

Why this module is where “analysis” becomes “decision”

A requirements doc tells you what’s needed. An options analysis tells you what’s possible. Neither one, by itself, gets an initiative funded, built, or aligned across the teams it touches. That takes three more documents, and every one of them has a failure mode that looks fine on first read and falls apart under real scrutiny:

• The business case that only survives a friendly audience. A case with a clean total and an optimistic payback period reads well in a first meeting. It falls apart the moment a CFO asks “where did this number come from” and the honest answer is “I estimated it” dressed up as a fact. The judgment isn’t building a bigger number — it’s building a case where every number’s confidence is visible, so the hard question has an honest answer already on the page.
• The backlog that looks organized but isn’t traceable. A backlog with clean epics and tidy stories can still be scope-drifted — a story that sounds reasonable but traces to nothing, or a requirement that quietly has zero stories covering it. It looks complete. It isn’t, and the gap surfaces mid-sprint, which is the most expensive time to find it.
• The workshop that felt productive but decided less than it seemed to. A cross-team session with good energy and real discussion can still produce almost nothing binding, because “we talked about it for twenty minutes” and “we agreed to it” feel the same in the room and read completely differently a week later.

The three playbooks give you the mechanics for each of these. This module is the judgment that decides whether the mechanics produce a document that survives the room it’s headed into, or one that quietly falls apart the first time someone pushes on it.

Building a defensible business case — the discipline of honest confidence

The business-case playbook already teaches the MEASURED / ESTIMATED / ASSUMED discipline. Mastery is knowing exactly how far that discipline has to go before a case is genuinely defensible, not just labeled.

• A label is not the same as a good number. Tagging a line ASSUMED doesn’t excuse a bad assumption — it flags it as one that still needs a real source before sign-off. The discipline isn’t “label everything and move on.” It’s “label everything, then go get a real number for every ASSUMED line you can, and be honest about the ones you genuinely can’t.” A case that ships with six ASSUMED lines and no plan to replace them is a case that’s honest about being unfinished, not a finished case.
• Every benefit needs visible math, every time. “This saves the support team 20 hours a week” is a claim. “20 tickets/week × 15 min average handling time saved × $35/hour loaded cost = $X/month” is a number you can defend, because anyone can check the arithmetic and argue with an input instead of the conclusion. If Claude hands you a benefit total with no visible calculation, that’s not a shortcut — it’s a gap. Push for the math before the number goes in the case.
• The downside case is not pessimism — it’s what makes the case credible. A case that shows only the base-case payback reads as a pitch. A case that shows “base case: 7-month payback; downside — every ESTIMATED benefit at half, every ASSUMED cost 30% high — still net-positive by month 13” reads as analysis. The decision-maker isn’t looking for the best number; they’re looking for the range, because the range is what tells them whether the initiative is still worth funding if reality lands on the pessimistic side of the estimates.
• Name the risks that break the math, not the risks that sound like risks. A generic risk register (“adoption risk,” “scope risk”) is filler. A math-specific risk — “if the self-serve feature needs a manual review step for flagged disputes, the support-hours-saved benefit drops by roughly 40%, which pushes payback past 12 months” — is the kind of risk a decision-maker actually needs, because it’s tied to the number that changes if the risk lands.
• Know your reader. A case for a CFO leads with the payback math and the downside case, in a page, no hedging. A case for a department head might lead with the problem and the stakeholder need before the numbers. The playbook’s step for “assemble the case in the register the reader expects” is not a formatting nicety — a numbers-first case in front of someone who wants the narrative first, or vice versa, gets read as evasive even when the underlying numbers are sound.

Writing a backlog that’s actually traceable

The user-story-backlog playbook gives you the mechanics: group into epics, draft stories with a “Traces to” line, write Given/When/Then acceptance criteria, run the two-way audit. Mastery is knowing where each of those steps quietly fails if you don’t push on it.

• A trace that doesn’t actually match its requirement is worse than no trace. It’s easy to write “Traces to: R4” on a story and move on. The judgment step is reading R4 back and asking: does this story actually deliver what R4 asked for, or does it deliver something adjacent that sounds similar? A mismatched trace passes a casual review and fails the first serious audit — and by then it’s usually already in a sprint.
• An uncovered requirement is a silent scope cut, not a clerical gap. When the two-way audit turns up a requirement with zero stories, that’s not paperwork to clean up later — it’s a signed-off stakeholder need that’s quietly not going to get built unless someone notices. Treat every uncovered requirement as a stop-and-fix, not a footnote in the backlog doc.
• Acceptance criteria that only cover the happy path create the illusion of “done.” A story with three clean Given/When/Then criteria, all describing the case where everything goes right, looks complete and isn’t. The disagreements that actually matter at review time — what happens when the customer disputes a charge that’s already past the eligibility window, what happens when two team members flag the same transaction — live in the edge cases. If the acceptance criteria don’t force that conversation before delivery starts, it happens during delivery instead, which is more expensive for everyone.
• The epic grouping is a judgment call you make, not one you accept from a first draft. Claude will group requirements that read similarly into the same epic even when they come from different stakeholders with different urgency and different owners. Reading the epic groupings yourself, before stories get drafted under them, is the point where you catch a Finance requirement and a Support requirement getting merged into one epic because they both mention “charge review” — a merge that will cost real confusion once two different teams are each expecting to own “their” story.
• A backlog isn’t done when it’s organized — it’s done when both audits pass. Organized and traceable are different properties. A tidy backlog can still have orphaned stories and uncovered requirements. Run the two-way audit as the actual gate, not the tidiness of the epic structure.

Running (or synthesizing) a cross-team workshop without losing the thread

The workshop-synthesis playbook’s core discipline — separate decisions from discussion, name an owner for everything, keep open questions honestly open — gets harder exactly in proportion to how many teams are in the room. A four-team workshop (Support, Finance, Data, Engineering, in this module’s scenario) multiplies every failure mode the playbook warns about.

• “We discussed it” becoming “we decided it” is the single most expensive trap in a multi-team session. With four teams in the room, a topic can get twenty minutes of genuine, substantive conversation — everyone contributed, everyone nodded along at some point — and still end without an actual agreement, because each team quietly assumed a different resolution. The synthesis has to be ruthless about this: if you can’t point to the specific moment the room agreed, and who was present when they did, it’s an open question, not a decision, no matter how thorough the discussion was.
• More teams means more silently competing assumptions. Support wants the self-serve flag-and-hold feature to reduce ticket volume immediately. Finance wants it to reduce fraud exposure without creating a refund-approval bottleneck. Engineering wants a scope that’s buildable in the sprint window they’ve already committed to. Data wants whatever ships to be instrumented so the next root-cause analysis has real numbers. None of these are wrong, and a workshop that doesn’t surface where they conflict will produce a backlog that quietly satisfies one team’s version of “done” and disappoints the other three. Naming the tension explicitly in the synthesis — even when it isn’t resolved in the room — is more useful than smoothing it into false consensus.
• A decision with no owner from a specific team is a decision that will stall between teams. In a single-team meeting, an unassigned action item usually lands on whoever’s most available. In a cross-team workshop, an unassigned decision falls into the gap between teams — each one assumes the other owns it. Push harder here than the playbook’s single-team baseline: an owner should be a named person from a named team, not “someone from Engineering.”
• Route the unresolved disagreement, don’t let it evaporate. When four teams don’t agree on something material — say, who approves a flagged dispute above a certain value — that disagreement doesn’t go away because the workshop ran out of time. It needs a named owner to resolve it and, per the playbook’s own guidance, a path into a risk register if it’s blocking. A synthesis that lists it as an “open question” and moves on has done half the job; the other half is making sure someone specific is accountable for closing it.
• The recap has to work for four different readers. A recap that a Support lead reads and understands should also make sense, in the same read, to Engineering and Finance and Data — without each team needing their own version. That’s a harder bar than a single-team recap, and it’s why plain language and explicit ownership matter more here, not less.

Your assignment

Build the three documents for one real initiative — your own (recommended: the output becomes the actual case and backlog your team funds and builds from) or the sample initiative worked through this module: Mizan’s Business Analyst Noor Al-Suwaidi, turning a recommended self-serve dispute-a-charge feature into a funded, traceable, cross-team-aligned package. Open your requirements doc (and options analysis, if you have one) in Claude Desktop, approve each read in the “Ask permissions” prompt, and work in the chat. No terminal needed.

Module 3 deliverable — the decision package

1. business-case.md
   - Cost and benefit tables, every line labeled MEASURED / ESTIMATED /
     ASSUMED, with visible math for every benefit
   - Base-case and downside-case payback shown side by side
   - Math-specific risks — each tied to what it does to payback if it hits
   - Addressed to a named decision-maker, in the register they expect

2. backlog.md
   - Epics grouped from the requirements doc, reviewed by you before
     stories were drafted
   - Every story with a "Traces to: [requirement ID] — [stakeholder]'s
     need" line that actually matches its requirement
   - Given/When/Then acceptance criteria per story, including at least
     one edge case or failure path each
   - A completed two-way traceability audit (mismatched traces +
     uncovered requirements), both closed before this ships

3. workshop-synthesis.md
   - Run (or simulate, if using the sample) a session with reps from at
     least three other teams pressure-testing the backlog
   - Decisions section: only things the room explicitly agreed to, each
     with a named owner from a named team
   - Open questions section: genuine unresolved items and real
     disagreement, each with who raised it and who should weigh in next
   - No item appears in both sections — decided or open, never blurred

Bilingual teams: all three documents in Arabic too, authored not
translated. Technical terms (feature names, tool names, team names)
stay in English.

If a prior module’s options analysis exists, ground the business case in the option it recommended and say so explicitly. If it doesn’t exist yet or isn’t finished, cost out a single reasonable approach and state plainly that only one path was evaluated — don’t invent a conflicting recommendation to fill the gap.

How it’s graded — the rubric

Your three files are scored against five criteria. Each is meets / nearly / not yet — and “nearly” on any one is a revise, not a pass.

Module 3 rubric

1. Cost and benefit are labeled     Every line is MEASURED, ESTIMATED, or
   honestly, with the downside      ASSUMED — no unlabeled numbers. Every
   case shown                       benefit shows its math. Base-case and
                                    downside-case payback both appear,
                                    side by side, not just the flattering
                                    number.

2. Every story traces to a real     Every "Traces to" line names a real
   requirement and stakeholder      requirement ID and matches what that
                                    requirement actually says — not a
                                    plausible-sounding paraphrase. The
                                    two-way audit is complete: zero
                                    mismatched traces, zero uncovered
                                    requirements left open.

3. Acceptance criteria leave        Every story has at least one edge-case
   no gaps                         or failure-path criterion, not just the
                                    happy path. Each criterion is specific
                                    enough that a tester could verify it
                                    without asking a follow-up question.

4. The workshop synthesis has       Every decision has a named owner from
   named owners and no orphaned     a named team. No item is ambiguous
   decisions                       between "decided" and "discussed."
                                    Real disagreement is named, not
                                    smoothed into false consensus, and has
                                    someone accountable for resolving it.

5. Both documents are bilingual     Arabic versions authored, not
   (where applicable)               translated. Technical terms (feature
                                    and team names) stay in English.

The discipline is what a delivery lead and a CFO would each separately demand: a business case that survives being challenged, a backlog a developer can pick up without guessing, and a workshop recap that four teams can each read once and agree it’s what actually happened.

The bar, shown — a worked model answer (Mizan)

You don’t have to guess what “meets” looks like. Here’s a passing excerpt for the sample initiative — yours doesn’t need to look like this, it needs to clear the same bar.

business-case.md — self-serve dispute-a-charge feature, Mizan (excerpt)

Problem & stakeholder need
  The March 1, 2026 double-billing incident generated 11 customer
  disputes handled entirely through manual Support intervention,
  each taking 45–90 minutes of agent + finance-reconciliation time.
  Dana Al-Qassimi (co-founder) asked for a formal requirements
  process on a self-serve dispute feature. The prior options
  analysis recommended a self-serve flag-and-hold feature: the
  customer flags a charge, it's held pending review, rather than a
  full automated refund.

Cost (labeled)
  Engineering build (flag-and-hold flow, DB schema, review queue):
    ESTIMATED — 6 sprint-weeks at Mizan's blended eng cost of
    AED 9,000/week = AED 54,000
  QA + rollout:
    ESTIMATED — AED 8,000
  Ongoing: review-queue moderation time:
    ASSUMED — 3 hrs/week at AED 120/hr = AED 1,560/month
    [needs a real number: current manual dispute volume run-rate
    once the March spike settles — flagged for Support to confirm]

Benefit (labeled, math shown)
  Support hours saved on charge disputes:
    MEASURED — 11 disputes in March × 65 min average (from ticket
    data) = 11.9 hours × AED 120/hr loaded cost = AED 1,430/month
    at March's elevated rate;
    ESTIMATED steady-state at ~4 disputes/month once the billing
    bug is fixed = AED 520/month
  Fraud/dispute risk reduction:
    ASSUMED — a flag-and-hold step is expected to reduce
    successful disputed-charge fraud by an estimated 15–20% based
    on industry benchmarks for review-gated refunds; Mizan has no
    internal baseline yet. This line depends on adoption — customers
    have to find and use the feature — flagged accordingly.

Payback
  Base case: build cost AED 62,000; monthly benefit ~AED 520 (support)
    + estimated fraud-risk value not yet monetized conservatively.
    Support-only payback: ~10 years at steady-state volume — NOT
    payback-justified on support-hours-saved alone.
  Reframe: the real case is risk avoidance and CX, not cost recovery.
    Downside case: if adoption is low (fewer customers use self-serve
    than expected) and the review-queue cost runs 30% high, the
    support-hours benefit alone doesn't clear payback in any
    reasonable window.
  Honest conclusion for the decision-maker: this feature is not
  justified on direct cost savings. It is justified on customer trust
  and repeat-incident risk — the case in front of Dana should say so
  plainly, not manufacture a support-savings payback that doesn't hold.

Math-specific risks
  Low adoption (customers don't find/use the flag) cuts the
    fraud-reduction benefit toward zero — impact: removes the
    primary justification for the feature.
  Review-queue backlog if flagged disputes aren't triaged within
    Mizan's stated SLA — impact: creates a new support-load risk
    that could offset the hours this was meant to save.

Addressed to: Dana Al-Qassimi (co-founder), numbers-first, one page,
no hedging language. Ask: fund 6 sprint-weeks of Engineering time,
with the explicit framing that the return is trust/risk, not
support-hours payback.

backlog.md — traceability excerpt (Mizan)

Epic: Self-serve charge dispute flow
  Covers: R2 (customer can flag a disputed charge without opening a
  ticket), R5 (flagged charge is held pending review, not auto-refunded),
  R6 (Finance is notified of every flag within 1 hour)

Story: As a customer, I want to flag a charge I don't recognize,
  so that I don't have to open a support ticket to start a dispute.
  Traces to: R2 — Support's need to reduce manual ticket volume on
  disputes.
  Acceptance criteria:
    Given a customer viewing their billing history,
      When they select "dispute this charge,"
      Then the charge status changes to "under review" within the UI
      immediately.
    Given a customer has already disputed the same charge once,
      When they try to flag it again,
      Then the system shows the existing dispute status instead of
      creating a duplicate — [edge case].

Story: As a Finance reviewer, I want every flagged charge routed to
  a review queue, so that no flag is auto-refunded without a human
  check.
  Traces to: R5 — Finance's need to prevent unreviewed refunds.
  Acceptance criteria:
    Given a charge is flagged,
      When the flag is submitted,
      Then it enters "held" status and appears in the Finance review
      queue within 5 minutes.
    Given a flagged charge sits in the queue past the 24-hour SLA,
      When the SLA is breached,
      Then an escalation notification fires to the Finance lead —
      [edge case/failure path].

Two-way traceability audit
  Mismatched traces: none found.
  Uncovered requirements: R6 (Finance notified within 1 hour) has
  no story yet — CLOSED by adding "Story: As a Finance reviewer, I
  want an immediate notification when a charge is flagged, so that
  the 1-hour SLA in R6 is met" before this backlog shipped.

workshop-synthesis.md — 4-team pressure-test excerpt (Mizan)

Goal: pressure-test the dispute-flag backlog with Support, Finance,
Data, and Engineering before it goes to sprint planning.
Attended: Noor (BA, facilitator), Layla Al-Nasser (Support), Youssef
Hamdan (Finance), Maya Haddad (Data), Bilal Al-Mansouri (Engineering).

Decisions made
  Decision: the review queue SLA is 24 hours, escalating to Finance
    lead if breached. Agreed explicitly when Youssef proposed 24
    hours and Layla and Bilal both confirmed it was workable.
    Owner: Youssef Hamdan (Finance) — owns the SLA policy.
  Decision: flagged-charge notifications go to Finance via the
    existing ops alert channel, not a new email flow. Agreed after
    Bilal flagged that a new email integration would add a sprint.
    Owner: Bilal Al-Mansouri (Engineering) — owns the integration.

Open questions (genuinely unresolved)
  Whether a flagged dispute should pause the customer's next invoice
    generation — Layla raised it as a customer-experience concern,
    Youssef raised a concern about reconciliation complexity if it
    does. Discussed for ~15 minutes; no agreement reached. Maya
    should weigh in next with data on how often disputes span a
    billing cycle boundary.
  Whether Data needs a new event log specifically for flagged
    disputes, beyond what's already captured — Maya raised this;
    parked because it depends on the notification-flow decision
    above resolving first.

Note: the invoice-pause question got substantial discussion but was
explicitly NOT decided — three people had opinions, no one proposed
a resolution the room agreed to, so it stays here, not in decisions.

What you’ve proven — and what’s next

Clear the rubric and you’ve built three things your team will use beyond the module: a business case that survives the hard question instead of dodging it, a backlog a delivery team can pick up without guessing at scope, and a workshop discipline that turns a room full of teams with different priorities into a page of named decisions and honestly-labeled open questions.

The credential you’re earning is “Certified Business Analyst with Claude” — and Module 3 is where the track turns from documenting what’s needed into deciding what gets built, funded, and delivered.

From here the track continues into the analysis and sign-off disciplines that sit on either side of this module:

• The analysis module — the options analysis, the SWOT and risk register, and the judgment that gets an initiative to a recommended option in the first place.
• The sign-off module — turning a decided, traced, funded package into a formally signed-off initiative, and the capstone that runs the full requirements-to-delivery cycle end to end for the certificate.

If you’re rolling this across a team, keep the same discipline this module teaches — honest confidence labels, real traceability, decisions separated from discussion — as the standard every initiative your BA function ships is held to, not a one-time exercise for this module alone.