Agile Business Analysis: The BA's Role in Scrum, Sprints and Product Delivery

DAY 1 | The BA in an Agile Team: What Really Changes

I want to tell you about the first week of my first Agile project. I had come from a Waterfall background. I knew how to produce a Business Requirements Document. I knew how to run a requirements workshop, baseline a specification, and manage a change control process. I was good at it. And I walked into that Agile team expecting to find an equivalent set of activities that I would now do differently. What I found instead was a team in the middle of a sprint, a backlog that was half-written and completely unprioritised, a Product Owner who was too busy to meet with me for three days, and a standup that lasted six minutes and covered almost none of what I expected it to cover. I spent that first week looking for the requirements phase. The moment when someone would say: now we gather requirements, now we analyse them, now we document them. That moment never came. Because in Agile, there is no requirements phase. Requirements are not a phase. They are a continuous activity that runs through every sprint, every ceremony, and every conversation for the entire duration of the project. That was the adjustment I was not prepared for. And it is the adjustment that catches most BAs who move into Agile from a traditional background.

What Actually Changes When You Move to Agile

Most BA training programmes describe the move to Agile as a methodology shift. You stop writing BRDs and start writing user stories. You stop attending phase-gate reviews and start attending sprint reviews. The tools change. The templates change. That description is accurate. It is also incomplete in a way that leaves most BAs underprepared. The biggest change is not in the tools or the templates. It is in the nature of the BA role itself. In a traditional project, the BA is primarily a producer. They produce requirements, they produce specifications, they produce documentation. There are phases where BA work is heavy and phases where it reduces. The BA moves through a project in waves of intensity.

In an Agile team, the BA is primarily a facilitator and a translator. They are always working. Not in waves. Continuously. Every sprint needs stories refined before it starts. Every standup surfaces requirements questions that need answering today, not next week. Every sprint review generates new requirements information that needs to be captured and processed immediately. The work does not come in phases. It comes in a constant stream.

This changes what you focus on, how you plan your time, and how you measure your own contribution. A BA in a Waterfall project can point to their BRD and say: that is what I produced. A BA in an Agile team has a much harder time making their contribution visible, because the contribution is distributed across dozens of small interactions rather than concentrated in a single document.

That invisibility is one of the reasons the BA role in Agile is so often misunderstood, undervalued, and sometimes eliminated entirely. And it is why the BAs who thrive in Agile are the ones who understand clearly what their contribution is, articulate it consistently, and build working practices that make it visible.

The Identity Shift: From Document-Producer to Embedded Analyst

In a traditional project, the BA's primary identity is tied to their deliverables. You are the person who produces the BRD. You are the person who owns the requirements specification. Your value is visible in the documents you create, the reviews you run, and the baseline you maintain. In an Agile team, your primary identity is tied to the quality of what gets built. You are the person who ensures that the development team always has clear, complete, well-thought-through work to pick up. You are the bridge between what the Product Owner wants and what the team can build. Your value is visible not in a document but in the smoothness of the delivery, the quality of the stories the team works from, and the absence of the expensive misunderstandings that happen when requirements are unclear.

This is a meaningful identity shift. And it requires a change in how you think about your own success.

In Waterfall, a well-written BRD that nobody builds from correctly is still a successful deliverable. In Agile, a backlog full of beautifully formatted user stories that the development team cannot execute without constant clarification is a failure. The measure of quality in Agile BA work is not the document. It is the outcome.

What the Agile BA Actually Does

Let me be concrete about this, because the abstract description of the Agile BA role tends to collapse into vague phrases about collaboration and communication that do not help anyone understand what they should actually be doing on a Monday morning.

1. The Agile BA owns the backlog quality. Not the backlog itself, which is owned by the Product Owner. The quality of what is in it. Every story in the backlog that is heading toward a sprint should have been reviewed, refined, and acceptance criteria written by the BA before the development team picks it up. If stories are entering sprints without clear acceptance criteria, without defined edge cases, without a shared understanding of what done looks like, that is a BA quality failure regardless of how good the story format looks.

2. The Agile BA runs the analysis between the sprints. Not in the sprints. This is a critical distinction. The sprint is for building. The analysis that makes the building possible happens in the white space between sprint planning and the end of the current sprint. The BA is always working at least two sprints ahead, refining stories so that when sprint planning arrives, the team is picking up work that is genuinely ready.

3. The Agile BA manages requirements change analytically. When a stakeholder says they want to change something, the Agile BA does not just add a new story to the backlog. They assess the impact of the change on existing stories, on the product direction, on the sprint in progress, and on the priorities that have already been set. They bring that assessment to the Product Owner with a clear recommendation, not just a new item on a list.

4. The Agile BA is the team's requirements memory. In a Waterfall project, the BRD serves as the organisational memory for what was agreed and why. In Agile, there is no single equivalent document, which means the BA must maintain enough context about the full scope of what is being built to answer questions that arise mid-sprint without needing to go back to a document.

The Trap Most BAs Fall Into

There is a trap that catches a significant number of BAs who move into Agile, and it is seductive precisely because it looks like good practice. The trap is treating the absence of a BRD as permission to do less analytical work. In a Waterfall project, the BRD is the vehicle that forces rigorous analysis. You have to think completely about requirements because you are writing them all down in one place and getting them signed off. The structure of the methodology enforces the thoroughness. In Agile, that structure is absent. Nobody is asking for a hundred-page document. Nobody is scheduling a formal requirements review. The ceremonies are shorter, the artefacts are lighter, and it is entirely possible to move through sprint after sprint doing what looks like BA work without ever going as deep as the project actually needs.

The symptoms of this trap are familiar to anyone who has worked in a dysfunctional Agile team. Stories that are not really stories. Acceptance criteria that describe tasks rather than behaviours. A backlog that has grown into an unmanageable list of disconnected items with no clear priority logic. Development teams that spend significant time mid-sprint asking the BA to clarify things that should have been answered before the sprint started.

The Agile BA who avoids this trap is one who brings the same analytical rigour they would bring to a BRD to every story they write, every refinement session they run, and every sprint they prepare for. The format is different. The rigour is identical.

What This Week Covers

Over the next five days, we are going to go deep on every dimension of the Agile BA role.

• Day 2: Writing user stories that actually get built right. INVEST criteria, acceptance criteria in Given-When-Then format, the mistakes that produce stories development teams cannot work from, and how to write for edge cases.

• Day 3: Backlog refinement and sprint ceremonies. What the BA owns in each ceremony, what breaks without active BA involvement, and how to make refinement sessions genuinely productive rather than exercises in reformatting.

• Day 4: Working with your Product Owner. The relationship that determines whether Agile works or does not work, what to do when the partnership is not functioning, and how senior BAs navigate a team where the Product Owner role is poorly defined.

• Day 5: Agile BA in your career. What mastery looks like at Junior, Mid and Senior level, model interview answers, and the six principles to carry forward.

Go out and be successful.

Oluwatosin Ogunkoya | Flotog BA Insights | www.flotogbainsights.com

Tomorrow: Writing User Stories That Actually Get Built Right. The INVEST criteria unpacked, acceptance criteria in Given-When-Then format, and the story-writing mistakes that cause teams to stop and ask questions when they should be building.