app0 — Business Analyst Actionable Toolbox | IIBA BABOK® & Strategyzer

Visual Methodology Architecture • Interconnected BA Ecosystem

💡 Interactive Diagram: Click any box to jump to its technique card below

Logical Relationships Between BABOK® Techniques

An end-to-end delivery sequence illustrating how all 50 BABOK® v3 Business Analysis deliverables interconnect across the 6 project lifecycle phases—from strategic problem framing and stakeholder elicitation through process modeling and backlog prioritization, down to solution evaluation and value realization.

01 Explore & Discover

1. Browse Visually or in Inventory

Trace upstream and downstream artifact flows in the interactive architecture diagram below, or search and filter all 50 techniques in the directory by phase, category, or readiness status.

🗺️ Interactive Map & Search

02 Select & Launch

2. Open Desired Actionable App

Click Open Actionable App ↗ on ready techniques (10.1, 10.2, 10.19, 10.30, 10.33, 10.43, 10.48) to launch dedicated browser workspaces equipped with domain-specific calculators, quality gates, and live exports.

⚡ 7 Actionable Studios Live

03 Interconnected Work

3. Craft & Connect Your Content

Every Actionable App works in direct relationship: map Stakeholders & Personas (10.43), decompose Backlogs (10.2) into INVEST User Stories (10.48), calibrate Estimation (10.19), prioritize with MoSCoW (10.33), calibrate NFRs (10.30), and verify Acceptance Criteria (10.1) without context loss.

🔄 10.43 ➔ 10.2 ➔ 10.48 ➔ 10.19 ➔ 10.33 ➔ 10.30 ➔ 10.1

Strategy & Problem Stakeholders & RACI Elicitation & Discovery Modeling & Architecture Specification & Stories Prioritization & Decision Evaluation & KPIs

IIBA BABOK® Guide v3 • Chapter 10

Complete Inventory of all 50 BABOK Techniques

Browse every technique from the Business Analysis Body of Knowledge. Click the Open Actionable App ↗ button on any technique to launch its dedicated interactive workspace in a new browser tab.

Showing 50 of 50 BABOK® techniques

BABOK Technique 10.X

Actionable Technique Workbench

Structured workspace for executing this technique directly in your browser.

IIBA Methodological Standard

Standard Guidelines

Knowledge Area: Strategy Analysis

Primary Inputs: Business Goals, Stakeholder Concerns

Primary Deliverables: Actionable Artifact

Core Execution Steps

Key Pitfalls to Avoid

Interactive Workspace

Actionable Canvas & Output

1. Objective / Context for this Exercise:

2. Key Analysis Observations & Data Points:

3. Trade-offs, Decisions & Core Mitigations:

4. Next Actionable Deliverables & Owners:

Rendered Markdown Document markdown

Strategy Analysis • Technique 10.8

Strategyzer Business Model Canvas (9 Blocks)

Map and stress-test the strategic architecture of your initiative. Click on any block to add, edit, or remove building blocks.

1 Key Partners

Who are our critical partners and suppliers?

2 Key Activities

What core activities do our value propositions require?

3 Value Propositions

What unique customer problems do we solve?

4 Customer Relationships

What type of relationship does each segment expect?

5 Customer Segments

For whom are we creating primary value?

6 Key Resources

What assets (tech, people, IP) are required?

7 Channels

Through which touchpoints do we reach customers?

8 Cost Structure

What are the most significant operational and fixed costs?

9 Revenue Streams

For what value are customers truly willing to pay?

Strategy & Scope • BABOK Technique 10.40 (Root Cause)

Problem Framing & 5-Whys Diagnostic

Formulate a rigorous problem statement using Minto/SCQA, then drill down to the fundamental root cause using the 5-Whys interrogation chain.

Framing Model

SCQA Problem Charter

1. Situation (Current Context & Baseline)

2. Complication (The Friction / Trigger)

3. Core Question (How Might We...?)

4. Proposed Value Hypothesis / Solution Scope

BABOK 10.40

The 5-Whys Root Cause Chain

Identified Root Cause (Actionable Leverage Point):

BA Planning & Monitoring • BABOK 10.43 & 10.39

Stakeholder Matrix & RACI Governance

Identify key roles, map them across the Power vs Interest quadrant, and ensure crystal-clear accountability with an interactive RACI matrix.

Stakeholder Engagement (BABOK 10.43)

Power vs. Interest Grid

Manage Closely High Power, High Interest

Keep Satisfied High Power, Low Interest

Keep Informed Low Power, High Interest

Monitor (Minimal Effort) Low Power, Low Interest

Roles & Permissions Matrix (BABOK 10.39)

Interactive RACI Governance Matrix

R = Responsible (does work) A = Accountable (approves / owns outcome — strictly 1 per task) C = Consulted (two-way feedback) I = Informed (kept updated)

Deliverable / Decision	Product Owner	Lead BA	Tech Lead	Business Sponsor	End Users

IIBA Methodological Standard • BABOK® Guide v3 Chapter 10.1

Acceptance and Evaluation Criteria — Executive Guide

Requirements Analysis (RADD)

🎯 What this Actionable App is Used For

Acceptance criteria express the definitive, measurable conditions that an increment of software, a user story, or a business process must satisfy to be accepted by business stakeholders and released into production. Evaluation criteria define the scoring dimensions used to assess and compare candidate solution options.

This app acts as the formal quality contract between Business Analysts, Product Owners, Developers, and QA automation engineers, eliminating subjective assumptions before implementation begins.

🔑 Key Methodological Information

Primary Inputs: User Stories (10.48), Business Rules (10.9), Process Models (10.35), Non-Functional Requirements (10.30).
Primary Deliverables: Gherkin Given-When-Then Scenarios, INVEST Verification, Definition of Done.
RACI Accountability: Product Owner (Accountable), Lead BA (Responsible for authoring), QA / Test Lead (Consulted on testability), Technical Lead (Consulted on feasibility).
Golden Rule: Every criterion MUST be testable with an indisputable boolean outcome (Pass or Fail). Subjective adjectives like "user-friendly" or "fast" are invalid without measurable thresholds (e.g. < 200ms).

⚠️ Critical Pitfall to Avoid: Writing only positive "happy-path" criteria while omitting error, boundary, and negative scenarios (e.g. invalid credentials, API rate limits, network timeouts). Always define at least 1 negative scenario and 1 edge case per user story.

Requirements Analysis & Design Definition (RADD)

Interactive Acceptance Criteria & Gherkin Studio

Formulate user stories conforming to the INVEST rubric and generate bulletproof Given / When / Then acceptance scenarios ready for Jira, Confluence, and Azure DevOps.

Story Formulation (10.48)

User Story Context

As a [User Role / Persona]:

I want to [Capability / Action]:

So that [Business Value / Outcome]:

Acceptance Criteria (10.1)

Gherkin Acceptance Scenarios

Quality Gate

INVEST Quality Check

Independent — Can be developed & delivered independently Negotiable — Captures intent, leaves room for technical co-design Valuable — Delivers clear tangible value to the customer/business Estimable — Scope is sufficiently clear for sizing Small — Sized appropriately for single sprint completion Testable — Objective pass/fail criteria via Given-When-Then

Export Deliverable

Standard GFM Markdown formatted for Confluence, GitHub, or documentation.

Markdown (GFM / Confluence) markdown

IIBA Methodological Standard • BABOK® Guide v3 Chapter 10.48

User Stories & INVEST Slicing — Executive Guide

Requirements Analysis (RADD)

🎯 What this Actionable App is Used For

A User Story expresses business requirements from the direct perspective of an end-user persona: "As a [role], I want [capability], so that [measurable business benefit]".

Under Ron Jeffries' classic 3 C's framework (Card, Conversation, Confirmation), a user story is never a rigid monolithic contract; it is a token for ongoing dialogue between stakeholders, Business Analysts, and engineers to discover optimal solutions and slice value into sprint-sized increments.

🔑 Key Methodological Information

Primary Inputs: Stakeholder Personas (10.43), Scope & Functional Decomposition (10.44 / 10.24), Customer Journey Maps, Problem Statements (10.40).
Primary Deliverables: Sized, vertically-sliced User Stories adhering to INVEST, SPIDR Slicing Plan, linked Acceptance Criteria (10.1).
RACI Accountability: Product Owner (Accountable for value & priority), Lead BA (Responsible for elicitation & story formulation), Tech Lead / Dev Team (Consulted on sizing & feasibility), QA Lead (Consulted on testability).
Golden Rule (INVEST Rubric): A story is sprint-ready ONLY when it is Independent, Negotiable, Valuable, Estimable, Small (delivered in 1 sprint), and Testable.

⚠️ Critical Pitfalls to Avoid: (1) Writing "Technical Stories" disguised as user stories (e.g. "As a database, I want an index on ID") — stories must deliver real human or business capability. (2) Horizontal slicing (building DB in Sprint 1, API in Sprint 2, UI in Sprint 3) — always slice vertical end-to-end value through all architectural layers.

Requirements Analysis & Design Definition (RADD)

Interactive User Story Studio & SPIDR Slicing Engine

Formulate user stories, select targeted SPIDR slicing strategies, validate against the INVEST quality gate, and export directly to Jira, Confluence, and Azure DevOps.

Story Framing (10.48)

User Story Formulation

Story ID / Key:

Epic / Feature Link:

Priority:

Story Points (Fibonacci Effort):

As a [User Role / Persona]:

Presets:

I want to [Capability / Action]:

So that [Measurable Business Value / Outcome]:

Vertical Slicing Method

SPIDR Story Slicing Strategy

Select the primary dimension used to split this story into single-sprint vertical increments:

S Spikes

Timeboxed technical research before building

P Paths

Split happy path from edge / error flows

I Interfaces

Split web UI, mobile, or backend API

D Data

Split simple data schemas from complex

R Rules

Relaxed business rules first, strict later

Slice Breakdown & Sub-Story Notes:

🔗 Attach Acceptance Criteria (BABOK 10.1)

Every ready user story requires Given-When-Then criteria to verify testability before development starts.

Open 10.1 Studio ↗

IIBA Methodological Standard • BABOK® Guide v3 Chapter 10.33

Requirements Prioritization & WSJF — Executive Guide

Prioritization & Decisions

🎯 What this Actionable App is Used For

Prioritization evaluates candidate requirements, user stories, and features to determine their relative implementation urgency and economic value against finite team capacity and release deadlines.

This app unifies the 3 industry-standard prioritization frameworks:

1. MoSCoW Method: Qualitative scope gating into Must (≤60%), Should, Could, and Won't.
2. WSJF (Weighted Shortest Job First): Math-driven economic prioritization using Cost of Delay over Job Size.
3. Value vs. Complexity 2×2 Matrix: Visual portfolio quadrant isolating Quick Wins from Time Sinks.

🔑 Key Methodological Information

Primary Inputs: User Stories (10.48), Acceptance Criteria (10.1), Backlog Items (10.2), Risk Analysis (10.38), Architecture Constraints.
Primary Deliverables: Ranked Release Backlog, MoSCoW Capacity Audit, WSJF Scoring Matrix, Decision Log (10.17).
RACI Accountability: Product Owner (Accountable for final ranking & cut-line decisions), Lead BA (Responsible for facilitating scoring, framing criteria, and impact analysis), Tech Lead (Consulted on complexity and architectural dependencies), Sponsors & Stakeholders (Consulted on business value).
Golden Rule (The 60% Capacity Constraint): "Must Haves" MUST NEVER exceed 60% of total sprint or release capacity. Reserving 20% for Should Haves and 20% for Could Haves provides the vital schedule buffer required when unforeseen technical complexity arises.

⚠️ Critical Pitfalls to Avoid: (1) "Everything is a Must" Syndrome: Stakeholders claiming all requirements are non-negotiable. Enforce the 60% capacity rule or use WSJF economic scoring to break deadlocks. (2) Ignoring Architectural Dependencies: Prioritizing a customer-facing feature as "Must" while placing its required foundational data model or API security in "Could".

Requirements Analysis & Life Cycle Management

Interactive Prioritization Studio & Capacity Guard

Classify requirements via MoSCoW, compute mathematical WSJF economic rankings, monitor release capacity thresholds, and export directly to Jira, Confluence, and Azure DevOps.

MUST

Non-Negotiable

0

Critical for launch; system fails or violates legal/business policy without it.

SHOULD

High Impact

0

Important but a manual workaround exists for the initial release window.

COULD

Desirable / Nice to Have

0

Included only if time and remaining capacity allow without risk.

WON'T

Out of Scope (for now)

0

Explicitly documented out-of-scope to protect delivery timeline.

SAFe® Economic Model

Weighted Shortest Job First (WSJF) Ranking Table

Formula: WSJF = Cost of Delay / Job Size = (User-Business Value + Time Criticality + Risk Reduction / Opportunity Enablement) / Job Size.
List of Values: Standard SAFe® Modified Fibonacci scale (1, 2, 3, 5, 8, 13, 20) prevents false precision and enables objective relative sequencing.

Feature / Requirement	MoSCoW	User Value (SAFe)	Time Crit. (SAFe)	Risk Red. (SAFe)	Job Size (SP)	WSJF Score

Strategic Portfolio Map

Value vs. Complexity 2×2 Portfolio Grid

Classify requirements across business impact and technical execution difficulty to guide roadmap sequencing:

DO FIRST

🚀 Quick Wins

High Value, Low Complexity (High ROI, rapid delivery)

PLAN CAREFULLY

🏛️ Strategic Bets

High Value, High Complexity (Core architecture, split via SPIDR)

FILL-IN

⏳ Low Hanging / Fill-Ins

Low Value, Low Complexity (Do when between major stories)

AVOID

⚠️ Time Sinks

Low Value, High Complexity (Deprioritize or drop)

Export Prioritized Backlog

Standard GFM Markdown formatted for Confluence, GitHub, or documentation repositories.

Markdown (GFM / Confluence) markdown

BABOK® Technique 10.2 • Prioritization & Delivery Management

👥 10.43 Stakeholders 🔗 10.48 User Stories 🎯 10.19 Estimation ⚖️ 10.33 Prioritization 🛡️ 10.30 NFR Studio 🧪 10.1 Acceptance Criteria

IIBA BABOK® Guide v3 — Technique 10.2

Backlog Management & Progressive Refinement — Executive Guide

A disciplined, transparent method to record, sequence, track, and groom all outstanding work items — balancing customer-facing user stories against technical debt, defects, and regulatory compliance.

🎯 Core Methodology Principles

The Backlog "Iceberg" Model: Items near the top of the backlog are small, detailed, and INVEST-sliced with testable Definition of Ready (DoR) criteria. Deep backlog items are coarse-grained epics refined progressively just-in-time.
Diverse Item Taxonomy: A healthy enterprise backlog contains 4 distinct work types: User Stories / Features (customer value), Technical Debt (architectural runway & refactoring), Defects (corrective quality), and Spikes (exploratory risk reduction).
Definition of Ready (DoR) Quality Gate: A strict non-negotiable checklist ensuring a user story has clear acceptance criteria, zero unresolved external blockers, and dev team estimation before entering sprint execution.
Backlog Hygiene & Decay Rule: Backlogs suffer from "Backlog Rot." Items sitting unrefined and untouched for > 90 days must be aggressively culled or archived to prevent backlog noise and cognitive overload.

🔑 Operational Delivery Standards

Primary Inputs: Elicitation findings (10.18, 10.50), Prioritized Themes (10.33), Production Defects, Non-Functional SLAs (10.30), Architectural Constraints.
Primary Deliverables: Ordered Product Backlog, Sprint-Ready Pipeline, Technical Debt Ratio, Release Roadmap, DoR Audit Scorecard.
RACI Accountability: Product Owner (Accountable for final business ordering), Lead BA (Responsible for backlog refinement, DoR gate audits, and requirement slicing), Tech Lead (Consulted on technical debt, sizing, and architectural sequencing), Delivery Team (Responsible for Story Point estimation).
Recommended Velocity Buffer: Maintain 2.0 to 3.0 sprints of fully groomed, DoR-passed backlog items ahead of the engineering team to prevent mid-sprint stalls.

⚠️ Critical Pitfalls to Avoid: (1) The "Infinite Black Hole": Treating the backlog as an unmanaged dumping ground with hundreds of forgotten tickets. Prune stale items regularly. (2) Zero Technical Debt Allocation: Dedicating 100% of sprint capacity to new features while ignoring technical debt until delivery collapses. Cap tech debt at 15–20% of capacity. (3) Premature Over-Refinement: Writing granular Given-When-Then criteria for items 6 months away before business priorities are validated.

Backlog Health & Operational Analytics

Backlog Health & Velocity Radar

Real-time monitoring of velocity coverage, Definition of Ready (DoR) compliance, technical debt ratio, and backlog decay.

Total Backlog Items

9 Items

36 Story Points

Sprint-Ready Buffer

18 SP Ready

1.1 Sprints (Low) Target: 2–3 Sprints

Definition of Ready (DoR)

56%

5 of 9 items passed (5/5 gates)

Technical Debt & Bugs

28%

10 SP (Target ≤ 20%)

Backlog Decay (> 60d)

1 Item

Prune Candidate

Intake & Progressive Capture

Add Item to Backlog

Backlog Inventory

Ordered Work Items & Quality Gate Audits

Rank	Type	Work Item Summary	Release Bucket	Effort	Definition of Ready	Age	Actions

Interoperability & Delivery Alignment

Multi-Platform Backlog Export Engine

Export the structured backlog directly to GitHub Markdown, Jira CSV bulk-import format, or Azure DevOps work items.

Standard GitHub-flavored Markdown for Sprint Planning documentation and Confluence.

Markdown Backlog Summary markdown

BABOK-10.30 Requirements Analysis & Design (RADD) ● Studio Live

👥 10.43 Stakeholders 📋 10.2 Backlog 🔗 10.48 User Stories 🎯 10.19 Estimation ⚖️ 10.33 Prioritization 🧪 10.1 Acceptance Criteria

IIBA BABOK® Guide v3 — Technique 10.30

Non-Functional Requirements Analysis (NFR Studio) — Executive Guide

Transform qualitative stakeholder wishes into testable, quantifiable Service Level Agreements (SLAs), Service Level Objectives (SLOs), and architectural quality constraints structured across the ISO/IEC 25010 international standard.

🎯 Core Methodology Principles

The ISO/IEC 25010 Quality Model: Systems are evaluated across 8 fundamental dimensions: Performance Efficiency, Security & Privacy, Reliability & Availability, Usability, Maintainability, Compatibility, Portability, and Scalability.
SLA vs. SLO vs. SLI Hierarchy: SLAs are contractual commitments with business penalties; SLOs are internal engineering target thresholds; SLIs are real-time telemetry metrics measured continuously by APM probes.
The "Quantification Imperative": A non-functional requirement without a numeric threshold, operator (<, ≤, ≥), and measurement context is merely an untestable wish. Vague statements like "system must be fast and secure" are strictly prohibited.
Definition of Done (DoD) Quality Gates: NFRs act as non-negotiable architectural quality gates that every functional User Story must satisfy before graduating to production.

🔑 Operational Delivery Standards

Primary Inputs: User Stories (10.48), Backlog items (10.2), Legal & Regulatory frameworks (GDPR, FINMA, PCI-DSS, HIPAA), Architecture constraints, Disaster recovery plans.
Primary Deliverables: Quantified NFR Specification Matrix, Architecture Quality Attribute Sheet, Telemetry SLI Verification Checklist, Jira & ADO DoD Quality Gates.
RACI Accountability: Solution Architect (Accountable for feasibility & latency budgets), Lead BA (Responsible for business impact & SLA definition), InfoSec & Compliance (Consulted on encryption and audit logs), Dev/QA Team (Responsible for automated benchmark validation).
The Triad Rule: Every critical business journey must satisfy at least 3 quantified NFR pillars: Performance (p95 latency), Security (encryption & RBAC), and Reliability (uptime & RTO/RPO).

⚠️ Critical Pitfalls to Avoid: (1) Unbounded Over-Engineering: Demanding "five nines" (99.999% uptime) or "< 10ms latency" without evaluating the exponential cloud infrastructure costs. (2) Untestable Subjectivity: Writing requirements that cannot be verified by an automated load test, static code scan, or security penetration audit. (3) The Post-Launch Surprise: Treating NFRs as an afterthought during the final sprint, triggering costly architectural rewrites.

Quality Attributes & Telemetry Analytics

NFR Health & Architectural Radar

Real-time monitoring of contractual SLA tiers, metric quantification rate, architectural verification status, and ISO 25010 coverage spread.

Active NFR Constraints

8 Constraints

Covering 7 of 8 ISO Dimensions

Critical SLA Gates (Tier 1)

4 SLAs

Strict Contractual Gate

Quantification Rate

100%

All Metrics Measurable

Architectural Compliance

63%

5 of 8 verified (Passing)

At-Risk Constraints

1 At Risk

Audit Pending

Quality Gate Intake

Define New Non-Functional Requirement

ISO 25010 Quality Category:

NFR Statement / Target Capability:

Quantified Metric & Threshold:

Criticality / SLA Tier:

Verification Method:

Target Scope / Item Link:

Quality Attribute Specification Matrix

Active NFR Quality Gates

ID	ISO Category	Requirement Statement	Quantified Metric & Threshold	SLA Tier	Status	Actions

Interoperability & Governance

Multi-Platform NFR & DoD Export Engine

Export architecture quality attribute sheets, Jira NFR quality gates, or Sprint Definition of Done (DoD) checklists.

Markdown Architecture Quality Attributes markdown

BABOK-10.19 Prioritization & Decisions ● Studio Live

👥 10.43 Stakeholders 📋 10.2 Backlog 🔗 10.48 User Stories ⚖️ 10.33 Prioritization 🛡️ 10.30 NFR Studio 🧪 10.1 Acceptance Criteria

IIBA BABOK® Guide v3 — Technique 10.19

Estimation Engine (PERT 3-Point & SAFe® Fibonacci) — Executive Guide

Transform subjective guesses into statistical forecasts. Balance relative complexity sizing (Modified Fibonacci) with probabilistic three-point PERT modeling (Beta distribution) to compute expected durations, variance, and 95% confidence delivery windows.

🎯 Core Methodology Principles

The PERT Beta Distribution: Three-point estimation recognizes asymmetry in software engineering: Expected Duration E = (O + 4M + P) / 6, where O is Optimistic, M is Most Likely, and P is Pessimistic.
Variance & Volatility Index: Standard deviation σ = (P - O) / 6 measures uncertainty. A wide spread between Pessimistic and Optimistic highlights architectural ambiguity or external integration risk.
Confidence Intervals (CI): Single-point estimates fail because reality is probabilistic: 68% CI = [E - σ, E + σ], while 95% CI = [E - 2σ, E + 2σ].
Relative Sizing (SAFe® Fibonacci): Humans struggle with absolute hours due to optimism bias, but excel at relative comparison (1, 2, 3, 5, 8, 13, 20 Story Points).

🔑 Operational Delivery Standards

Primary Inputs: User Stories (10.48), Backlog items (10.2), Architectural constraints (10.30), Historical team velocity.
Primary Deliverables: PERT Expected Timeline, Portfolio Standard Deviation, Calibrated Story Point Backlog, Recommended Risk Contingency Reserve.
RACI Accountability: Development Team (Accountable for sizing), Tech Lead (Responsible for technical risk), Product Owner (Consulted on business priority), Lead BA (Responsible for acceptance criteria clarity).
Statistical Portfolio Summation: Expected Total = ∑ Eᵢ, Portfolio Standard Deviation = √(∑ σᵢ²) (summing variances, not linear standard deviations).

⚠️ Critical Pitfalls to Avoid: (1) Equating Estimates to Commitments: Treating a probabilistic forecast range as a legally binding deadline without a contingency buffer. (2) The Anchoring Trap: Allowing senior leaders or loud team members to state a number first, biasing everyone else's vote. (3) Linear Buffer Padding: Arbitrarily adding 30% padding instead of computing statistically derived portfolio risk reserves 2 × σ_total.

Probabilistic Delivery Metrics • Monte Carlo Readiness

Estimation Health & Statistical Radar

Real-time portfolio variance analysis, expected duration aggregate, 95% confidence delivery bands, and recommended risk contingency reserve.

Total Estimated Scope

32.5 Days

8 Items • 35 Story Points

95% Confidence Window

28.2d – 36.8d

E ± 2σ Bound

Risk Contingency Reserve

+4.3 Days

+13.2% Recommended Buffer

Fibonacci Velocity Velocity

4.4 SP

Standard Sprint Distribution

Portfolio Volatility Index

13.2%

Low Risk / High Confidence

Probabilistic Calibration Intake

Calibrate New Work Item Estimate

Mode:

📐 PERT 3-Point Mode Active: Enter duration in days (Optimistic, Most Likely, Pessimistic). The engine calculates Beta Expected Duration E = (O + 4M + P)/6 and automatically recommends the closest SAFe® Story Points.

Work Item / Story Title:

Domain / Category:

Optimistic (O) [Days]:

Most Likely (M) [Days]:

Pessimistic (P) [Days]:

SAFe® Story Points:

🎯 SAFe® Fibonacci Golden Calibration Anchors Click any anchor to auto-calibrate intake values

1 SP • XS

Trivial copy tweak, simple CSS fix, config toggle. Zero uncertainty.

2 SP • S

Minor form validation, new database column with standard migration.

3 SP • M

Standard UI component + well-defined internal REST endpoint.

5 SP • L (Anchor)

Golden Baseline: Full CRUD screen, DB tables, unit & integration tests.

8 SP • XL

Multi-step workflow, external webhook integration, async queue.

13 SP • XXL

High architectural uncertainty or spike. Split using 10.48 Slicer.

Statistical Estimation Catalog

Active Work Items Estimation Matrix

ID	Work Item Summary	Domain	O (Opt)	M (Likely)	P (Pess)	Expected (E)	Std Dev (σ)	Story Points	Actions

Interoperability & Delivery Integration

Multi-Platform Estimation Export Engine

Export statistical PERT forecasting schedules, Atlassian Jira effort CSVs, or Azure DevOps Work Item estimates.

Markdown Executive Estimation Report markdown

BABOK-10.43 Stakeholders & RACI ● Studio Live

📋 10.2 Backlog 🔗 10.48 User Stories 🎯 10.19 Estimation ⚖️ 10.33 Prioritization 🛡️ 10.30 NFR Studio 🧪 10.1 Acceptance Criteria

IIBA BABOK® Guide v3 — Technique 10.43 & 10.39

Stakeholder Mapping & Personas Studio — Executive Guide

Map and calibrate influence, sentiment, and accountability across your initiative. Combine the classic Mendelow 2×2 Power vs. Interest heuristic with 360° empathetic User Personas (Jobs-To-Be-Done, pain points, digital fluency) and rigorous single-accountability RACI governance.

🎯 Core Methodology Principles

Mendelow 2×2 Heuristic Grid: Segment stakeholders by Power (influence/budget authority) and Interest (direct impact/stakes) into four distinct governance treatments: Manage Closely, Keep Satisfied, Keep Informed, and Monitor.
Stakeholder Sentiment & Alignment Radar: Categorize individuals into Champions, Supporters, Neutrals, and Skeptics to proactively defuse organizational friction and tailor change management cadences.
Empathetic User Personas 360°: Anchor user stories in living archetypes equipped with demographic context, digital fluency ratings (1–5 ★), core Jobs-To-Be-Done (JTBD), and daily emotional friction points.
Single Accountability RACI Rule: A deliverable or decision with zero "A"s has no ownership; one with multiple "A"s breeds confusion. Every row must have strictly one Accountable (A) leader.

🔑 Operational Delivery Standards

Primary Inputs: Enterprise org charts, project charters, customer discovery interviews, workflow observation notes.
Primary Deliverables: Mendelow Power/Interest Grid, Stakeholder Engagement Matrix, Persona Dossiers, RACI Governance Blueprint.
RACI Accountability: Lead BA (Accountable for stakeholder elicitation & persona profiling), Project Sponsor (Accountable for executive alignment & RACI sign-off), Product Owner (Consulted on user needs & backlog slicing).
Cross-Tool Synergy: Feed Persona archetypes directly into the 10.48 User Story Slicer to ensure user stories reflect verified real-world operator needs.

⚠️ Critical Pitfalls to Avoid: (1) Executive Myopia: Prioritizing top-tier sponsors while neglecting frontline daily operators who dictate actual adoption success. (2) The Multiple "A" Trap: Assigning accountability to multiple committees or managers, ensuring nobody feels truly responsible. (3) Static Shelfware Personas: Inventing purely decorative personas disconnected from actual backlogs, estimation, or acceptance criteria.

Portfolio Governance Metrics • Organizational Alignment

Stakeholder Health & Alignment Radar

Real-time balance of influence quadrants, champion-to-skeptic alignment ratios, persona coverage, and RACI single-accountability integrity.

Total Stakeholders

10

4 Internal • 6 External / Exec

Key Players (Manage Closely)

30%

3 High Power • High Interest

Alignment Sentiment

85%

4 Champions • 3 Supporters • 1 Skeptic

Validated Personas

4

2 Internal Staff • 2 End Clients

RACI Governance Integrity

100%

6 Deliverables • 0 Conflicting A's

BABOK 10.43 Heuristic Analysis

Mendelow Power vs. Interest Strategic Matrix

🎯 Manage Closely High Power (≥6) • High Interest (≥6)

3

🛡️ Keep Satisfied High Power (≥6) • Low Interest (<6)

3

📢 Keep Informed Low Power (<6) • High Interest (≥6)

2

👁️ Monitor (Minimal Effort) Low Power (<6) • Low Interest (<6)

2

Empathy & Human-Centered Design

User Personas 360° Studio

BABOK 10.39 Roles & Permissions

Interactive RACI Governance Matrix

R = Responsible (does work) A = Accountable (approves / owns — strictly 1 per task) C = Consulted (two-way feedback) I = Informed (kept updated) (Click any cell badge below to cycle roles)

Deliverable / Decision	Product Owner	Lead BA	Tech Lead	Business Sponsor	End Users	Ownership Check

Quick Intake Engine

Add New Stakeholder or Persona

Stakeholder Name

Title / Role

Department / Organization

Power / Influence (1–10)

Interest / Stake (1–10)

Initial Sentiment

Stakeholder Sphere

Primary Concern or Sticking Point

Engagement Strategy & Cadence

Multi-Platform Governance Export

Stakeholder & RACI Export Engine

Markdown Stakeholder Engagement Plan markdown

Elicitation & Collaboration • BABOK Chapter 4

Elicitation Technique Diagnostic Selector

Select your real-world project constraints to identify the optimal BABOK elicitation technique, prep checklists, and facilitation traps to avoid.

Context Diagnostic

Your Project Scenario

Select the situation that best matches your current discovery hurdle:

💥 Conflicting Stakeholder Opinions Different department heads have competing expectations and irreconcilable priorities.

🏛️ Poorly Documented Legacy System No specifications exist, original authors left, but business logic must be replicated.

🌐 Distributed / Time-Constrained Team Stakeholders across timezones with under 30 minutes of synchronous availability.

🌫️ Brand-New Innovation / Unclear Needs Users cannot articulate what they want because the concept does not exist yet.

⚖️ High Regulatory & Compliance Scrutiny Strict audit requirements, legal constraints, zero tolerance for missing edge cases.

BABOK Recommendation

Collaborative Workshop & Decision Analysis

Facilitate a structured 90-minute workshop with an impartial prioritization rubric (BABOK 10.14 & 10.33) rather than 1-on-1 interviews.

Actionable Business Analyst Toolbox

Logical Relationships Between BABOK® Techniques

1. Browse Visually or in Inventory

2. Open Desired Actionable App

3. Craft & Connect Your Content

Complete Inventory of all 50 BABOK Techniques

Actionable Technique Workbench

Standard Guidelines

Core Execution Steps

Key Pitfalls to Avoid

Actionable Canvas & Output

Strategyzer Business Model Canvas (9 Blocks)

1 Key Partners

2 Key Activities

3 Value Propositions

4 Customer Relationships

5 Customer Segments

6 Key Resources

7 Channels

8 Cost Structure

9 Revenue Streams

Problem Framing & 5-Whys Diagnostic

SCQA Problem Charter

The 5-Whys Root Cause Chain

Stakeholder Matrix & RACI Governance

Power vs. Interest Grid

Interactive RACI Governance Matrix

Acceptance and Evaluation Criteria — Executive Guide

🎯 What this Actionable App is Used For

🔑 Key Methodological Information

Interactive Acceptance Criteria & Gherkin Studio

User Story Context

Gherkin Acceptance Scenarios

INVEST Quality Check

Export Deliverable

User Stories & INVEST Slicing — Executive Guide

🎯 What this Actionable App is Used For

🔑 Key Methodological Information

Interactive User Story Studio & SPIDR Slicing Engine

User Story Formulation

SPIDR Story Slicing Strategy

🔗 Attach Acceptance Criteria (BABOK 10.1)

INVEST Quality Check

Delivery Checklist

Export Deliverable

Requirements Prioritization & WSJF — Executive Guide

🎯 What this Actionable App is Used For

🔑 Key Methodological Information

Interactive Prioritization Studio & Capacity Guard

Must Have Capacity: 0% of Total Backlog

Non-Negotiable

High Impact

Desirable / Nice to Have

Out of Scope (for now)

Weighted Shortest Job First (WSJF) Ranking Table

Value vs. Complexity 2×2 Portfolio Grid

🚀 Quick Wins

🏛️ Strategic Bets

⏳ Low Hanging / Fill-Ins

⚠️ Time Sinks

Export Prioritized Backlog

Backlog Management & Progressive Refinement — Executive Guide

🎯 Core Methodology Principles

🔑 Operational Delivery Standards

Backlog Health & Velocity Radar

Add Item to Backlog

Ordered Work Items & Quality Gate Audits

Multi-Platform Backlog Export Engine

Non-Functional Requirements Analysis (NFR Studio) — Executive Guide

🎯 Core Methodology Principles

🔑 Operational Delivery Standards

NFR Health & Architectural Radar

Define New Non-Functional Requirement

Active NFR Quality Gates

Multi-Platform NFR & DoD Export Engine

Estimation Engine (PERT 3-Point & SAFe® Fibonacci) — Executive Guide

🎯 Core Methodology Principles

🔑 Operational Delivery Standards

Estimation Health & Statistical Radar

Calibrate New Work Item Estimate