← Default view
Expedition · 103 citations · 7 angles

The 2026 AI Playbook
for BA · FA · PO

Role-by-role guide to adopting AI across the full requirements lifecycle — from discovery through backlog, specs, and stakeholder reporting.

Business Analyst Functional Analyst Product Owner All Roles
10–15
hrs/week AI can reclaim
more domain concepts w/ structured input
30–50%
less report creation time
67%
documentation time saved
Core Finding

AI output quality is bounded by input structure. Attaching EventStorming board artifacts to an LLM prompt produced 3× more domain concepts than unstructured prose. EARS "shall" statements produce requirements that AI coding agents can parse as executable contracts. The shared failure mode across every task type is treating AI as a shortcut that works on messy inputs.

By Role — Primary AI Workflows
Business Analyst
High-leverage AI tasks
  • Attach EventStorming / Domain Storytelling artifacts to LLM prompts for richer elicitation
  • Generate structured interview guides and stakeholder question banks
  • Convert meeting transcripts → action items pushed to Jira/ADO
  • Draft EARS-formatted requirements from feature briefs
  • Produce audience-tailored executive summaries from technical outputs
Functional Analyst
High-leverage AI tasks
  • Author specs for two audiences simultaneously: human reviewers and AI coding agents
  • Validate existing requirements against EARS notation with Inflectra.ai or Copilot4DevOps
  • Generate BDD Gherkin scenarios as a coverage scaffold (then add edge cases manually)
  • Detect duplicate and contradicting requirements across large backlogs
  • Produce traceability matrices from spec to test case automatically
Product Owner
High-leverage AI tasks
  • Score backlog items with WSJF / RICE / Kano using structured prompts (use AI scores for ranking, not absolute estimates)
  • Synthesise customer feedback themes from multiple unstructured sources
  • Auto-generate Sprint Review narrative from Jira/ADO data
  • Translate roadmap into audience tiers: exec summary vs. engineering detail
  • Assign GitHub Copilot to backlog issues with well-written acceptance criteria
7 Chapters — Deep Dives
Structure-First Discovery — The Multiplier
EventStorming and Domain Storytelling as LLM context
more domain concepts in LLM output

EventStorming artifacts as LLM input

A prototype using EventStorming board photos as LLM context produced 9 schemas vs 3 from unstructured prose — same model, same prompt structure, better input. Codecentric case study

The implication: EventStorming, Domain Storytelling, and EARS aren't "extra process." They're the precision instruments that determine the ceiling of every downstream AI output.

Quantified Time Savings (Current AI Tooling)
~10 hrs
saved/week
Backlog refinement overhead — consumes ~20% of a PO's workweek. AI grooming, scoring, and deduplication reclaims the bulk.
Source: Agile Leadership Day India
200 hrs/yr
< 30 min/week
Status reporting. 3–5 hrs/week writing documents stakeholders skim in under 2 minutes. AI pulls from Jira/ADO/GitHub and generates narrative on schedule.
Source: Taskade
6 hrs prep
45 min
Weekly reporting prep for BAs. Jasper + Beautiful.ai + Power BI natural-language Q&A compress the cycle and produce audience-tailored deliverables.
Source: Sync Skills
8–12 hrs
67% faster
BRD / PRD writing. ChatGPT and Claude generate structured drafts from domain briefs. Reframe as review-and-refine, not blank-page authoring.
Source: Klariti
The Two-Audience Problem — Specs in 2026

Human Reader Needs

  • Narrative context explaining the business motivation
  • Rationale for trade-offs and non-obvious constraints
  • Clear ownership and approval chains (RACI)
  • Plain-language success criteria stakeholders can sign off on
  • Diagrams and examples for shared understanding

AI Coding Agent Needs

  • EARS "shall" statements: unambiguous, single-behaviour
  • Explicit edge cases and negative scenarios in GWT format
  • Structured headings + bullet points (models parse better than prose)
  • Quantified non-functionals: "< 200 ms", "≥ 99.9% uptime"
  • Agent-optimised format: CLAUDE.md, .cursorrules, or Kiro spec layer
The hardest discipline shift in this playbook: optimising a spec for one audience degrades the other. BAs and FAs who write only for human readability will erode their engineering team's AI-assisted development velocity. This dual-audience habit also has the longest leverage — it propagates value from discovery all the way through implementation. ChatPRD on PRDs for AI codegen · Kiro (AWS) forces spec-first
Tool Spotlight — Spec-Driven IDEs

Kiro — AWS's Answer to Structureless Agentic Coding

Launched internationally May 2026. Kiro operates at the specification layer first — before writing a single line of code, it forces formalisation of intent into a structured spec using EARS notation with formal logic to catch contradictions. Represents the "spec-as-source" maturity level where humans edit only specs, never code directly.

Comparable tools at different maturity levels: Jira Rovo (spec-anchored, integrated with existing workflow), Copilot4DevOps (generates FRDs natively in Azure DevOps).

Kiro — AWS agentic IDE
Prompt Templates — Copy and Adapt
Requirements Elicitation Interview Guide BA
Role: Senior Business Analyst preparing for a stakeholder discovery session.

Context: [Project name] — a [domain] system being built for [user group].
The primary stakeholder is [role, e.g. Head of Operations].

Task: Generate a structured interview guide with:
  • 5 opening questions to surface the business problem (not the solution)
  • 4 questions to uncover tacit knowledge and undocumented workarounds
  • 3 questions to identify constraints (regulatory, technical, organisational)
  • 2 closing questions to confirm understanding and agree next steps

Constraints: No leading questions. Avoid solution-first framing.
Each question should be open-ended and invite narrative.

Output format: Numbered list grouped by section, with a one-line "why this question" note per item.
EARS Requirement Drafting FA
Role: Functional Analyst writing machine-parseable requirements.

Context: Feature: [feature description in plain language]
System: [system name and brief description]
Actors: [list the actors involved]

Task: Convert the above into EARS-formatted requirements using the correct
template for each type:
  • Ubiquitous:  The [system] shall [action]
  • Event-driven: When [trigger], the [system] shall [response]
  • State-driven: While [state], the [system] shall [action]
  • Optional:     Where [feature] is included, the [system] shall [action]

Constraints: Each statement covers exactly one behaviour.
No compound "and/or" in a single requirement.
Quantify non-functionals (e.g. "within 500 ms", "≥ 99.5% uptime").

Output format: Table with columns: ID | EARS Type | Requirement | Rationale
Backlog Scoring — WSJF + Kano PO
Role: Product Owner prioritising the next sprint's candidates.

Context: Product: [product name]. Current sprint goal: [goal].
Stories for scoring: [paste story titles and one-line descriptions]

Task:
  1. Score each story on WSJF components (1–10 scale):
     • User/Business Value, Time Criticality, Risk Reduction, Job Size
     WSJF = (Value + Time + Risk) / Size
  2. Classify each story by Kano category:
     • Must-Have / Performance / Excitement / Indifferent
  3. Flag any story where Job Size > 5 as a split candidate.

Important: Use WSJF scores for relative ranking ONLY.
Job size estimates from AI run 10–20× too high for absolute planning.

Output format: Ranked table: Story | Value | Time | Risk | Size | WSJF | Kano | Split?
Sprint Status Report — Stakeholder Tier Translation All Roles
Role: BA / PO producing a Sprint Review summary.

Context:
Sprint: [sprint number/name]. Goal: [sprint goal]
Completed: [list stories done]
Incomplete: [list stories carried over, with reason]
Impediments: [list blockers encountered]
Metrics: Velocity [N] pts. Burn-up: [status]

Task: Produce THREE versions of the status report:
  A. Executive (≤ 5 bullet points) — business impact language, no jargon
  B. Steering / Sponsor (1 page) — decisions needed, risks, timeline impact
  C. Team retrospective input — honest, blameless, focused on process

Output format: Three labelled sections. Version A must lead with the sprint goal
outcome (achieved / partial / missed) in the first sentence.
Consistent Risk Signals Across All 7 Angles
Syntactically correct, semantically wrong
AI generates EARS-formatted requirements that look precise but drop real constraints. It writes "so that" clauses that sound plausible but don't capture actual stakeholder motivation. Affects every task type.
AI drafts, human verifies with domain knowledge. Build review into the workflow, not as an afterthought.
WSJF / RICE estimate inflation
AI calculates job size estimates 10–20× too high for engineering work. Using AI-generated WSJF scores for absolute capacity planning will break sprint commitments.
Use AI scores for relative ranking only. Calibrate job size estimates against your team's historical velocity data. Source
Integration gap — summaries stranded in silos
Meeting summaries that don't push action items to a project board are never acted on. Standalone LLM sessions that don't connect to Jira, Confluence, or ADO capture a fraction of the value.
Integration is the unlock. Choose tools that write back to your system of record automatically. Meeting AI comparison
Gherkin/BDD coverage scaffold mistaken for complete coverage
AI generates valid Gherkin in under a minute but misses actual business intent and skips non-functional requirements (performance, security, accessibility).
Treat AI-generated BDD scenarios as a first-pass coverage scaffold. Add edge cases, error paths, and NFR scenarios manually.
Governance gap — verification ownership undefined
What remains underexplored: who owns the verification step that catches AI's wrong-intent outputs? Sign-off, governance, and organisational accountability are the least-documented parts of the playbook (3–7 citations).
Assign explicit ownership of AI output review in your Definition of Ready. Don't leave it to "the team."
Prompt-first trap — 30% efficiency ceiling
Organisations that adopt AI via raw prompting without investing in structured discovery (EventStorming, EARS) capture ~30% of available efficiency gain — enough to notice, not enough to transform the workflow.
Start with prompt wins for quick ROI. Then invest in structured methods to multiply the gains across the entire lifecycle.
Adoption Sequencing — The Tension
Quick-Win Path (Prompt-First)
Start with raw LLM prompting on existing workflows. Zero integration cost, immediate results within days.
~30% of available efficiency gain
  • 1. Use ChatGPT/Claude for meeting summaries and report drafts
  • 2. Prompt-engineer story splitting and backlog scoring
  • 3. Generate acceptance criteria drafts for human review
  • 4. Add integration to Jira/ADO when patterns stabilise
vs.
Structure-First Path (Methods-Led)
Invest in EventStorming, Domain Storytelling, and EARS notation as the multiplier layer before optimising prompts.
~100% of available efficiency gain
  • 1. Adopt EventStorming for domain discovery (2–4 week ramp)
  • 2. Standardise EARS notation for requirements writing
  • 3. Build spec dual-audience writing habit (human + AI agent)
  • 4. Layer AI tools on top of structured artifacts for 3× multiplier
The recommendations pull in opposite directions: quick wins favour prompt-first; systemic ROI favours structure-first. The pragmatic path: capture the 30% win quickly to build internal credibility, then use that credibility to invest in the structured methods that unlock the remaining 70%. Don't let prompt-first become the permanent ceiling.
Key Tools by Category
Open Question — What This Expedition Doesn't Answer
Given that structured discovery methods multiply AI ROI across the full lifecycle but require organisational buy-in, what is the minimum viable structure a solo BA or PO can introduce unilaterally — before the rest of the organisation is on board — to still capture a meaningful downstream AI multiplier?