Imagine a scene that plays out every day in hundreds of IT organizations around the world. Friday retrospectives where the development team reviews the last sprint and concludes that for the third story in a row, rework was needed because requirements turned out to be incomplete. The Product Owner, buried in stakeholder meetings, did not have time for in-depth analysis of edge cases. Developers, having built the functionality according to what they understood, hear from testers that system behavior does not match business expectations. An entire sprint — two weeks of work by a multi-person team — goes to waste. This is not an exception. This is the norm in organizations that decided the business analyst is a relic of the past and that Agile eliminated the need for this role.
See also
- A comprehensive guide to web application testing: From the basics to advanced strategies
- Accessibility Testing - How to get started with WCAG (Web Content Accessibility Guidlines)?
- 4 key levels of software testing - An expert’s guide
This article debunks that myth. The Business Analyst role in Agile has not only survived the agile revolution but has undergone one of the most fascinating transformations in the history of IT project management. The business analyst has ceased to be a passive requirements gatherer who spent months creating multi-page specifications and has become a strategic value architect — a person who connects business vision with technological realities and ensures that every sprint delivers real value to the end user. In this guide, based on ARDURA Consulting’s experience from over 211 projects, I will show exactly how this evolution unfolded, why the modern BA is an effectiveness multiplier for the entire team, and how to acquire such an expert for your own organization.
Why did traditional business analysis based on large specifications have to die?
To understand who the modern business analyst is, you first need to understand what they moved away from. In the traditional, cascading Waterfall model, the Business Analyst was a central, almost ritualistic figure. Their work consisted of conducting a series of lengthy meetings with stakeholders, gathering all possible requirements, and then pouring them into hundreds of pages of a formal document — the System Requirements Specification (SRS). This document, created over many weeks or months, became the unquestionable bible of the project, then passed “over the wall” to the development team. The analyst’s success was measured by the completeness and precision of this document, not the business value of the final product.
The problem was that this model rested on a fundamentally false assumption — that we can predict the future and precisely define all user needs at the very start of a project. Reality is brutal: the market changes in weekly cycles, competition does not wait, and customer expectations evolve at a speed that no multi-hundred-page document can capture. A specification that was current in January often lost all substantive value by June.
Large specification documents also created a paradoxical effect — instead of facilitating communication, they killed genuine dialogue between business and technology. The development team, receiving a comprehensive specification, assumed that “everything is in the document” and stopped asking questions. Business stakeholders, having handed over the document, washed their hands of responsibility for further decisions. Between the two sides, a chasm of misunderstandings grew that only revealed itself at the first demo — often after many months of work.
That is why the Agile revolution did not build better bridges between business and technology. It filled in the gap entirely. In a world where software development happens in short, two-week iterations and close daily collaboration is the foundation, the analyst’s role of creating large documents “in advance” simply lost its reason for being. But the analyst themselves — the one who could adapt — became more important than ever.
What does the evolution of the business analyst role from Waterfall to Agile look like?
The transformation of the Business Analyst role is not a one-time event but a process that is still ongoing in many organizations. To understand the scale of this change, it is worth looking at it through the lens of specific dimensions of the analyst’s work and comparing the old model with the new.
The primary task of an analyst in Waterfall was to collect, document, and formalize requirements. In Agile, this task has been replaced by continuous discovery of user needs, decomposition of problems into implementable fragments, and facilitation of shared understanding within the team. The analyst stopped being a “mailbox” between business and IT and became an active translator and mediator who helps both sides speak a common language.
The way of working changed just as radically. The traditional BA worked in isolation, locked in their room with documents and diagrams. The modern business analyst is an integral part of the Scrum team — they participate in daily standups, sprint plannings, refinements, and retrospectives. Their work does not end with handing over a document but continues throughout the entire lifecycle of a user story, from idea through implementation to verification.
The planning horizon shrank from months to weeks. Instead of creating a detailed specification for the entire project upfront, the modern BA works in a “just enough, just in time” model — they prepare requirements for one, at most two sprints ahead, accepting that further needs will evolve based on feedback from users and stakeholders.
The measure of success is perhaps the most fundamental change. In Waterfall, BA success was measured by completeness of documentation and conformity of the final product to the specification. In Agile, success is measured by business value delivered to users — whether the product solves real problems and delivers a measurable return on investment. This shift in perspective from “what we wrote in the document” to “what actually helps our customers” is revolutionary and requires an entirely different mindset from the analyst.
What competencies define a modern business analyst in Agile?
In an agile ecosystem, the role of the Business Analyst undergoes a transformation that requires a new set of competencies. Instead of being a single “bridge,” the modern BA becomes a versatile facilitator and accelerator of the entire product team’s work. The table below presents the competency model of a modern business analyst, divided into key areas.
| Competency area | Traditional BA (Waterfall) | Modern BA (Agile) | Impact on team |
|---|---|---|---|
| Requirements gathering | Formal interviews, surveys, document analysis | Story Mapping workshops, Event Storming, contextual interviews | Faster discovery of real needs, fewer false assumptions |
| Documentation | SRS, BRD — hundreds of pages of formal documents | User stories, acceptance criteria, living documentation | Time savings, documents always current |
| Modeling | Use Case diagrams, ERD — created “in advance” | BPMN, Value Stream Mapping, Impact Mapping — created “just in time” | Better understanding of complexity, risk identification |
| Communication | One-directional — from BA to team through documents | Multi-directional — facilitation of dialogue among all parties | Shared understanding, fewer misunderstandings |
| Prioritization | None or formal (MoSCoW in a document) | Active — together with PO, based on data and business value | Team works on what delivers the most value |
| Validation | Post-implementation — acceptance testing at end of project | Continuous — demos, feedback loops, A/B tests | Quick course correction, lower risk |
| Systems thinking | Limited to project scope | Holistic — impact on entire ecosystem, integrations, processes | Fewer integration problems, better architecture |
This competency model shows that the modern business analyst is not a “stripped-down” traditional BA but an entirely new role requiring a hybrid mix of soft and hard skills. They must be able to comfortably talk with the CEO about strategy, with a developer about API structure, and with the end user about their daily frustrations. This versatility is simultaneously the greatest value and the greatest recruitment challenge.
Why is the business analyst a strategic partner to the Product Owner and not their substitute?
One of the most common and most costly misconceptions in organizations transitioning to Agile is: “We have a Product Owner, so we don’t need an analyst.” This is a fundamental error that stems from misunderstanding the scope of both roles. Product Owner and Business Analyst are not interchangeable roles — they are complementary roles that together form a powerful decision-making tandem.
The Product Owner, according to the Scrum Guide, is responsible for maximizing product value and managing the backlog. Their perspective is strategic — they define product vision, set priorities, communicate with stakeholders, and make decisions about what the team should build. This is a role that requires a broad view of the market, competition, and business needs. The problem is that in reality, most Product Owners are overwhelmed with responsibilities — meetings with the board, negotiations with clients, presentations for investors — and physically do not have time to go to a deep level of requirements analysis.
This is where the business analyst steps in as the Product Owner’s right hand. While the PO defines the “what” and “why” at a strategic level, the BA goes to the operational level — conducting interviews with end users, analyzing data, mapping processes, identifying edge cases, and system dependencies. The result of their work is well-prepared, unambiguous user stories with precise acceptance criteria, ready to be picked up by the development team.
In practice, this tandem works like a pair of eyes looking at the same problem from two different perspectives. The Product Owner looks “outward” — at the market, customers, and strategy. The analyst looks “inward” — at processes, systems, data, and technical dependencies. Together they create a complete picture that neither of them can create alone. Organizations that try to combine both roles in one person quickly discover that the quality of one of them dramatically drops — either the PO stops having time for strategy, or requirements arrive in the sprint underdeveloped, generating rework and frustration in the team.
How does the business analyst serve as a process architect and systems analyst?
The second extremely important dimension of the modern BA’s role is systems analysis and process modeling. This is a competency that in the era of digital transformation, multi-system integrations, and complex microservice architectures takes on truly critical significance. The analyst is the person who can look at a problem holistically, understanding how a new functionality will impact existing systems, processes, and data flows across the entire organization.
The modern BA uses advanced modeling techniques such as BPMN diagrams, Value Stream Mapping, and data flow diagrams to visualize complexity and identify potential problems, dependencies, and risks before the development team writes the first line of code. This work is invaluable in integration and modernization projects, where understanding the current state (“as is”) is a prerequisite for designing the target state (“to be”).
Imagine a situation where a company is implementing a new CRM module that must integrate with an existing ERP system, a data warehouse, and three legacy systems. Without a systems analyst who maps all data flows, identifies potential conflicts, and proposes an integration architecture, the development team will discover problems one by one during implementation — which means delays, cost escalations, and frustration on all sides. With an experienced BA, these problems are identified and addressed in advance, allowing the team to work smoothly and predictably.
The business analyst in the role of process architect also serves as a consistency guardian — ensuring that local optimizations in one area do not create new problems in another. This is a perspective that is often lacking from both developers (focused on their module) and the Product Owner (focused on value for the end user). The BA sees the entire ecosystem and can signal risks that escape other team members.
How does the business analyst function in different agile methodologies?
Although Agile principles are universal, different methodologies implement them in different ways, which affects the scope and manner of the business analyst’s work. Understanding these differences is key for organizations that want to optimally leverage BA competencies.
In Scrum, the business analyst is not a formally defined role — the Scrum Guide lists only the Product Owner, Scrum Master, and Developers. In practice, however, the BA most often functions as a key member of the development team or as a close collaborator of the Product Owner. Their work focuses on backlog refinement — preparing user stories, defining acceptance criteria, and leading grooming sessions that ensure every story entering the sprint is “ready for development.” In mature organizations, the BA typically works one sprint ahead of the development team, preparing analytical material for the next iteration.
In Kanban, the BA’s role is more fluid and continuous. Instead of working in sprint cycles, the analyst operates in flow mode — analyzing the next backlog items as free “slots” appear on the Kanban board. The key value of a BA in Kanban is optimizing workflow — identifying bottlenecks, reducing work-in-progress, and ensuring that requirements do not become a bottleneck slowing down the entire system.
In SAFe (Scaled Agile Framework), which is used in large organizations, the business analyst’s role is more formalized and operates at multiple levels. At the team level, the BA performs a similar function as in Scrum. At the program level, they may serve as a Product Manager or System Architect, responsible for analytical consistency among multiple teams working on the same product. At the portfolio level, they support the definition of strategic epics and value stream mapping.
Regardless of methodology, the value of the business analyst remains the same — they are the person who ensures the team is building the right thing in the right way, minimizing waste and maximizing the value of every iteration.
Why is the business analyst a master of facilitation and how does this affect requirements quality?
Facilitation is the competency that distinguishes a truly elite business analyst from an average one. In an agile environment where communication is the foundation of success, the ability to lead workshops, moderate discussions, and build shared understanding within a group becomes a key working tool for the BA.
The modern analyst organizes and leads workshops such as Story Mapping — a technique that allows for visually decomposing the entire product into user stories and identifying the minimum MVP scope. Another powerful technique is Event Storming — a method of collaborative exploration of business processes in which developers, domain experts, and analysts together build a model of business events on a wall covered with colorful sticky notes. These workshops, led by an experienced facilitator, can uncover more about domain complexity in a single day than weeks of traditional interviews.
The BA is also an expert in writing clear, concise, and testable user stories. A good user story is not a description of a technical function — it is a narrative about a user need, written in their language, with precise acceptance criteria that unambiguously define when the story is “done.” Creating such user stories is an art that requires a deep understanding of both business and technology, empathy for the end user, and the ability to express complex concepts in a simple, unambiguous way.
Thanks to these competencies, the analyst eliminates one of the most common sources of waste in Agile teams — unclear or incomplete requirements entering the sprint. Industry research consistently shows that the cost of fixing a requirements error grows exponentially in subsequent phases of a project. An error caught at the analysis stage costs an hour of discussion. The same error discovered in production costs weeks of team effort, loss of customer trust, and potentially millions in losses. An elite BA is the best insurance policy against these costly mistakes.
Why is acquiring an elite business analyst so difficult?
The role of the modern agile analyst is extremely demanding and requires a unique, hybrid mix of competencies. They must combine soft skills — such as empathy, communication, facilitation, and negotiation — with hard skills — such as analytical thinking, systems modeling, technology understanding, and data analysis. They must be able to talk freely with the CEO about strategy, with a developer about API structure, and with a tester about edge case scenarios.
Finding people with such a broad and deep competency profile on the market is one of the most difficult recruitment challenges in the IT industry. Many companies, trying to fill this role, make one of two classic mistakes. The first mistake is hiring someone with a purely business background — a former consultant or financial analyst — who understands business processes perfectly but cannot engage in dialogue with the technical team. They lack understanding of technological constraints, system architecture, and the realities of development work, which means their requirements are either unrealistic or too vague.
The second mistake is promoting an experienced programmer to the analyst position. Such a person understands technology perfectly but often struggles with communicating with business stakeholders, leading workshops, and listening empathetically to users. Their requirements are technically precise but may miss real business needs because they view the problem through the lens of architecture rather than through the lens of user value.
A truly elite business analyst is someone who naturally bridges both worlds. They can build a BPMN process model diagram just as comfortably as they can conduct an empathetic interview with a frustrated user. They understand why the CTO worries about technical debt and can simultaneously explain to the CFO why refactoring will deliver a return on investment within two quarters. There are very few such people on the market, and acquiring them through a traditional recruitment process takes months and often ends in failure.
Why is the business analyst an effectiveness multiplier for the entire development team?
One of the most underappreciated aspects of the Business Analyst role is their impact on the productivity of not one person but the entire team. An elite analyst is what military terminology calls a “force multiplier” — an effectiveness multiplier that elevates the capabilities of every element of the system they work with.
The mechanism of this effect is simple, though its consequences are far-reaching. One outstanding analyst, by providing the team with clear, well-prepared, and unambiguous requirements, eliminates dozens of hours wasted on incorrect implementations, misunderstandings, and downtime. Imagine a ten-person development team working without an analyst. Each developer spends an average of an hour a day clarifying unclear requirements — looking for the Product Owner, writing on Slack, trying to understand what exactly they are supposed to build. That is ten hours a day, fifty hours a week, over two hundred hours a month of wasted senior time, where instead of writing code, they are trying to understand what to write.
Add to that the cost of rework — according to Standish Group data, the average Agile team without a dedicated analyst devotes 20-30% of its throughput to reworking functionality that was built based on incomplete or incorrect requirements. For a ten-person team working at daily rates of 800-1200 PLN net per person, that is hundreds of thousands of PLN annually spent on fixing what could have been done right the first time.
An elite analyst eliminates or drastically reduces both of these problems. They free up the Product Owner’s time, allowing them to focus on strategy instead of explaining requirements. They free up developers’ time, allowing them to focus on what they do best — writing high-quality code. They free up testers’ time by providing precise acceptance criteria that enable writing automated tests even before implementation begins. A single BA can literally double the effective throughput of a team where requirements were previously the bottleneck.
How do you recognize a truly good business analyst during recruitment?
Verifying a business analyst’s competencies is harder than for most technical roles. It is not enough to check whether a candidate knows BPMN notation or can write a user story in the “As a… I want… So that…” format. A BA’s true competencies reveal themselves in complex, ambiguous situations that require combining multiple perspectives.
The first signal of quality is the way a candidate asks questions. An elite analyst, presented with a description of a business problem, does not rush to document requirements. Instead, they ask probing questions — why this problem exists, who is affected by it, what solutions have already been tried, what the consequences of no solution would be. They seek the root of the problem, not its symptoms. If a candidate in a job interview immediately starts proposing solutions instead of asking questions, that is a warning sign.
The second key indicator is the ability to simplify complexity. Ask a candidate to explain a complicated business process to a non-technical person. A good analyst can take a complex, multi-threaded problem and break it down into simple, understandable elements using analogies and visualizations. A candidate who gets lost in technical jargon or cannot adjust the level of communication to the audience will have difficulty in daily work with diverse stakeholders.
The third differentiator is their approach to requirements conflict. In real projects, stakeholders regularly have conflicting expectations — the sales department wants one thing, the operations department another, and the technology team says neither solution is realistic within the given budget. An elite BA does not take sides. They can facilitate constructive dialogue that leads to a solution optimal for the entire organization, even if it is not the solution any individual stakeholder dreamed of.
Finally, pay attention to whether the candidate can speak about success measures in terms of business value rather than in terms of documents they produced. An analyst who boasts about “writing a 200-page specification” instead of “identifying a requirement that saved the client three months of work” is probably still mentally stuck in the Waterfall model.
How does ARDURA Consulting help acquire elite business analysts through the Staff Augmentation model?
At ARDURA Consulting, we treat the role of Business and Systems Analyst with the utmost seriousness because we know from experience how critical and simultaneously how difficult to fill this competency is. For years, we have specialized in identifying, vetting, and delivering the best analytical experts to our clients in a flexible Staff Augmentation model that eliminates risk and shortens acquisition time from months to weeks.
Our selection process for business analysts goes far beyond standard CV review and a recruitment interview. We verify not only theoretical knowledge — familiarity with BPMN notation, requirements techniques, or agile methodologies — but above all practical skills in facilitation, modeling, and solving complex problems. Every candidate goes through a simulation of an analytical workshop in which they must handle ambiguous requirements, conflicting stakeholder expectations, and technological constraints. This allows us to assess how they will perform in a real project environment.
Thanks to a network of over 500+ vetted senior IT specialists and experience from 211+ projects, we are able to deliver the right business analyst within 2 weeks of defining the competency profile. Our experts are productive from day one — they know agile methodologies, can quickly onboard into the client’s domain, and immediately start adding value to the team. A 99% client retention rate confirms that our approach to selecting and vetting analysts works.
By engaging an analyst from ARDURA Consulting, the client does not merely receive an additional employee. They receive an experienced professional who from the first sprint becomes an accelerator of the entire team’s work. They bring battle-tested analytical techniques, help implement best practices, and serve as a mentor for less experienced team members. At the same time, the Staff Augmentation model means the client retains full flexibility — they can scale analytical engagement up or down depending on current project needs, achieving up to 40% cost savings compared to traditional in-house recruitment.
What are the most frequently asked questions about the business analyst role in Agile?
Is a business analyst needed in a small Scrum team?
Yes, though their engagement may be partial. In small teams (3-5 developers), a business analyst can work part-time or serve two teams in parallel. The key is that someone performs the analytical function — ensuring requirements clarity, leading refinements, and maintaining user story quality. In small teams without a BA, these responsibilities fall on the Product Owner or developers, which means either product strategy suffers or coding velocity drops.
What certifications are most valuable for a business analyst?
The most valued certifications are CBAP (Certified Business Analysis Professional) from IIBA, PMI-PBA (Professional in Business Analysis) from PMI, and Agile certifications — PSM, CSPO, or SAFe. However, a certification is merely confirmation of theoretical knowledge. In practice, project experience and facilitation skills are far more important. An elite analyst without certifications is more valuable than a certified BA without real experience in complex projects.
How do you measure a business analyst’s effectiveness?
BA effectiveness is best measured indirectly through impact on the team. Key metrics include rework reduction (percentage of stories returned for revision), team velocity (whether it increases after the BA joins), time from idea to production (lead time), and requirements quality measured by the number of defects resulting from unclear requirements. Direct metrics such as the number of user stories written can be misleading and do not reflect the analyst’s true value.
Will AI replace the business analyst?
AI tools support BA work — they automate documentation generation, data analysis, and pattern detection in requirements. However, key analyst competencies — empathy, facilitation, systems thinking, and mediation between conflicting interests — require deep human understanding of organizational context and interpersonal relationships. AI is a powerful tool in the BA’s hands but is not capable of replacing them in the foreseeable future.
How much does the lack of a business analyst cost a team?
The cost of lacking a BA is most often invisible because it disperses across the entire team — unclear requirements generate additional meetings, incorrect implementations require rework, the Product Owner spends time explaining instead of strategizing. It is estimated that a team without a dedicated BA loses 20-30% of its throughput to these inefficiencies. For a ten-person team with a monthly cost of 150-200 thousand PLN, that means 30-60 thousand PLN per month in wasted resources — many times the cost of hiring one experienced analyst.
Are your development teams struggling with unclear requirements? Is the Product Owner overloaded and lacking time for in-depth analysis? ARDURA Consulting will help you acquire an elite Business Analyst through the Staff Augmentation model — within 2 weeks, risk-free, with quality guaranteed by 211+ projects and 99% client retention.