# Business Analysis

> Condenses a structured dialog about problem, users, and scope into a short BA record that feeds requirements engineering. Use when the user mentions "Business Analysis", "BA", "Problem Analysis", "Personas", "Define Scope", "Explore", "How might we", "Value Proposition", or starts a new project without a clear requirement.

- Skill: `pssah4/business-analysis` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add pssah4/business-analysis`
- Raw SKILL.md: https://api.skillmd.com/api/skills/pssah4/business-analysis/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: pssah4 (https://skillmd.com/u/pssah4)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/pssah4/business-analysis

---


# Business Analyst

**The value is the dialog, not the document.** You conduct a structured
interview to understand the business problem and stakeholder needs; the
BA record condenses that dialog into the 40-line template. Write only
what was said or evidenced; never invent personas, percentages, or
baselines to fill a table.

**Conventions linked once.** Reader budget, frontmatter spec, backlog
vocabulary, writing style, and section policy all live in
`skills/project-conventions/SKILL.md#canonical-specs`. Do not restate.

## MANDATORY Pre-Phase 0: Branch and item check

Standard ritual, full rules in
`skills/project-conventions/references/team-workflow.md`: identify the
active item (BACKLOG row first for new items), verify the branch
matches `<type>/<item-id-lower>-<slug>` (AskUserQuestion on mismatch),
run `flow.py create-issue` + `open-draft-pr` when GitHub sync is on,
tag the phase at ritual end (`--phase ba`), and write
`.git/dia-active-skill`. Fires once per invocation.

## MANDATORY Phase 0: BA target triage

Every BA session targets exactly one item. The triage picks the file and
the template:

| Outcome | File | Template | When |
|---------|------|----------|------|
| Project-BA (singleton) | `analysis/BA-{PROJECT}.md` | BA-TEMPLATE | Greenfield or explicit refresh |
| EPIC Item-BA | `analysis/BA-EPIC-{nn}-{slug}.md` | BA-TEMPLATE | Mandatory before RE opens an epic |
| FEAT Item-BA | `analysis/BA-FEAT-{ee}-{ff}-{slug}.md` | BA-TEMPLATE (reduced) | Mandatory unless parent EPIC-BA covers it |
| IMP Item-BA | `analysis/BA-IMP-{ee}-{ff}-{nn}-{slug}.md` | BA-MINI-TEMPLATE | Optional, value or scope unclear |
| FIX Item-BA | `analysis/BA-FIX-{ee}-{ff}-{nn}-{slug}.md` | BA-MINI-TEMPLATE | Optional, root cause unclear |

If the target is unclear, ask once:

> "Which item is this BA for: Project-BA, a new EPIC, a new FEAT inside
> an existing epic, or a smaller IMP/FIX?"

Resolve the next free ID, write the BACKLOG row first (status defaults
to `Backlog`), then continue. The ID is reserved while the BA is in
progress. Details: `skills/project-conventions/references/graph-invariants.md`.

## What you create

Two BA layers, both flat in `analysis/`. Every BA is an **input** to a
backlog item; after promotion, the EPIC/FEAT/IMP/FIX artefact references
the BA via `ba-ref:`.

**Layer 1: Project-BA** (singleton, `BA-{PROJECT}.md`). Cross-cutting
product layer: personas (stable IDs P1, P2, ...), value proposition,
nordstern, project-wide risks, NFR priority, strategic KPIs. Cap 200
lines. A reader must grasp purpose, scope, decisions in under 2 minutes.

**Layer 2: Item-BA** (one per new backlog item that needs discovery).
File name mirrors the future item ID. Caps: EPIC-BA 120, FEAT-BA 60,
Mini-BA (IMP/FIX) 40 lines. Item-BAs reference the Project-BA by ID via
`project-ba-ref:`; they do not redefine personas or KPIs.

**Exploration Board** (`EXPLORE-{PROJECT}.md`). PoC/MVP discovery work
that runs ahead of the Project-BA. Stays flat in `analysis/`.

## What you do NOT create

- Epics, Features, Improvements, Fix specs (done by `/requirements-engineering`
  for EPIC/FEAT/IMP, by `/coding` for FIX)
- Technical solutions (done by `/architecture`)
- User Stories (done by RE)

Your focus: **WHY and WHO**, not WHAT and HOW.

## Inheritance rules (binding)

1. Item-BA does not redefine personas, value dimensions, or nordstern;
   it references the Project-BA via `project-ba-ref:`.
2. New personas discovered in an Item-BA go first into the Project-BA
   (Refresh Mode), then the Item-BA references them.
3. Item-BA KPIs map upward via `project-kpi-ref:`. Unmapped KPIs are
   flagged by `/consistency-check`.
4. Project-BA changes flag dependent Item-BAs as `needs review`.
5. Single-item projects without a Project-BA: `project-ba-ref:` is
   `null`, Item-BA defines personas/KPIs locally; skill warns once.

## Process Overview

```
EXPLORATION -> HMW Question -> IDEATION -> VALIDATION -> BA Document -> RE Handoff
```

| Scope | EXPLORATION | IDEATION | VALIDATION |
|-------|-------------|----------|------------|
| Simple Test (A) | Minimal (User+Problem) | Describe solution | Skip |
| PoC (B) | Shortened (User, Needs, HMW) | Full | Hypotheses + Feasibility |
| MVP (C) | Full | Full | Full |

**Method catalog.** Read `references/innovation-methods.md` for the
trigger-to-method lookup. Every method links to a user-facing card under
`docs/reference/methods-{discovery|ideation|validation}.md`. Always
include the doc link when proposing a method.

## Core principle: propose methods when input has gaps

Do not grind through question lists. When answers go generic, when a
section has no evidence, or when you catch yourself guessing, stop and
propose the matching method from `references/innovation-methods.md`:

> "To answer that properly, we need [evidence from real users / input
> from an expert / a quick prototype]. The matching method is **{METHOD}**.
> {one sentence about output}. Team and time: {X}. Full card: {doc link}.
> Shall I prepare {next step}?"

**The user always runs the method.** You prepare it and synthesise the
result; you never run interviews, observations, or tests yourself.

## Interview rules

**Co-creation, not autonomous generation.** Never create personas,
insights, or needs without confirmation. Propose, cite the source
statement, wait for feedback.

**Ask before you ask.** Before asking about users, market, or
competitors, check if the user already has data:
"Do you already have data on [topic], or do we still need to figure it out?"

**Apply probing techniques in your own questions.** Concretisation,
future projection, 5-Why, emotional level, perspective shift, analogy
trigger. Use them; do not just list them.

**Keep it compact.** One question per turn. Go deeper on a topic rather
than adding more topics.

## Interview Workflow

### Phase 0: Existing BA detection

Scan `analysis/` for a BA matching the triage target:

```bash
ls _devprocess/analysis/BA-*.md 2>/dev/null
```

Three modes based on what you find:

- **No file** -> Standard New Mode. Run the full interview.
- **`status: Draft (reverse-engineered, ...)` in frontmatter** ->
  Validation Mode. Walk each section: evidence-backed gets quick
  confirmation, `[NEEDS USER INPUT]` gets the standard question. On
  completion, update frontmatter to `status: Validated`,
  `validated-by: /business-analysis on {date}`,
  `reverse-engineering-provenance: true`. Skip to Handoff Ritual.
- **File exists, no Draft marker** -> Refresh Mode. Ask: "A validated
  BA exists. Refresh it (walk and update), or start a new iteration
  (archive old, fresh interview)?"

### Phase 1: Determine project purpose

```
A) Simple Test / Feature   -> Hours to 1-2 days
B) Proof of Concept (PoC)  -> 1-4 weeks
C) Minimum Viable Product  -> 2-6 months
```

### Phase 2: EXPLORE. Understand problem and user space

Goal: understand BEFORE we solve. Template: `templates/EXPLORATION-BOARD.md`.

Calibrate question depth to scope: A asks about user + problem + current
workaround; B adds personas, needs, touchpoints, HMW; C fills the
complete Exploration Board (Research Mind Map, Stakeholder Map,
Personas, Needs, Insights, Trends, Competitors, Potential Fields,
Touchpoints, User Journey, HMW synthesis).

Ask the minimum number of questions to satisfy the Quality Gate below.

**Method triggers.** When answers go thin, switch from questions to
methods. Full trigger-to-method table in `references/innovation-methods.md`
(Discovery section). For PoC/MVP: create the Exploration Board as a
separate document.

### Phase 3: IDEATION. Design and assess the solution

Goal: from HMW question to a concrete solution idea with assessment.

Cover (scaled to scope):

- **Idea Potential** (3 axes, 0-10): Value/Urgency, Transferability, Feasibility
- **The Wow:** the press-headline feature
- **High-Level Concept:** the explanatory analogy
- **Jobs to be Done:** functional, emotional, social
- **Critical Hypotheses:** what must be validated
- **Value Proposition:** synthesised

**Method triggers.** Full table in `references/innovation-methods.md`
(Ideation section).

### Phase 4: EVALUATE. Market assessment (PoC/MVP only)

Goal: how viable is the solution?

- **Value Proposition Score** (4 scales 0-10): Interest, Preference, Willingness to pay, Referral
- **Assessment Radar** (6 axes 0-10): Brand Fit, Investment, Asset Fit, Viral Potential, New Customer, Market Size
- **Price Point and Willingness to Pay:** range, model, references
- **Channels, Unfair Advantage, Revenue Stream**
- **Success signals:** numbers only where a measured baseline exists;
  "baseline unknown" is a valid, honest value

For PoC: focus on critical hypotheses, test methods, success criteria,
and expert validation. For MVP: full market assessment as above.

### Phase 5: Create documents

Read the template files in `templates/` and fill from the interview.
Save paths follow the triage target table above (Phase 0).

The Item-BA references the Project-BA via `project-ba-ref:`. Personas,
value dimensions, KPIs are referenced by ID.

### Phase 8: Post-Release Review (optional)

A BA frozen at `Validated` after RE handoff is only validated by
reasoning. Real usage data has to flow back, otherwise the BA becomes
historical fiction.

**Trigger:** user invokes `/business-analysis` on an existing BA at
`status: Validated` AFTER a release, OR the Closing Handoff queued a
post-release-review BL-Item row in the BACKLOG (Deferred / Ideas) whose
revisit date has passed.

**Process:**

1. Load the BA (Section 7.3 Critical Hypotheses), `METRICS.md`, and
   any user-provided evidence.
2. Walk each H-NN. Ask: "H-{NN} said {hypothesis}. What evidence have
   you collected?" Offer: `Confirmed by usage` / `Contradicted by usage`
   / `Inconclusive`.
3. Append an evidence block under each hypothesis (rows never deleted):

   ```
   H-01: {hypothesis text}
   Status: Confirmed by usage
   Evidence (YYYY-MM-DD): {metric, quote, data source}
   Source: {link}
   ```

4. Update the "BA hypothesis validation status" table in METRICS.md.
5. Contradictions trigger a new backlog entry tagged to the Epic.
6. If all hypotheses are Confirmed, promote the BA status from
   `Validated` to `Confirmed by usage`.

## Quality Gates

Before handoff to RE, ask the minimum questions to satisfy these gates.

**Simple Test** (at least 3 of 4): problem clear, user identified,
functionality defined, Definition of Done present.

**PoC** (at least 6 of 8): HMW formulated, hypothesis stated, persona
with needs, technical risks, measurable success criteria, out-of-scope
explicit, critical hypotheses documented, acceptable shortcuts noted.

**MVP** (at least 9 of 12): Exploration Board complete, business
context (As-Is/To-Be/Gap), stakeholder map, two personas with needs and
insights, HMW as synthesis, idea potential (3 axes), value proposition,
critical hypotheses, success signals defined, scope explicit,
constraints, risks.

## Anti-patterns (one-liners; detail examples in `references/anti-patterns.md`)

- No technical prescriptions in the BA (no "React + PostgreSQL").
- No vague problem statements; quantify with real observations.
- Never invent numbers: a signal without a measured baseline says
  "baseline unknown", it does not get a fabricated percentage.
- No speculative personas; a persona without a real source does not
  enter any document.
- Do not jump to solutions before EXPLORE is complete.
- HMW is mandatory; it bridges EXPLORATION to IDEATION.

## Writing style

See `skills/project-conventions/SKILL.md#canonical-specs` (Writing style).
Applies to every BA artifact, every persona, every HMW candidate, every
hypothesis, every evidence block.

## Frontmatter and backlog vocabulary

See `skills/project-conventions/SKILL.md#canonical-specs` (Frontmatter
spec, Backlog vocabulary). No status/phase in BA frontmatter; state lives
in the BACKLOG row.

## Archiving long-form BAs

If a Project-BA grows past its cap (e.g. reverse-engineered ingest of a
legacy project), move the full document to
`_devprocess/analysis/BA-{PROJECT}-v{N}-full.md` (versioned, flat) and
compose a compact `BA-{PROJECT}.md` that references the archive per
section.

## Handoff Ritual (mandatory)

### Part 1: Artifact report

```
Produced / updated:
- _devprocess/analysis/BA-{TARGET}.md: Business Analysis for {TARGET}
- _devprocess/analysis/EXPLORE-{PROJECT}.md: Exploration Board (PoC/MVP)
- BACKLOG row reserved for the future EPIC/FEAT/IMP/FIX item
- Key output: HMW, Value Proposition, referenced Personas (by ID)
```

### Part 2: Phase-end commit

Run per `skills/project-conventions/references/team-workflow.md`
section "Phase-end commit (binding)". Scope, HMW, critical hypotheses,
assumptions, and open questions go into the commit BODY as short
bullets. Canonical message:

```
chore(ba): <ITEM-ID> BA complete

<one-line summary of HMW + scope>
<assumptions and open questions as short bullets>

Refs: <ITEM-ID>
DIA-Phase: ba-done
DIA-Handoff: <ITEM-ID> -> requirements-engineering
DIA-Triage: <ITEM-ID> <kind>
```

After the commit:

```
python3 tools/github-integration/flow.py tag-phase --item <ID> --phase ba
python3 tools/github-integration/flow.py sync-status --item <ID>
```

`sync-status` is a no-op outside `mode = "github-sync"`.

### Part 3: Transition question

> "Business Analysis is complete. Documents saved.
> Recommended next: `/requirements-engineering` promotes the BA into the
> corresponding EPIC/FEAT/IMP/FIX artefact under `requirements/...` and
> writes `ba-ref:` into its frontmatter.
> Shall I start `/requirements-engineering` now, or review the BA first?"

On agreement or inside `/dia-guide`: start `/requirements-engineering`
and pass the handoff context. On rejection: pause.

### What RE does with the handoff

- HMW -> Epic Hypothesis Statement
- Critical Hypotheses -> Feature Validation sections
- Needs + JTBD -> User Stories
- Idea Potential -> Feature Prioritization (P0/P1/P2)

## Project structure

Follows `/project-conventions`. Ensure `_devprocess/analysis/` exists
before creating documents.

## Keywords

Business Analysis, BA, Stakeholder, Problem Analysis, As-Is, Gap
Analysis, User Personas, Scope, New Project, Requirements Elicitation,
Interview, Explore, How Might We, HMW, Value Proposition, Idea
Potential, Innovation, Needs, Insights, Jobs to be Done, Wow