Business Analyst in Agile vs Waterfall: Role Differences, User Stories vs BRD, and Career Transition

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 BA Role: Agile vs Waterfall

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:

1. Requirements gathering: Conduct stakeholder interviews, workshops, and document analysis to understand what the system needs to do
2. Requirements documentation: Write a comprehensive Business Requirements Document (BRD), Functional Requirements Document (FRD), or System Requirements Specification (SRS)
3. Requirements review and sign-off: Present the document to stakeholders for formal approval. Once signed off, the requirements become the baseline against which the project is measured.
4. Handoff to development: Pass the signed requirements to the development team, who builds the system according to the specification
5. User acceptance testing: Near the end of the project, validate that the delivered system matches the original requirements

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:

1. Continuous discovery: Requirements emerge throughout the project through stakeholder conversations, user feedback, and data analysis
2. User story writing: Capture requirements as user stories with acceptance criteria — lightweight, conversation-focused artifacts
3. Backlog refinement: Regularly review and refine upcoming stories with the development team, adding detail and splitting stories as understanding grows
4. Sprint support: Answer developer questions, clarify edge cases, and validate that delivered features meet acceptance criteria
5. Sprint review feedback: Gather stakeholder feedback on delivered features and incorporate it into future sprint planning

Practice the sprint-level BA skills that distinguish agile analysts from their waterfall counterparts with our Delivery Horizon Activities practice quiz.

User Stories vs Business Requirements Documents

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:

• Business objectives and project scope
• Stakeholder list and organizational context
• Functional requirements (what the system must do)
• Non-functional requirements (performance, security, usability)
• Data requirements and business rules
• Process flows and use case diagrams
• Constraints and assumptions
• Glossary of terms

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:

• Given the user is on the search results page, when they select a minimum and maximum price, then only products within that range are displayed
• Given no products exist within the selected price range, then a "No results found" message is displayed with a suggestion to expand the range
• Given the user clears the price filter, then all search results are displayed again

Key Differences in Practice

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.

Agile Elicitation Techniques for BAs

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:

• Rules: Business rules that govern the story's behavior
• Examples: Concrete scenarios that illustrate how each rule works
• Questions: Open questions that the team cannot yet answer

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:

• Event storming: The team maps out domain events on sticky notes, revealing the business process, commands, aggregates, and policies that the system must handle
• Impact mapping: Working backward from business goals to identify who can help or hinder the goal, what behaviors need to change, and what the team can build to influence those behaviors
• Personas and empathy mapping: Creating shared understanding of user types, their goals, frustrations, and contexts

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.

Transitioning Your BA Career to Agile

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:

• Volunteer for agile teams within your organization: Many companies run both agile and waterfall projects. Request a transfer or cross-team assignment.
• Join open-source projects: Many open-source projects use agile practices. Contributing to issue refinement, writing acceptance criteria, or helping with documentation provides practical experience.
• Take on a side project: Build something (a web application, a tool, an automation) using Scrum or Kanban to experience the workflow firsthand.

Step 4: Get Certified

Certification signals to employers that you have formalized your agile knowledge. The most relevant certifications for transitioning BAs are:

• IIBA AAC: The agile-specific BA certification, ideal if you already have IIBA credentials
• CSPO: Useful if you want to understand the Product Owner role that many agile BAs collaborate with or transition into
• Certified Scrum Master (CSM): Provides deep Scrum framework knowledge
• ICAgile Certified Professional (ICP): A broader agile foundations credential

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.

• Letting go of comprehensive documentation: Waterfall BAs often feel uncomfortable without a complete specification. In agile, you need to trust that requirements will emerge and be refined through the sprint cycle.
• Embracing "just enough" analysis: Analyze enough to start building, not enough to answer every possible question. The sprint will reveal what you missed.
• Working without formal sign-off: In agile, stakeholders validate requirements by reviewing working software, not by signing a document. This feels less formal but provides faster feedback.
• Sharing ownership: In waterfall, the BA "owns" the requirements. In agile, requirements are a team responsibility. The BA facilitates understanding rather than gatekeeping information.