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

DAY 3 | Backlog Refinement and Sprint Ceremonies: The BA's Engine Room

There is a version of Agile BA practice where every ceremony is something that happens to you. Sprint planning happens, and you answer questions when the team asks them. The standup happens, and you give your update when it is your turn. The sprint review happens, and you sit in the room while the developers present. The retrospective happens, and you nod along. This version of the role is passive. And it is far more common than most Agile practitioners would like to admit.

The ceremonies in Scrum are not meetings you attend. They are the primary working tools of the Agile Business Analyst. Each one is an opportunity to do something specific and important: to clarify, to elicit, to align, to capture, to improve. The BA who understands this uses every ceremony deliberately. The BA who does not is a warm body in a room.

Today we go through every ceremony and define exactly what the BA owns in each one.

Backlog Refinement: The BA's Primary Working Session

Backlog refinement is the ceremony that makes everything else work. It is where stories are broken down, acceptance criteria are written, edge cases are identified, estimates are discussed, and priorities are confirmed. Done well, it means sprint planning is fast and smooth, stories enter the sprint ready to be built, and the development team spends its time building rather than asking for clarification. Done badly, it means sprint planning is slow, stories are vague, mid-sprint questions pile up, and the velocity of the team is lower than it should be because the BA work that should have happened before the sprint is happening during it.

The BA owns the preparation for refinement. Not the Product Owner. Not the Scrum Master. The BA. This means reviewing every story that is coming up for refinement before the session, identifying the gaps, preparing specific questions, and often drafting acceptance criteria ahead of time so the session can focus on review and discussion rather than starting from zero. In the session itself, the BA is working at two levels simultaneously. At the story level, they are ensuring each story is understood, correctly sized, and has clear, testable acceptance criteria before it leaves the session. At the backlog level, they are maintaining awareness of the coherence of the set: do these stories hang together logically, are there gaps between them, are there dependencies that need to be managed?

One of the most common failures in backlog refinement is treating it as a formatting exercise. The team goes through each story, checks whether it looks like a user story, adds some notes, and marks it as refined. What they have not done is ask whether the story is actually clear enough to build from. The test is simple: can every member of the development team describe, independently, what done looks like for this story? If the answers differ, the story is not ready.

Sprint Planning: The BA as Business Context Authority

Sprint planning is where the team selects which stories they will build in the coming sprint and confirms the sprint goal. The BA's role is not to lead this session. That is the Scrum Master's job. The BA's role is to be the authoritative voice on business context. When the team discusses a story and asks whether a particular implementation approach is acceptable from a business perspective, that question is for the BA. When there is uncertainty about the priority of two stories and the Product Owner is not sure which delivers more value, the BA provides the analytical context that informs the decision. When a story needs to be adjusted to fit the sprint capacity, and there is a question about which acceptance criteria can be deferred without losing the story's core value, the BA makes that call.

The BA should also be watching for stories that are clearly not sprint-ready despite having been through refinement. If a story is generating significant discussion and uncertainty in sprint planning, that is a signal that refinement was insufficient. The right call is to pull the story from the sprint, resolve the questions, and re-refine it before the next sprint planning session. It is always better to be one story short in a sprint than to carry an unready story through two weeks of development confusion.

The Daily Standup: Five Minutes of Active Listening

The BA's standup contribution should be brief: what you completed yesterday relevant to the team, what you are working on today, and any blockers. That part is simple. What is less obvious is what the BA should be doing while everyone else gives their update. Listening. Analytically.

Developers describe blockers in technical language that often masks a requirements problem underneath. "I am not sure how to handle the case where a user has two active orders at the same time" is a technical statement. It is also a requirements gap. The acceptance criteria for that story did not address concurrent orders. If the BA does not catch this in the standup, the developer will make an assumption. That assumption will either be correct, in which case you were lucky, or it will be wrong, in which case you have a defect.

After the standup, the BA should be following up immediately on any technical blocker that has a requirements dimension. Not at the end of the day. Not in the next refinement session. Immediately. Unresolved requirements questions during a sprint accumulate into delays. The BA who resolves them quickly keeps the team moving.

The Sprint Review: The Most Underused Elicitation Session in Agile

The sprint review is the most valuable elicitation session available to the Agile BA, and it is consistently the most underused. When stakeholders see working software, they tell you things they could never have told you in a workshop. They see interactions they did not anticipate. They identify gaps they did not know existed. They change their minds about priorities in ways that are grounded in direct experience of the system rather than abstract imagining of it. This is real requirements information. It is often better quality than anything the elicitation process produced.

The BA's job in a sprint review is not to present completed work. It is to facilitate a feedback conversation and capture every piece of new information for conversion into backlog items before the next sprint planning session. This requires preparation. Before the sprint review, the BA should identify the two or three questions they most need stakeholders to answer about the current sprint's output. They should design the demo flow to surface those questions naturally rather than leaving them to chance. And they should have a clear process for capturing feedback in a format that can be directly converted into stories or refinements.

The sprint review where stakeholders are not present is an Agile failure. It removes the feedback loop that is the core mechanism of Agile delivery. When stakeholder attendance is low, that is a problem for the BA to investigate and address, not a feature of Agile to accept. Low attendance usually signals one of three things: the format is not engaging enough to be worth the time, the wrong people are being invited, or there is a relationship gap between the delivery team and the business. All three are addressable. None of them fix themselves.

The Sprint Retrospective: The BA's Professional Development Tool

The retrospective is where the team reflects on how they worked together and identifies specific improvements for the next sprint. The BA participates as a full team member, not as an observer. If requirements quality was a factor in any sprint problems, whether stories were unclear, acceptance criteria were ambiguous, or edge cases were missed, the retrospective is where the BA should own it explicitly. Not defensively. Not with excessive qualification. Directly. "The acceptance criteria for the payment story were not specific enough about the error handling, which caused the team to stop and wait for clarification on day three. In the next sprint, I am going to make sure error state criteria are drafted before refinement rather than during it."

That kind of direct ownership builds credibility. It shows the team that the BA is accountable for the quality of their own work in the same way developers are accountable for the quality of theirs. And it turns the retrospective into a genuine tool for improving BA practice rather than a team meeting where the BA is a spectator.

What Breaks Without Active BA Involvement

When BA involvement in the ceremonies is shallow or passive, the same problems appear with enough regularity that they have become predictable. The backlog becomes a list rather than a product plan. Stories accumulate without a coherent priority logic. The connection between individual stories and the strategic objectives of the project becomes invisible. The team builds features efficiently without anyone maintaining clarity about whether the features being built are the right ones in the right order.

Sprint planning slows down because stories are not ready. The team spends the first half of every sprint planning session clarifying work that should have been clarified in refinement. Velocity suffers. The sprint goal is vague because the individual stories underneath it were vague. Mid-sprint questions pile up. Developers stop to ask the BA for clarification because the acceptance criteria did not cover their scenario. Each interruption is small. Collectively, they represent hours of lost development time across every sprint.

The sprint review stops generating useful information because stakeholders stop attending. Nobody tells the team this is because the reviews are not engaging enough to justify the time. They just quietly stop coming.

All of these are BA problems. Not Scrum problems. Not Product Owner problems. BA problems. And all of them are preventable with the kind of active, deliberate ceremony involvement this article has described.

Go out and be successful.

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

Tomorrow: Working With Your Product Owner. The relationship that determines whether Agile works, how to make it function well, and what the experienced BA does when the partnership is not working.