Saratoga Software · Business Analysis
What Business Analysts
Really Do When
Delivery Gets Messy
A firsthand account from three business analysts who joined a complex programme mid-flight — at the same time, into the same client, but three very different working environments.
By
Rafieqah, Aldo & Jaco
Business Analysts at Saratoga Software · April 2026
Introduction
How this started
Saratoga placed three of us into the same client programme on the same day.
The programme had been running for months. The teams were already in a rhythm — stand-ups had their own shorthand, the backlog had a history we hadn't lived, and the systems had layers of decisions we hadn't been part of making.
There was no onboarding window. No handover pack waiting for us. No gradual introduction to the domain. Each of us simply showed up in a squad that was already moving and had to make ourselves useful — fast.
On the surface, the environment looked well structured. The ceremonies were happening. The backlogs existed. The delivery framework was familiar. But the real work sat beneath the surface — in the edge cases, the business rules, and the knowledge that lived in people's heads rather than in any document.
Programme timeline
Same programme. Three realities.
Squad A — Steady cadence
Planned increments, predictable delivery rhythm, clear backlog ownership.
Squad B — Reactive priorities
Fast-changing scope, shifting stakeholder priorities, constant reprioritisation.
Squad C — Compliance-driven
Fixed regulatory deadlines, non-negotiable scope, work arriving outside normal planning cycles.
The same agile framework. The same broad goal. But from day one, the experience of being a BA in each squad was fundamentally different.
01 — Context
Every squad had
its own rhythm
Some teams had steady work that followed planned increments. Others were more reactive. In some areas, compliance-driven work arrived with fixed deadlines and very little room to move — outside the normal planning rhythm, but still demanding urgent attention from teams already stretched.
That changes the business analyst role. You are not simply gathering requirements at the start and handing them over.
"Priorities shift. Requirements become clearer as work progresses. The BA has to stay close to the work — making sense of what is changing, what is still unclear, and what needs to be decided before delivery can move forward."
Questions surfacing at every stage
During planning — what is actually in scope?
During development — what did we assume that turns out not to be true?
During testing — what did the system do that no one expected?
After release — what do users actually need vs. what we built?
In every squad, the BA role was not a phase at the start of the process. It was a continuous thread running through the whole of it.
02 — Learning
The knowledge gap
is part of the job
All three of us felt the same thing early on: everyone else already knew things we still had to learn. Teams had their own terminology. Systems had history. Stakeholders understood context that was never written down.
People knew which rules mattered, which exceptions caused trouble, and which parts of the process worked differently in real life. That gap can feel uncomfortable when you are trying to add value quickly.
Good business analysts ask focused questions, know where to go for answers, listen carefully, test their understanding, and build context without creating unnecessary noise. Trying to sound like the smartest person in the room does not help. Learning quickly and clearly does.
The realisation
"Strong business analysts are not defined by how much they know on day one. They are defined by how they learn."
Ask
Focused, specific questions — not broad, open-ended ones that waste people's time.
Listen
For inconsistencies, gaps, and the things people say differently to different audiences.
Test
Your understanding. Repeat it back. Let people correct you. That is how gaps surface.
Record
Turn what you learn into shared artefacts. Don't let valuable knowledge stay in your own head.
03 — Subject Matter Experts
SMEs made
the difference
The most useful conversations were often with subject matter experts. They helped us understand how systems behaved in practice, where the exceptions lived, and what certain decisions would mean for users and teams. Without that input, our analysis would have stayed too shallow.
But working with SMEs is not a passive process. We had to prepare well — ask specific questions, test assumptions and listen for differences in interpretation. Often, a simple question revealed that two people understood the same rule in entirely different ways.
"That is exactly the kind of gap a business analyst needs to uncover early — before it becomes a development problem, a testing problem, or a go-live problem."
What SME conversations produce
The translation that matters Without it, valuable knowledge stays scattered across conversations and individuals. With it, the team has something clear enough to build, test and challenge together.
04 — The Core Insight
Clarity is
the real work
Documentation alone does not solve confusion. It does not remove contradictions. It does not prove that the business, developers, testers and users all mean the same thing when they use the same words.
For clients, unclear requirements do not stay as analysis problems — they become development delays, testing gaps, rework, missed expectations and frustrated users.
← Click each question to see what it is really probing for.
Six questions that expose the real gaps
05 — Adapting in Practice
Agile delivery
still needs judgement
Frameworks help. Ceremonies help. Structure helps. But no process can think for you.
Each squad had its own pace, culture and pressure points. To be effective, we had to adapt without losing the discipline of good analysis.
It is not about following a process blindly. It is about using the process to help people make better decisions and deliver better outcomes.
What adaptation looked like
Changing how we engaged stakeholders
Meeting people where they were — formal or informal, documented or conversational, synchronous or async.
Adjusting the level of documentation
Matching the complexity and risk of the work — not over-engineering every story, not leaving gaps in critical business rules.
Stepping in to challenge things that did not make sense
The most valuable intervention is often the question no one else thought to ask — or was too close to the work to ask.
Staying close even when the work felt stable
Stable-looking delivery can hide misalignment. The BA's job is to keep asking until the team genuinely shares the same understanding.
Conclusion
What the experience
taught us
Looking back, we came away with the same conclusion. Being a strong business analyst is not about arriving with all the answers. It is about how you deal with uncertainty.
← Work through each insight to reveal the conclusion.
How quickly you learn a new environment. Not what you already know walking in — what you do in the first days and weeks to build real context.
How well you work with subject matter experts. The depth of your analysis depends entirely on the quality of those relationships.
How clearly you ask questions. Not how many questions — how precise and useful they are for the people you are asking.
How effectively you turn scattered knowledge into shared understanding. The output is not just documentation — it is alignment.
How well you hold the team together around a shared definition of what needs to be built. In high-pressure delivery, that shared understanding is what keeps things moving.
The bottom line
In high-pressure delivery, clarity is not a nice-to-have. It is what keeps teams moving in the same direction. Strong business analysts help create that clarity — and they do it without slowing anything down.
Saratoga Software · Business Analysis
Need business analysts who can bring clarity without slowing delivery down?
Saratoga's business analysts are used to joining complex delivery environments, learning quickly, working with SMEs, and turning scattered information into clear, testable requirements.
Speak to us about how we can support your next project with practical, delivery-focused business analysis.
Frequently Asked Questions
Common questions about
business analysis in agile delivery
About the authors
Rafieqah, Aldo, and Jaco are business analysts at Saratoga Software. This article is based on their shared experience joining and delivering on a complex client programme at the same time, in different squads.