How Business Analysts Can Use AI for Strategic Advantage.

AI Simulation Modelling.

This article builds on Nate B Jones' video "We're Getting AI Agents Backwards - Simulation Wins" applying his insights to business analysis.

We're Solving the Wrong Problem

Whilst everyone obsesses over AI agents that write emails and reports, we're missing the  opportunity hiding in plain sight.

The current approach treats AI as an executor: LLMs + tools + guidance, designed to automate tasks. This provides linear improvements—turning that 10-minute email into a zero-minute email. 

However, companies like Renault (60% reduction in vehicle development time) and BMW (overnight factory optimisation) have discovered that AI's real value isn't in what it can do for you—it's in what it can show you.

AI agents as reality simulators.

Instead of LLMs + tools + guidance, add one crucial element: a simulated environment. This transforms AI from a task executor into a strategic engine that can model different futures before you commit.

We’re Already Modelling

As BA’s, we’re already modelling reality—every requirements document and stakeholder analysis attempts to simulate how users and systems behave. The difference is we’re doing it manually, once, with limited iteration cycles. AI simulation lets you run multiple variations in the time it used to take to do one. Here's where the opportunities lie:

  1. Requirements Validation Simulation: Test how different user personas would interact with proposed features across “happy paths”, edge cases, and error conditions before finalising requirements

  2. Change Impact Analysis: Model how proposed changes ripple across departments and systems simultaneously, revealing hidden dependencies before they derail your project

  3. Sprint Planning Simulation: Model team estimation patterns, capacity constraints, and story dependencies before the actual ceremony

  4. Risk Scenario Planning: Explore how different risk events would impact current projects, moving from reactive firefighting to proactive planning

But where should you start? 

Sprint Planning

Sprint planning offers an ideal entry point as it's essentially a collaborative requirements validation session. What if you could run sprint planning discussions multiple times before the actual meeting?

We have the data: velocity trends, estimation accuracy patterns, common blockers, team capacity variations. Feed this into an AI simulation with your proposed backlog to model scenarios:

  • What happens if Sarah's API integration overruns?

  • How does removing Story A affect the dependency chain?

  • Which story combination gives the best sprint success probability?

The simulation reveals that Story A always triggers lengthy discussions, or that combining Stories B and C creates hidden dependencies. Armed with these insights, you refine stories beforehand and enter the real ceremony with greater confidence.

How to Build Your Sprint Planning Simulation

The approach works across different AI platforms - you're not locked into any specific vendor. Choose the method that fits your existing tools and preferences.

Option 1: Claude Projects Approach Set up a dedicated Claude project called "Sprint Planning Simulation" and populate it with:

  • Team personas: Detailed profiles of each team member including their estimation tendencies, technical strengths, and typical concerns

  • Historical data: Past sprint velocities, common blockers, estimation accuracy by story type

  • Project context: Current technical constraints, dependencies, and business priorities

Upload meeting transcripts from previous sprint planning sessions and retrospectives. Claude will learn your team's patterns and provide increasingly accurate simulations.

Option 2: Google Gemini with Custom Gems Create specialised Gems for different aspects:

  • "Sprint Estimator" Gem: Trained on your team's estimation patterns and velocity data

  • "Dependency Tracker" Gem: Focused on identifying story relationships and technical constraints

  • "Risk Assessor" Gem: Specialised in surfacing potential blockers based on past sprint issues

Each Gem becomes an expert in one simulation aspect, process them sequentially for comprehensive sprint planning analysis.

Option 3: Structured Prompting Approach If you prefer not to set up projects or gems, use a prompt template.

PROMPT TEMPLATE EXAMPLE

You are simulating sprint planning for [Team Name]. 

TEAM CONTEXT:

- [Team member profiles with estimation tendencies]

- [Recent velocity: X story points per sprint]

- [Known constraints: API dependencies, testing bottlenecks, etc.]

PROPOSED STORIES:

[List your sprint backlog with story points and acceptance criteria]

HISTORICAL PATTERNS:

[Summary of what typically causes issues in your sprints]

OUTPUT REQUIRED:

Please provide a structured sprint planning simulation report including:

1. TEAM MEMBER CONCERNS

   - What specific questions would each team member raise?

   - Which stories would trigger the most discussion?

   - What technical risks would be highlighted?

2. DEPENDENCY ANALYSIS

   - What story dependencies might be missed in initial planning?

   - Which external dependencies could impact delivery?

   - What sequence risks exist?

3. ESTIMATION CHALLENGES

   - Which stories are likely under/over-estimated and why?

   - What assumptions are being made that should be validated?

   - Where would the team need more information?

4. REALISTIC SPRINT COMMITMENT

   - What's the actual deliverable capacity considering team patterns?

   - Which stories should be prioritised/deprioritised?

   - What's the confidence level for sprint success?

5. PRE-PLANNING ACTIONS

   - What story refinements are needed before the real planning session?

   - Which stakeholders need to be consulted?

   - What technical investigations should happen first?

Example Input 

Let's say you're planning Sprint 12 with these proposed stories:

  • User registration API (8 points)

  • Payment integration (13 points)

  • Mobile responsiveness fixes (5 points)

  • Database migration (8 points)

Feed this into your simulation with team context:

  • Sarah (Backend): Cautious about API integrations, always asks about error handling

  • Mike (Frontend): Spots UI edge cases, concerned about mobile testing time

  • Team velocity: Averaging 28 points per sprint

  • Recent blocker: Payment provider API changes caused 3-day delay in Sprint 9

Simulation Output

  • "Sarah will likely flag that payment integration depends on the registration API being stable. 

  • Mike will point out that mobile fixes need extensive device testing. 

  • Given the Sprint 9 payment API issues, the team may be conservative on the payment story estimate. 

  • Realistic commitment: 26 points, dropping the database migration to reduce risk."

This gives you specific insights to address before the real planning meeting.

The simulation approach is vendor-agnostic - whether you use Claude, Gemini, ChatGPT, or any other LLM, the structured methodology delivers insights. 

Implementation Reality

Limited Accuracy - to begin with: Your first simulations will be roughly 30-40% accurate—useful for obvious issues but not fine-grained predictions. 

We don't know the exact improvement trajectory, but by consistently feeding actual sprint outcomes back into the simulation, accuracy should improve over time. 

Data Quality Matters: Meeting transcripts, project management tools, and retrospectives already contain most simulation inputs. 

Data Privacy: As a general rule we should anonymise sensitive data before uploading to AI platforms. Remove specific names, project details, and commercial information whilst preserving team dynamics and estimation patterns. 

Your Next Steps

  1. Document one upcoming sprint planning session as your baseline

  2. Capture team estimation patterns from recent retrospectives and velocity data

  3. Create basic team personas using actual member characteristics

  4. Run a simple simulation using structured prompts in ChatGPT or Claude

  5. Compare simulation insights with actual sprint planning outcomes

  6. Iterate and improve based on accuracy and usefulness

The goal isn't perfect prediction—it's better decision-making through structured exploration of possibilities! The technology is ready. The data exists. 

Are you ready to use Claude for strategic advantage rather than just task automation?

Reply

or to participate.