At DVT we run regular online events that are focused on the latest technology trends within the IT industry and we invite guest speakers to share their knowledge and insights on various topics. The DVT Insights Events aim to enlighten you, educate you and often, provide a new view on a burning issue within the technology space.

Has Agile killed the Business Analyst?
Willem Botha

Has Agile killed the Business Analyst?

Tuesday, 23 May 2017 13:10

By Willem Botha, DVT

With the ever increasing need for software development teams to react faster and deliver quicker solutions to problems, agile has become an essential framework to follow. That said, what is the role of the Business Analyst (BA) in an agile world and is the BA still needed as part of the team?

Let’s start at the beginning and go back to the basic definition of business analysis. According to the International Institute of Business Analysis (IIBA), a BA is a liaison among stakeholders to understand the structure, policies, and operations of an organisation, and to recommend solutions that enable the achievement of goals.

Thus the BA’s role is not centred on software; it is about suggesting solutions to business problems and enhancing processes. Software can be part of a BA’s recommendations which a stakeholder would then vet and forward on to a product owner for detailed evaluation as a product enhancement.

In agile when we are talking about a BA or agile BA, we are typically referring to the technical BA when software was part of the recommendation already.

Does the agile BA exist?

Let’s have a look at the characteristics of an agile BA according to the agile manifesto:

  • Adaptability: Everyone associated with agile must be adaptable. However, the traditional BA has always needed to adapt to the business process, software development process or even a lack of process.
  • Goal Oriented: The goal is to add value to the organisation by solving business problems. This is true for both the agile BA as well as the traditional BA role.
  • Innovation: The agile BA, as well as the traditional BA, is looking for new approaches to solving the business problem and improvements to the business processes in which the problem exists.
  • Leadership: Being an agile BA or traditional BA means taking the lead in providing solutions to business problems.
  • Empathy: The BA deals with the business sponsor, customers, users, solution team, technical personnel and management. Both the agile BA and traditional BA need to exhibit empathy and understanding for all these roles.
  • Business Oriented: While the agile software development team is focused on the technological issues of producing working software every two weeks, the agile BA needs to provide the business justification. This has always been true for the traditional BA.
  • Anticipation: The agile BA, as well as the traditional BA, must be thoroughly familiar with the problem domain, the business area in which the problem exists and to anticipate positive and negative impacts to other areas of the organisation.

Based on the characteristics listed for an agile BA we can see that there is clearly no difference to the traditional role played by the BA. So if the agile BA does not exist, do we need the business analysis role in agile?

The answer is a definite yes! But, why am I saying this?

Let’s look at what the most successful agile teams have in common:

  • Everyone in the team understands the “Why”.
    • In the agile world, the BA needs to manage the communication channels with business to understand “why we are working on something.”
    • The BA needs to foster a shared understanding, thus a two-way communication flow between development and business.
  • Teams can make faster decisions by getting answers quickly.
    • With distributed teams where product owners sometimes oversee multiple projects, the agile BA understands the product vision to provide the answers to questions from the teams.
    • On smaller teams, the product owner and agile BA role are played by the same person. However, the focus is still on clear communication to all team members.
  • Although the BA role might not exist in the agile team, the skills associated with a BA is still needed.
    • In smaller teams the product owner may have the required BA skills, making the BA role redundant. That said, the product owner role is usually played by the BA.
    • In bigger teams, the agile BA provides the detailed requirements for the different product owners.
  • The development team still needs someone to take the lead in analysing business requirements and facilitating the process with business.
    • Keeping the noise away from the team and providing clear prioritised work for two-week sprints.
  • There’s still a need to facilitate requirement sessions and documenting these requirements clearly.
    • Where detailed requirements are necessary, documentation needs to be based on a set template for the team following Unified Modeling Language (UML) standards.
    • The team decides when detailed requirements are necessary. However, documenting the business requirement is still required for new members joining a team.

Now if we are saying that the role of the BA might not be needed in an agile team - but only the skills associated with the role, are developers able to play this part in the team? I asked the development community I work with to provide me with answers to this, and it was clear that it depends on team dynamic and the size of the project.

Team dynamic
  • If the team has dedicated developers, then they cannot play this role. They have to wrap their minds around difficult technical concepts. They will not be thinking in abstract or general terms and will be busy with the specifics.
    • A representative for the business requirement is still needed. Someone must have a clear singular focus on the business need and guarantee that this prerequisite is solved and achieved.
    • Sometimes if not done correctly, developers will solve problems that do not exist or invent their interpretation of the business requirement.
  • If you have a team of agile people working toward a common goal, where each person does what is best for the project and team at any given time, then yes, the same person who writes code can also perform the function of business analysis.
Nature of the project
  • With bigger projects, the role of the BA is better suited for requirement analysis and documenting these requirements in advance, with the development team left to focus on the work in the current iteration.
  • Conversely, there are smaller projects where the development team could easily just sit with the business owner and understand the full scope of what is needed.

Business analysis should not be focused on software thus falling outside of the agile process. The notion of an agile BA is not new; it is still the traditional role played by the BA. Moreover, once software has been identified as a solution the BA or technical BA role is still needed in the agile team.

The core principles of the BA role still exist and are needed by the team. Agile has merely freed up the BA to be a BA, instead of a technical BA. These core principles are:

  • Facilitate communication and understanding.
  • Set team objectives per iteration.
  • Fill the role of the business owner or Product Owner proxy

The need for quality analysis in a world of increasing change and technological complexity is high. The role of the technical BA does not have to be a particular person. However, the responsibilities of the role should not hamper delivery from a development point of view.

Agile has also changed the way the BA plays his or her role. The amount of analysis has changed - BAs only do what’s necessary, ensuring that there is no waste in the analysis process.

Focus on T-shaped skills

According to, T-shaped skills describe specific attributes of desirable workers. The vertical bar of the T refers to expert knowledge and experience in a particular area, while the top of the T refers to an ability to collaborate with experts in other disciplines and a willingness to use the knowledge gained from this collaboration.

What does this mean for the business analyst? It means being more aware of the customer journey; what problem needs to be solved, why business needs the product and ultimately how customers will use the product.

Finally, influence the team dynamics by working closely with the product owner, development team and business to help establish a shared goal.

At the end of the day, it is the goal and not the role that is important. It is also clear that the business analyst has an essential role to play in an agile world.

DVT 25 Years of Service