If you are on an Agile project right now and trying to work out exactly what business analyst deliverables in Agile you should be producing, this is your working reference. Not the theory. Not a framework comparison. The actual artefacts: what they are, what they look like in practice, and what goes wrong when you get them wrong.
The confusion I see most often is that people come into Agile projects expecting the BA role to look like Waterfall with shorter cycles. It does not. The artefacts are different, the timing is different, and the relationship with the team is different. What I want to do here is walk you through each deliverable with enough specificity that you can act on it in your current sprint.
How the Deliverable Model Changes in Agile
In Waterfall, I would typically produce a comprehensive set of upfront documents: the business requirements specification, process models, data dictionaries, and a sign-off package before development touched a line of code. In Agile, that model inverts. You produce just enough to support the next sprint, and you refine continuously based on what the team learns.
That does not mean documentation disappears. It means its purpose changes. Every artefact you produce in Agile exists to enable someone else to act: the developer to build, the tester to test, the stakeholder to decide. Before I produce anything, I ask one question: does this help the team build the right thing in the next sprint? If the answer is no, I do not produce it.
The table below shows how the deliverable model compares across the two approaches.
| Dimension | Waterfall BA | Agile BA |
|---|---|---|
| Requirements format | Business Requirements Specification, FRD | User stories with acceptance criteria |
| Timing of deliverables | Front-loaded, before build starts | Continuous, just ahead of each sprint |
| Documentation volume | Comprehensive upfront artefact set | Minimal, purpose-driven artefacts |
| Sign-off model | Formal approval at phase gates | Sprint review feedback loop |
| BA relationship to build team | Handoff at end of requirements phase | Continuous collaboration inside the sprint |
| Handling changing requirements | Change control process, often resisted | Backlog refinement, expected and managed |
For a broader look at how the two approaches differ across the project lifecycle, see Agile vs Waterfall Methodologies: Choosing the Best Methodology for Your Project.
The Core Agile BA Deliverables
- User stories. The primary unit of work in most Agile frameworks, written in the format: As a [user role], I want [functionality] so that [benefit]. The BA is typically the person who writes them, refines them, or quality-checks them before they enter a sprint. The format keeps focus on user value and forces you to articulate why a feature matters.
- Acceptance criteria. Specific, testable conditions attached to each user story that define when a story is complete. Without them, “done” means something different to the developer, the tester, and the business stakeholder. Good acceptance criteria cover both functional and non-functional conditions.
- A refined backlog. A prioritised, sprint-ready queue of work maintained throughout the project. Refinement is where most of the BA’s value is generated in Agile. Stories that are vague, too large, or poorly sequenced create friction in sprint planning and slow the team down.
- Process maps and visual models. Used when a workflow is complex, involves multiple actors, or has branching logic and system integration points. Even experienced Agile teams benefit from a clear end-to-end flow when they are building something they have never built before.
- A data map. A single source of truth for every field in the system: whether it is preloaded from a source system or manually entered, which record types it applies to, mandatory or optional status, and any validation rules. This artefact alone can save hours of back-and-forth between the developer and business stakeholders.
- Sprint goals. A one-sentence statement agreed at sprint planning that defines what the sprint is trying to achieve. The BA typically contributes to defining this by translating business priorities into a clear focus statement. It becomes the reference point for every mid-sprint decision.
- MVP definition. The agreed minimum feature set for the first release, documented as a tagged set of user stories rather than a narrative description. This makes it easy to track which MVP stories have been completed and which are still in progress at any point during the build.
For detailed guidance on writing stories with well-formed acceptance criteria, see How to Write User Stories and Acceptance Criteria: Formats, Tips and Best Practice.
A Worked Example: When the Sprint Tells You Something Is Wrong
On Project X, an education sector build to give teachers a single digital platform for managing personalised learning plans for students with additional needs, I entered Sprint 1 with what looked like a clear, well-scoped backlog. We had planned 18 story points across eight core stories. The sprint goal was to establish the ability for a teacher to find a student, initiate a plan, and have pre-loaded data pulled from existing school systems displayed correctly.
During the sprint, the team identified 12 additional stories that needed to be addressed, adding a further 24 points. The actual velocity at the end of the sprint was 32 points against a planned velocity of 42. That gap was not a team performance problem. It was a scoping problem I had not caught in time.
The additional stories emerged because the data requirements for the learner profile were more complex than they had appeared in the high-level requirements. Several fields that looked straightforward required changes to database SQL queries to expose the right data from source systems. That was not visible until the developer started building. The retrospective was direct: requirements for fields on the data spreadsheet had taken too long to decipher, and story writing needed to stay further ahead of the build cycle. That feedback was directed at me.
There was also a specific point of friction at sprint planning. The Product Owners wanted the student search function, the full learner profile display, and several assessment data fields all confirmed as tested within Sprint 1. The developer pushed back on the data fields, and fairly so: the connections to source systems had not yet been confirmed as accessible. I had to help the team triage. Some stories moved to tested status. Others stayed in progress because the underlying data connections were still being resolved. We ended up with a velocity gap we had to explain clearly to the business sponsor at the sprint review.
I adjusted the approach for Sprint 2. The data map was made more explicit, backlog descriptions were more detailed, and I committed to having the next sprint’s stories written and reviewed before the sprint planning session. The lesson was practical: if the BA is not keeping pace with the developer, the developer either stops or starts making assumptions. Neither outcome is acceptable.
Non-Functional Requirements in Agile
Non-functional requirements are frequently neglected in Agile projects because they do not fit neatly into the user story format. But they are just as important as functional requirements, and if left until late in the build, they can be expensive to address.
On Project X, the full NFR set covered security, performance, reliability, compliance, and data retention. Those requirements were translated into acceptance criteria attached to relevant stories. A story about displaying pre-loaded assessment data, for example, included a criterion that the display load within two seconds of the learner profile opening. That non-functional condition could easily have been overlooked if the criteria only covered the functional behaviour.
The security requirements were particularly complex. The system handled sensitive student data including disability classifications and wellbeing information. Role-based access control was a story in its own right, and it was still in progress at the end of Sprint 1 because the granularity of the security configuration had not been fully resolved. That is exactly why NFRs need to be surfaced early and treated as first-class backlog items. For a practical reference on how to capture them, see Non-Functional Requirements Template: Defining NFRs for Software Success.
The BA and the Product Owner: Where the Roles Intersect
On smaller Agile projects, there is genuine overlap between the BA and the Product Owner. The Product Owner owns the backlog and is accountable for prioritisation decisions. The BA provides the analysis that makes those decisions possible.
On Project X, the Product Owners were domain experts who understood what teachers needed but were not always available to write stories or maintain the backlog in real time. I filled that gap as the BA, drafting stories and acceptance criteria for their review rather than waiting for them to produce the content themselves. That arrangement works well when both parties have a clear understanding of who makes final prioritisation calls. It breaks down when the BA starts making priority decisions that should belong to the business. The discipline is to produce and advise, not to decide unilaterally what gets built next.
If you are considering whether the BA and Scrum Master roles can coexist in one person, see Can Business Analyst Become Scrum Master: Unlocking Agile Career Paths for Forward-Thinking BAs.
The Challenges You Will Actually Face
- Keeping documentation light without losing rigour. The temptation is to either over-document from Waterfall habit or under-document by misreading Agile principles. The test is always whether the artefact helps the team build the right thing. If yes, produce it. If not, cut it.
- Managing stakeholders who expect a specification upfront. Stakeholders from Waterfall environments often want to see the full requirements before development starts. On Project X, a Business Requirements Specification served that purpose in the pre-build phase, but ongoing work was managed through the backlog. Setting that expectation early avoided conflict later.
- Staying ahead of the developer. In Agile, the BA’s output directly gates the developer’s work. If your stories are not ready, the developer is blocked. That is a different kind of pressure than Waterfall, and it requires a different kind of discipline around your own planning.
- Balancing the BA and Scrum Master roles. On smaller Agile projects, the BA often wears both hats. On Project X, I was formally the BA and the Scrum Master simultaneously. That is manageable, but it requires clear role awareness. When in the Scrum Master role, the job is to protect the team and keep the process running. When in the BA role, the job is to produce the content that enables delivery.
Agile BA Deliverables at a Glance
| Deliverable | Purpose | Typical Format | When Produced |
|---|---|---|---|
| User stories | Define what needs to be built from the user’s perspective | As a / I want / So that in backlog tool | Continuously, ahead of each sprint |
| Acceptance criteria | Define when a story is complete | Attached to each story in backlog tool | Written with each story |
| Refined backlog | Prioritised, sprint-ready queue of work | Managed in Azure DevOps, Jira, or equivalent | Ongoing throughout the project |
| Process maps | Shared model of complex workflows | Visio, Lucidchart, or equivalent | Early sprints, updated as needed |
| Data map | Single source of truth for data fields and sources | Spreadsheet or backlog attachment | Early sprints, updated as build progresses |
| Sprint goal | Focus statement for each sprint | One sentence agreed at sprint planning | Start of each sprint |
| MVP definition | Agreed minimum feature set for first release | Tagged user stories in backlog | Project start, reviewed each sprint |
The Agile BA’s deliverables are fewer in number than in Waterfall but no less demanding to produce well. They are produced continuously, at pace, in close proximity to the team doing the build, and they are only ever as good as your ability to stay ahead of the work. Every artefact you produce in an Agile sprint exists to enable someone else to act, and if it does not serve that purpose in the current sprint, it is probably not the right thing to be producing right now.
Frequently asked questions
What does a business analyst produce in an Agile project?
In Agile, a BA produces user stories with acceptance criteria, a refined and prioritised backlog, process maps where workflows are complex, a data map documenting all system fields, sprint goals, and an MVP definition. These artefacts are produced continuously and just in time to support each sprint, rather than as a comprehensive upfront document set.
Do business analysts still write requirements documents in Agile?
On larger or more complex projects, a Business Requirements Specification is still valuable at the start of a project to establish scope and MVP before the build begins. Once the build is underway, day-to-day requirements are managed through the backlog in user story format. The BRS and the backlog serve different purposes and can coexist on the same project.
How do user stories differ from traditional requirements?
Traditional requirements describe system behaviour in a specification format, often from the system’s perspective. User stories describe what a user needs to do and why, which keeps the focus on user value. Acceptance criteria attached to each story provide the specific, testable detail that a traditional requirement would have included.
What happens to non-functional requirements in Agile?
Non-functional requirements should be captured early and treated as first-class backlog items, either as standalone stories or as acceptance criteria on relevant functional stories. They are frequently overlooked in Agile projects and then become expensive to address late in the build. Surfacing them upfront is the BA’s responsibility.
How does a BA manage changing requirements in Agile?
Through backlog refinement. New requirements or changes are assessed, written as stories if they warrant inclusion, prioritised by the Product Owner, and brought into a future sprint. The discipline is to keep the backlog current and to be transparent with the team about what is changing and why, rather than absorbing changes silently.
Try Ash, Your Virtual BA
The deliverables covered in this article, user stories, acceptance criteria, backlog content, MVP definitions, carry a significant writing and structuring load. Getting the detail right is what separates a sprint that flows from one that stalls. Ash Virtual BA can help you write user stories and acceptance criteria, structure your backlog thinking, and work through the requirements questions that Agile projects demand. If you are mid-sprint and need a sounding board or a solid first draft, Try Ash Virtual BA.
Further reading
- Business Analysis Blog | Why Every Agile Team Needs a Business Analyst | IIBA
- Why Every Agile Team Needs a Business Analyst | IIBA® Business Analysis Blog
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.