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.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).