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:

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

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:

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