What You Actually Need to Capture on an Agile Project
If you are trying to work out how business requirements vs functional requirements should be handled on an agile project, you are probably already feeling the friction. Someone has told you that agile teams do not write requirements documents. Someone else has handed you a backlog of vague user stories and asked you to “BA them up.” Neither of those situations is helping you get work done. So let me cut through it.
The short answer is this: agile does not eliminate the distinction between business requirements and functional requirements. It changes where they live, who owns them, and when they are formalised. Understanding that shift is what lets you add genuine value instead of producing documentation that nobody reads.
The Waterfall Starting Point: Why the Old Model Made Sense
In a traditional waterfall project, business requirements and functional requirements were separate documents written in sequence. You gathered what the business needed, produced a Business Requirements Document, then decomposed those needs into a Functional Requirements Document that told developers what to build. The logic was linear: understand the problem fully, then specify the solution fully, then build it. If you want a reminder of how those two documents differ structurally, the BRD vs FRD comparison on this site covers it well.
The problem with that model on an agile project is not that it is wrong in principle. It is that the feedback loops work differently. In agile, you are not handing a finished requirements specification to a team and waiting six months for a product. You are working in short iterations where understanding evolves as the team builds and tests. Writing a full functional specification upfront in that environment produces a document that is partially wrong by the time the first sprint ends.
How Agile Reshapes the Relationship
Here is what actually changes when you move to agile delivery:
- Business requirements move to the product backlog. The outcomes the business needs to achieve are expressed as epics and user stories, owned by the product owner, and refined progressively rather than documented all at once.
- Functional requirements become acceptance criteria. The specific behaviours a system must exhibit in response to user actions are captured at story level, not in a separate document. They are written just in time, when a story is about to enter a sprint.
- The BA role shifts from author to facilitator. Instead of writing requirements documents solo, you are running refinement sessions, challenging ambiguous stories, and making sure acceptance criteria are testable before work starts.
- Traceability still matters, but it looks different. The link between a business objective and the specific functionality being built runs through the backlog hierarchy: strategic goal, epic, feature, story, acceptance criterion. That chain needs to be visible even if it is not in a formal document.
What This Looks Like in Practice: A Real Example with Friction
I worked on a forms and process automation programme for a government department, Organisation A, that had recently decided to adopt an agile delivery approach for a series of small internal digital tools. The initiative involved replacing dozens of manual Word and Excel forms with lightweight SharePoint-based solutions, each delivered within a fixed $10,000 budget per solution. The overall programme budget was $90,000 covering at least nine individual deliverables.
What made this interesting from a requirements perspective was the deliberate decision to abandon traditional upfront requirements documentation. No formal business requirements document. No functional specification. Instead, the approach relied on iterative prototyping: I would run a workshop with the business stakeholder based on a working prototype built in SharePoint, gather feedback in the room, refine the prototype, then repeat until the solution was accepted.
That sounds clean. It was not. The friction came from the HR team, who were responsible for one of the more complex solutions involving job swap applications, agreement forms, and an expressions of interest register. Three separate Word forms with overlapping fields, each sitting with a different part of the business. When I brought them together around a prototype, it became clear that the three form owners had different assumptions about which data fields were mandatory, who should receive workflow notifications, and whether manager approval was one step or two.
In a waterfall project I would have caught that during requirements elicitation and resolved it before a line of configuration happened. In the agile prototype model, we discovered it mid-iteration. The project manager wanted to push on and resolve it later. I pushed back. My argument was that the business process owner question had to be settled before we could finalise the acceptance criteria for the workflow story, because the number of approval steps directly affected both the screen design and the notification logic. Continuing without that decision would mean re-doing work that was already within a constrained budget.
We paused for two days, got the right people in a room, and resolved the decision. The business process map I produced in that session became the closest thing to a functional requirements artefact on the project: a cross-functional diagram showing stakeholders, process steps, decision points, and workflow triggers. It was not called a functional requirements document, but it did exactly that job.
That experience reinforced something I have seen repeatedly across agile engagements: the functional requirements thinking does not disappear. It just gets expressed differently, often through process maps, acceptance criteria, and prototype demonstrations rather than through formal specification documents.
Comparing the Two Approaches Side by Side
| Aspect | Waterfall Approach | Agile Approach |
|---|---|---|
| Business requirements format | Business Requirements Document (BRD) | Epics and user stories in the backlog |
| Functional requirements format | Functional Requirements Document (FRD) | Acceptance criteria at story level |
| When requirements are written | Upfront, before development begins | Just in time, as stories approach a sprint |
| Who owns requirements | BA produces, stakeholders approve | Product owner owns the backlog; BA supports refinement |
| Traceability mechanism | Requirements traceability matrix | Backlog hierarchy: goal, epic, feature, story, criterion |
| Change management | Formal change control process | Backlog reprioritisation in sprint planning |
| Validation approach | Formal UAT against requirements document | Acceptance criteria tested within the sprint |
What BAs Get Wrong About Agile Requirements
The most common mistake I see early-career BAs make on agile projects is assuming that because there is no BRD or FRD, there is nothing to analyse or document. That leads to two failure modes. Either they produce nothing and the team builds based on assumptions, or they produce a waterfall-style document that nobody reads because it does not fit the team’s workflow.
The better framing is to ask: what does this team need from me, in what format, and at what point in the sprint cycle? For most agile teams, the answer is:
- Before a story enters the backlog: A clear problem statement that explains what the business needs to achieve and why, not what the system should do.
- During backlog refinement: Well-written acceptance criteria that are specific, testable, and agreed with both the product owner and the development team.
- Before sprint planning: Any business rules, constraints, or edge cases that the team needs to handle correctly in this iteration.
- After a sprint: Feedback from stakeholders on whether delivered functionality actually meets the business need, not just whether it passes the acceptance criteria as written.
That last point matters more than most people acknowledge. Acceptance criteria written before development can still be wrong. I have signed off stories as meeting their acceptance criteria only to have a stakeholder demonstrate in the review that the underlying business need was not met. The criteria were technically correct but did not cover an edge case that the stakeholder assumed was obvious. That is a requirements gap, and it happens on agile projects just as often as on waterfall ones.
Keeping the Business Requirement Visible
One of the risks of agile delivery is that the original business requirement gets lost as the team focuses on individual stories. I have seen products shipped that technically satisfied every user story in the backlog but did not solve the problem the business actually had. The stories had drifted. New ones had been added. The original intent had been diluted across twelve sprints.
The way I guard against this is to keep a short, plain-English statement of the business outcome at the top of every epic. Not a user story. Not a system capability. A statement of what the business is trying to achieve and how success will be measured. Something like: “Finance teams need to process expense claims without manual data entry so that processing time falls below two working days per claim.” Every story under that epic should trace back to that outcome. If it does not, it probably should not be in the epic.
This is exactly the kind of thinking that sits at the heart of good requirements work on any project. If you want to go deeper on how business and functional requirements relate to each other structurally, the article on business requirements vs functional requirements covers the foundational layer well. And if you are working in a context where agile deliverables are a recurring question, the guide to BA deliverables in agile is worth reading alongside this one.
Practical Steps to Apply This on Your Current Project
- Audit your current backlog against business outcomes. Check whether each epic has a clear business objective attached, not just a feature description.
- Review your acceptance criteria for testability. If a criterion cannot be verified with a specific test, it is not a functional requirement yet. It is still an aspiration.
- Find the process map that is missing. Most agile teams skip process mapping. I almost always produce one, even informally. It is the fastest way to surface the decisions that acceptance criteria need to reflect.
- Identify unresolved business rules before each sprint. These are the details that slip through: what happens when a field is left blank, what triggers a rejection, who can override an approval. Get them answered before the developer starts work, not during code review.
- Validate against the original business need after each sprint. Not just against the acceptance criteria. Ask the business stakeholder directly: does what we built get you closer to the outcome you described at the start?
The shift from waterfall to agile does not make requirements thinking less important. It makes it more urgent, more continuous, and more visible in how the team works day to day. The BA who understands that distinction, and who can move fluidly between articulating business outcomes and specifying functional behaviours at story level, is the one who adds the most value to an agile team. The documents change. The thinking does not.
Frequently asked questions
Do agile teams still need business requirements?
Yes, agile teams still need a clear understanding of what the business is trying to achieve and why. Business requirements in agile are typically expressed as epics or high-level user stories at the top of the backlog rather than in a formal BRD. Without them, teams risk building functionality that passes acceptance criteria but does not solve the actual business problem.
What replaces functional requirements in agile?
Acceptance criteria on user stories play the role that functional requirements documents play in waterfall. They specify the exact behaviour a system must exhibit to satisfy a given story. They should be written before a story enters a sprint and must be specific enough to be tested.
Should a BA still write a BRD on an agile project?
Not typically in the traditional sense, but the thinking behind a BRD is still necessary. On agile projects, that thinking is expressed through well-structured epics, clear business outcome statements, and refined acceptance criteria rather than a single upfront document. Some organisations use a lightweight project brief or vision document to capture the business context before backlog work begins.
How do you trace requirements in agile without a traceability matrix?
Traceability in agile runs through the backlog hierarchy: from strategic goal to epic to feature to user story to acceptance criterion. Many teams use their project management tool, such as Jira or Azure DevOps, to maintain that chain. The key is ensuring every story can be linked back to a business outcome, even if the link is informal.
What is the difference between a user story and a functional requirement?
A user story describes who needs something and why from a business perspective, whereas a functional requirement specifies what the system must do in response to a particular input or action. In agile, acceptance criteria bridge the two by translating the intent of a user story into testable system behaviours. Both levels of thinking are needed for a team to build the right thing correctly.
Try Ash, Your Virtual BA
If you are trying to work out exactly what to write on your current agile project, whether that is acceptance criteria, a lightweight epic structure, or a business outcome statement that keeps your backlog honest, Ash can help you build it. Ash is purpose-built for business analysis work and understands the difference between a business requirement and a functional one at every level of the backlog. Skip the guesswork and get structured, practical output in minutes. Try Ash Virtual BA.
Further reading
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.