What does a business analyst do on an agile team, and how does requirements work survive without a signed-off specification?

The work is the same; the container changed

Nothing in the analysis disappeared when the specification did. Somebody still has to find out how the business really operates, discover that two departments apply the referral limit differently, decide what happens when the payment file arrives twice, and write it down so a developer and a tester read it the same way. On an agile team that output lands in refined backlog items, in acceptance criteria, in a rules or decision register, and in conversation at the moment of build — instead of in a numbered document approved in advance.

What genuinely changes is timing and revisability. Under a specification you analysed a whole scope, had it signed, and then defended it against change through a control process. Now you analyse a slice about a sprint or two ahead of build, in enough depth to build that slice and no more, and you expect the next slice to teach you something that revises your own earlier thinking. The discipline shifts from getting it complete to getting it complete enough, deliberately, at the last responsible moment.

Day to day the job is unglamorous and continuous. You spend a portion of every day two sprints out — talking to subject experts, chasing the answer nobody has, drafting items — and a portion of every day inside the current sprint, answering the six questions a developer hits that no written artefact anticipated, checking a built screen against what the business meant, and reworking an acceptance criterion that turned out to be untestable.

Where the detail lands instead

Acceptance criteria are the load-bearing artefact, and this is where weak candidates fall over: they describe the format and never demonstrate the precision. Compare these two versions of the same story.

# Weak - reads well, cannot be tested, hides three decisions
Feature: Referral of large claims
  Scenario: Large claim is referred
    Given a large claim
    When it is submitted
    Then it should be referred to a manager promptly

# Strong - the boundary, the negative case and the failure path are all stated
Feature: Referral of claims above the product limit
  Background:
    Given the motor product has a referral limit of GBP 25,000

  Scenario: Gross value above the limit is referred
    Given a motor claim with a gross value of GBP 25,000.01
    When the handler submits it
    Then its status is "Referred"
    And it does not appear in the payment run

  Scenario: Gross value exactly at the limit is not referred
    Given a motor claim with a gross value of GBP 25,000.00
    When the handler submits it
    Then its status is "Awaiting payment"

  Scenario: Notification failure does not release the claim
    Given a claim has been marked "Referred"
    When the assessor notification email fails to send
    Then the claim remains "Referred" and unpayable
    And the failure appears on the integration exception report

The second version settles whether the limit is inclusive, states gross rather than net, and answers the question a developer would otherwise answer alone at half past four: whether the block on payment depends on the notification. Those three lines are the analysis. The syntax is not.

Around the criteria sit three things that carry what a criterion cannot. A definition of done holds the cross-cutting obligations that belong to no single story, such as audit logging or accessibility. A short living register holds business rules with a stated rationale, because a rule expressed only inside a closed ticket is effectively lost. And a process model or journey map earns its place for a flow that crosses teams, since a backlog has no natural way to represent an end-to-end path.

Refinement, readiness and splitting

Refinement is where the BA's preparation is either visible or absent. You bring an item that already has its rules, its data availability checked, its dependency on another team named and its open questions listed as open questions. Refinement is then a conversation about approach and risk, not a session where the team watches you discover a requirement live. A useful private measure of your own work is how many questions in refinement you could have answered beforehand.

A definition of ready is the agreement that stops half-analysed work entering a sprint: typically that the item has testable acceptance criteria, no unresolved external dependency, identified test data, and a stated business rationale. Treat it as a conversation trigger rather than a gate to enforce, because a ready checklist used as a weapon recreates the handover it was meant to remove.

Splitting is the technique interviewers probe most, because it separates people who have done this from people who have read about it. Split by business rule, by workflow step, by data variation, by channel, by happy path first with exceptions following. Never split into analysis, then build, then test, which reintroduces phases inside a sprint and produces nothing shippable. A concrete example: "onboard a corporate customer" splits into a sole-trader with one director and no sanctions hit, then multiple directors, then a sanctions match requiring manual review, then non-UK ownership structures. Each is demonstrable, each teaches you something about the next, and the first one is genuinely useful to the business.

Just-in-time is not the same as undocumented

This is where the answer is won. Many candidates say documentation is replaced by working software and conversation, which is half true and, stated flatly, sounds like relief at not having to write. Three things a signed specification supplied for free do not appear on their own, and a strong answer names them.

Traceability is the first. A backlog flows forward well and reaches backwards badly. Six months on, given a behaviour in production, you cannot easily say which objective it served, who agreed it, and which test proves it. You rebuild that with persistent epics or a feature register that outlives the sprint, story-to-test links maintained in the tooling, and a decision log — not with a matrix nobody updates.

Non-functional requirements are the second: retention periods, peak-load behaviour, residency, availability. They belong to no story, so in a story-only process they belong to nobody and they surface in a penetration test the week before go-live.

An agreed scope baseline is the third, and it matters most under contract. If a supplier is delivering to a fixed price against a specification, that document is the commercial instrument, and no amount of agile enthusiasm changes it. Then your job is running both honestly — sprints inside, a controlled baseline outside — and being the person who keeps them reconciled rather than pretending one does not exist.

The role boundary you should state, not assume

The product owner decides what is built and in what order, and accepts the result. You supply the analysis those decisions need and the detail the build needs. In practice the split varies enormously: in many enterprises the product owner is a business expert who attends ceremonies while the BA writes every item, and in others the product owner writes the backlog and the BA works on process and data. Say in the interview that you would establish this on day one, and name the specific questions — who writes acceptance criteria, who decides between two stakeholders, who signs off — because the failure mode is a BA who behaves as a proxy owner without the authority to be one, and then owns a decision they were never allowed to make.

Agile did not remove the requirements work, it removed the document that used to prove the requirements work had been done. Traceability, cross-cutting requirements and the scope baseline are what you now have to produce on purpose.