BRD or user stories? How to choose in UK financial services
Business analysts in financial services are often told to "go agile" while a governance committee still asks for a business requirements document. Both demands are reasonable, and the question of which format to use is rarely either-or. This article sets out what each is good for and gives a decision table you can use on your next piece of work.
Last reviewed: October 2026.
What each one is for
A business requirements document (BRD) records what the business needs, in one place, in a form that can be reviewed and signed. It tends to include scope, objectives, stakeholders, business rules, constraints and a numbered list of requirements. Its strength is completeness and a clear approval point.
A user story is a short statement of a need from one user's point of view, usually in the form "As a [role], I want [capability], so that [benefit]", with acceptance criteria. It is meant to start a conversation with the delivery team and to be small enough to build in a sprint. Its strength is fast, incremental delivery and adjustment as you learn.
Neither is better. They answer different questions. The BRD answers "what have we agreed the business needs?" The story answers "what are we building next, and how will we know it works?"
Where the choice gets hard in financial services
Three things push towards more documentation than a typical product team would write.
Audit and accountability. Some changes need a record that a named person approved a requirement at a point in time. That may be set by your firm's change policy or by a regulator's expectations. Check your own firm's rules, and ask your compliance or risk function if you are unsure what they need to see.
Fixed rules. A payment cut-off time, a sanctions-screening rule or a reporting field is not up for negotiation in a sprint. Those need to be stated precisely and traced, whatever format you use.
Many parties. Operations, legal, compliance, technology and a third-party supplier may all need to agree. A written document gives them one thing to comment on.
Pushing the other way: customer-facing features, internal tools and anything where you expect to learn by releasing something small are poorly served by a 60-page document written before anyone has seen a screen.
Starter, £30 (41 files, discovery to a tested set of requirements) · Complete, £80 (59 files, adds governance and assurance). Prices include UK VAT: Starter £25 + VAT, Complete £66.67 + VAT. Payhip may show the price before VAT. One payment, no subscription.
Sold by Quantum Sphere Consulting Limited; your statutory rights apply.Decision table
| Situation | Lean towards | Why |
|---|---|---|
| Regulatory change with a fixed deadline and defined rules | BRD, with stories for delivery | Rules and approvals need a stable record; the build can still be incremental |
| New customer-facing feature, uncertain demand | User stories | You will learn from early releases; a long document will date quickly |
| Replacing a system like-for-like | BRD or detailed requirements list | The aim is to preserve behaviour; completeness matters more than discovery |
| Procured package or third-party supplier | BRD | A contract and supplier response depend on written requirements |
| Internal tool built by an agile team | User stories | Close contact with users; low governance overhead |
| Change touching several departments' controls | BRD, plus a traceability matrix | Many sign-offs and an audit trail |
| Small enhancement to an existing product | User stories | Context already exists; a BRD would repeat it |
| Data migration or reporting change | Mapping specification, with stories for the work | The rules sit in the data, not in a user's goal |
If a row does not match your situation, ask who has to approve, how likely the requirement is to change, and whether a third party is bound by what you write.
The hybrid that works well
On many financial-services projects the most practical answer is a short, stable top layer and a flexible lower layer.
- A lean business requirements document. Objectives, scope, constraints, business rules and the controls that must hold. Ten pages, not sixty. It changes through a formal change request.
- A backlog of user stories below it. Each story links to the section or rule it serves. Acceptance criteria are written with the people who will test.
- A traceability link between the two. It can be a simple column in the backlog. It shows the committee that everything in the BRD is covered, and shows the team why each story exists.
This gives the governance process what it needs without freezing the detail.
An example, with a fictional firm
Northgate Bank needs to add a new payment type to its business banking platform before a scheme deadline. The scheme sets the message format and cut-off times. The bank can decide the screens and notifications.
The BA writes a short BRD covering the scheme rules, the scope, the controls, and the approvals required. These are numbered and signed by the product owner and compliance. The customer-facing parts become stories: "As a business customer, I want to see which payment type I am using before I confirm, so that I do not send money by the wrong route." Each story cites the BRD item it supports. When the scheme rules change, the BRD is revised through change control and the affected stories are found through the links.
Neither document alone would have worked. The BRD alone would have been too slow for the screens. The stories alone would have left the scheme rules scattered across tickets.
Common mistakes
Writing stories for rules. "As a system, I want to apply the cut-off time" tells nobody anything. State the rule as a rule, with its source, and write acceptance criteria against it.
Treating the BRD as finished at sign-off. Requirements move. If the document has no change route it will be ignored, and the backlog will become the real record without anybody having decided that.
Duplicating content. If the same requirement is in the BRD, the story and the test plan, they will drift apart. Keep one home for each fact and link to it.
Ignoring who reads it. A committee needs a different view from a developer. Write for the person who has to act on it.
What to do on Monday
Look at your current piece of work and ask three questions. Who must formally approve it? Is any part of it fixed by a rule or a deadline outside your control? Will you know more in a month than you do now? If the first two answers are yes, you need the stable layer. If the third is yes, keep the delivery layer flexible.
The Starter toolkit includes a User Story and Acceptance Criteria Library and a Functional Specification template, which work together in the way described above.