The business analyst role looks fundamentally different in agile organizations compared to traditional waterfall environments. This guide compares the BA role across both methodologies, explains how user stories replace Business Requirements Documents, covers the elicitation techniques that work best in agile, and provides a practical roadmap for BAs transitioning from waterfall to agile.
Traditional waterfall business analysis centers on comprehensive upfront documentation — creating detailed Business Requirements Documents (BRDs) before any development begins. Agile business analysis replaces this with continuous collaboration, iterative requirements discovery, and lightweight artifacts like user stories and acceptance criteria. Both approaches aim to ensure the right product gets built, but the path to that outcome is fundamentally different.
Students preparing for standardized academic tests can also practice with our Scrum certification practice test 2026, covering the quantitative and analytical reasoning sections tested on exam day.
The agile business analyst and the waterfall BA share the same fundamental goal — ensuring that what gets built solves real business problems and meets user needs. But the way they achieve that goal differs in almost every dimension.
Waterfall BA: The Upfront Analyst
In a waterfall environment, the BA's primary contribution happens before development begins. The typical workflow looks like this:
This approach works when requirements are stable, the problem is well-understood, and the project scope is unlikely to change. It struggles when requirements evolve, user needs shift, or the organization needs to respond to market changes during a long development cycle.
Agile BA: The Continuous Collaborator
In agile, the BA works alongside the development team throughout the entire project. There is no handoff — the BA is a continuous presence, clarifying requirements in real time and adapting the backlog based on what the team learns each sprint. The typical workflow:
Practice the sprint-level BA skills that distinguish agile analysts from their waterfall counterparts with our Delivery Horizon Activities practice quiz.
The shift from BRDs to user stories is one of the most visible changes when a BA transitions from waterfall to agile. Understanding what each artifact does — and does not do — helps you make the transition effectively.
The Business Requirements Document (BRD)
A BRD is a comprehensive document that captures all the requirements for a project or system. A typical BRD includes:
BRDs can run 50-200+ pages for large projects. Creating one takes weeks or months. The strength of a BRD is comprehensiveness — everything is documented in one place. The weakness is that it assumes you can identify all requirements upfront, which is rarely true for complex software projects. By the time the BRD is complete and signed off, business conditions may have changed.
The User Story
A user story is a brief description of a feature from the user's perspective. The standard format is:
"As a [user type], I want [capability] so that [benefit]."
Example: "As an online shopper, I want to filter search results by price range so that I can quickly find products within my budget."
The story itself is intentionally brief — it serves as a placeholder for a conversation between the BA, the Product Owner, and the development team. The detail lives in the acceptance criteria, which define the specific conditions that must be met for the story to be considered complete:
Key Differences in Practice
| Aspect | BRD | User Story |
|---|---|---|
| Length | 50-200+ pages | 1-3 sentences + acceptance criteria |
| Creation time | Weeks to months | Minutes to hours |
| Detail level | Comprehensive upfront | Progressively elaborated |
| Change handling | Formal change request process | Backlog reordering |
| Audience | Stakeholders and development team | Development team (stakeholders see demos) |
| Sign-off | Formal approval before development | PO acceptance after delivery |
| Risk | Requirements may be wrong but costly to change | Requirements validated every sprint |
The user story approach does not mean less analysis — it means the analysis happens continuously rather than all upfront. An agile business analyst may do the same amount of analytical work as a waterfall BA, but it is distributed across the project lifecycle rather than concentrated at the beginning.
Elicitation — the process of drawing out requirements from stakeholders — looks different in agile than in waterfall. Traditional elicitation relies heavily on formal interviews, document analysis, and structured workshops. Agile elicitation adds collaborative, visual, and iterative techniques that are better suited to continuous discovery.
User Story Mapping
User story mapping is a collaborative technique where the team creates a visual map of the user's journey through the product. Stories are arranged horizontally by workflow sequence and vertically by priority. The result is a two-dimensional view of the product that shows what the minimum viable product (MVP) looks like and how the product grows over subsequent releases. This technique is invaluable for sprint planning and release planning because it shows which stories must be completed together to deliver a coherent user experience.
Example Mapping
Example mapping is a structured conversation technique used during backlog refinement. For each user story, the team identifies:
This technique prevents the common problem of user stories that seem clear but have unresolved edge cases. If a story has too many questions, it is not ready for development — the BA needs more elicitation.
Collaborative Modeling
Instead of the BA creating process models or data models alone and presenting them, agile BAs facilitate collaborative modeling sessions where the entire team builds models together. Techniques include:
Continuous Stakeholder Collaboration
The most powerful elicitation technique in agile is also the simplest: continuous, direct conversation with stakeholders. Rather than scheduling formal requirement-gathering sessions, the agile business analyst maintains ongoing relationships with key stakeholders and engages them frequently in short, focused interactions. This includes sprint reviews (where stakeholders see working software and provide feedback), ad-hoc conversations when questions arise during development, and regular check-ins to understand evolving business priorities.
Strengthen your agile elicitation skills with our Agile Elicitation and Collaboration practice quiz — these techniques are essential for both the IIBA AAC exam and day-to-day agile BA work.
If you are a waterfall BA looking to transition into agile roles, the shift can feel daunting. The good news is that your core BA skills — analytical thinking, stakeholder management, requirements elicitation, and problem decomposition — are directly transferable. What changes is the cadence, the artifacts, and the mindset.
Step 1: Learn the Agile Fundamentals
Before you can be an effective agile business analyst, you need to understand agile frameworks at more than a surface level. Read the Scrum Guide (it is only 13 pages), study the principles behind the Agile Manifesto, and understand how Kanban boards work. Pay attention to the "why" behind agile practices, not just the ceremonies and artifacts. The BA who understands why daily standups exist (rapid impediment resolution) contributes more than the one who just knows they happen every morning.
Step 2: Practice Writing User Stories
Take a feature from a past waterfall project and rewrite the requirements as user stories with acceptance criteria. This exercise reveals the mental shift required: instead of describing the system comprehensively, you are describing individual slices of value from the user's perspective. Start with the "As a, I want, So that" format, then focus on writing acceptance criteria using Given-When-Then scenarios. Practice until this format feels natural.
Step 3: Get Hands-On Agile Experience
Reading about agile is not sufficient preparation — you need real experience working in sprints. Options include:
Step 4: Get Certified
Certification signals to employers that you have formalized your agile knowledge. The most relevant certifications for transitioning BAs are:
Step 5: Update Your Resume and Portfolio
Reframe your waterfall experience in agile-relevant terms on your resume. Stakeholder interviews become "continuous stakeholder collaboration." BRDs become "requirements elicitation and user story creation." Process modeling becomes "collaborative modeling and workflow analysis." Highlight any experience with iterative development, rapid prototyping, or cross-functional team collaboration. Employers evaluating agile BA candidates look for adaptability, collaboration skills, and comfort with ambiguity — emphasize these qualities over document-writing expertise.
Common Challenges During Transition
CFA candidates building their financial analysis expertise also use the Real Estate Exam Practice Test 2026 to understand investment property valuation and financial markets.
Yes, though the role looks different from traditional waterfall BA work. In agile teams, the BA facilitates requirements discovery through collaborative techniques, writes user stories with acceptance criteria, participates in backlog refinement, and validates delivered features during sprint reviews. Some organizations combine the BA and Product Owner roles into one position, while others keep them separate with the BA handling detailed analysis and the PO focusing on strategic prioritization. The Scrum Guide does not explicitly name a BA role, but the analysis work it describes is performed by someone on every successful Scrum team — and that someone is often a business analyst.
A Business Requirements Document (BRD) is a comprehensive specification (50-200+ pages) written before development begins, covering all functional and non-functional requirements for a project. A user story is a brief description of a feature from the user's perspective (1-3 sentences) paired with acceptance criteria. BRDs aim for completeness upfront, while user stories are intentionally lightweight and serve as placeholders for conversations between the BA, Product Owner, and development team. The detail in agile emerges progressively through backlog refinement and sprint-level elaboration, rather than being defined entirely before coding starts.
Start by learning agile frameworks (read the Scrum Guide, study Kanban, understand the Agile Manifesto principles), then practice writing user stories by converting past waterfall requirements into story format with acceptance criteria. Seek hands-on experience by volunteering for agile teams in your organization or contributing to open-source projects. Consider certification (IIBA AAC or CSPO) to formalize your knowledge. Update your resume to reframe waterfall experience in agile terms — stakeholder interviews become continuous collaboration, process models become collaborative modeling. The core analytical skills transfer directly; what changes is the cadence, artifacts, and mindset.
The most effective agile elicitation techniques include user story mapping (creating a visual map of the user journey to guide release planning), example mapping (structured conversations that reveal business rules, concrete scenarios, and open questions for each user story), event storming (collaborative domain modeling using sticky notes), and impact mapping (connecting business goals to user behaviors to product features). These techniques emphasize team collaboration and visual communication over individual analysis and document writing. Continuous stakeholder conversation — short, frequent interactions rather than formal scheduled sessions — is the foundation that supports all other agile elicitation techniques.
Yes, but the nature and volume of documentation changes. Agile BAs produce user stories with acceptance criteria, lightweight process sketches, data flow diagrams when needed, and decision logs. They do not typically produce 100-page BRDs or comprehensive specifications. The agile principle "working software over comprehensive documentation" does not mean no documentation — it means documentation should serve a clear purpose and be maintained only as long as it provides value. Many agile BAs also maintain living documents like glossaries, API contracts, and architecture decision records that the team references throughout the project.
Business analysts with agile skills and certifications typically earn 10-20% more than their waterfall-focused counterparts. Mid-level agile BAs in the US earn $80,000-$100,000 compared to $70,000-$90,000 for traditional BAs in similar roles. Senior agile BAs with certifications like the IIBA AAC or CSPO can earn $100,000-$130,000. The premium reflects market demand — the majority of software development organizations have adopted agile practices, creating strong demand for BAs who can work effectively in sprint-based environments. Waterfall-only BA roles still exist in regulated industries (government, defense, healthcare), but the overall market is shifting toward agile.