Surviving Without a BA

Mohammad Zolmajd & Lawrence Ludlow, Intelliware Development Inc.

January 10th, 2022 in Blog, Agile

Business Analysis is Important! Now Where is Our BA?

This post focuses on a topic not often discussed in Agile, the role of Business Analysts (BAs) and business analysis on Agile teams. There are several reasons for this—a significant one is that, ideally, requirements are communicated directly from the business to the development team, so there is no need for business analysis. The concept of just-in-time delivery of requirements and close collaboration with those who best understand what is required helps ensure that the team Builds The Right Thing.

However, the ideal model, in most organizations, does not reflect reality. Most teams don’t have direct and timely access to business representatives. And sometimes, knowledge of what needs to be delivered may be spread across multiple business folks, so there isn’t a single point of contact. A BA can take a lot of the “churn” of determining and organizing requirements off of the team’s plate so they can focus on building new functionality.

But what happens if a BA is not available? There are many things a team can do to modify their process and take on more business analysis work to fill the gap. This post provides practical recommendations on measures to help development teams compensate for a role that would be considered essential in many organizations.

A BA can have many responsibilities. However, their primary role is often to run ahead of the development team to gather requirements and liaise between the team and the business. BAs fill the gap between business wants and needs—these are often not the same thing. BAs leverage their skills, knowledge, and experience to convert business requirements into functional specifications that development teams can effectively work with.

But shepherding requirements is often just one part of a BA’s role. They also frequently take on many other responsibilities, including:

  • Acting as a subject matter expert in the business field
  • Thinking critically around user experience (UX) and business use cases
  • Helping balance business priorities with technical and non-functional requirements
  • Clarifying requirements and making sure business needs make sense at a strategic level
  • Helping maintain the Backlog
  • Completing Business Acceptance Testing (BAT) of Stories before handover to Quality Assurance
  • Resolving issues—from triaging new issues to prioritizing, defining, clarifying, and verifying fixes
  • Reviewing completeness and fit of Epics and Features—BAs see the big picture

BAs also often serve as stewards of the planning process because much of what they do is tightly tied to the process. BAs do a great service to their teams by often organizing key process ceremonies such as Backlog Refinement, Iteration Planning, Iteration Kickoff, and Review and Demo meetings.

It’s important to note that much of what BAs do occurs separately from the rest of the team. Because they run ahead of the team, much of their work is done before planning meetings. So, while the rest of the team works from Iteration to Iteration, committing to Stories and delivering them, BAs work independently to ensure that the rest of the team has what it needs when they need it. As a result, BAs are also often experts at multi-tasking and self-organizing.

When a team doesn’t have access to a BA, much of their work moves downstream to the realm of planned iteration work. Developers and QA Analysts become responsible for their current iteration plan and commitment, plus planning and requirements gathering.  

Reasons Why a BA May Not Be Available

There are many reasons why a BA may not be available. Start-ups and small companies may not be large enough to keep a BA busy and justify hiring one. Or, perhaps, they have plans to hire someone but haven’t found the right person. A BA is a highly specialized role that can sometimes be a difficult hire.

In some cases, BAs may work at a company, but there isn’t one available to work with the team because the company is simply short-staffed. Or all of the BAs are committed to other projects. BA’s flexibility and skills often result in them working on multiple projects across many areas of an organization—not always on software initiatives.

Lastly, a team may have a BA, but they aren’t delivering what the development team needs. The BA may be very capable but new to Agile, the business domain, or both, and not equipped to help the team (hopefully, this is a temporary problem). In some cases, the BA may have other project-related responsibilities, such as writing training documentation, and not have time to work with the team on requirements and other responsibilities focused on “upfront” work.

What Happens When There Is No BA

When a delivery team doesn’t have a BA, the team will likely find itself in one of the two following situations:

1. Too much information. The team receives many requests and information via e-mails, text messages and conversations. However, the information tends to be scattered and not cohesive, so it’s not immediately clear what is needed. There are many business requirements, but much work is required to organize them, identify and fill gaps, and translate them into the functional specifications that the team needs.

2. Too little information. The team receives requests, but they are not detailed—in most cases, not much more than a couple of lines of text. More analysis is required to get to the point where the team understands the requests sufficiently to create functional specifications.

In both situations, team members have to organize what information they have and transform it into something they can use for development. This process can take considerable time and effort, especially when knowledge gaps need to be filled to enable development.

Surviving Without a BA

Intelliware teams, over the years, have found themselves in many situations where a BA has not been available to work with them. A key to our teams surviving, even thriving in this situation, is to trust the Agile principles and practices to guide them. A team with a robust process that sticks to it is better equipped to deal with challenges, such as not having a BA, without them becoming roadblocks.

The following sections provide a compendium of tips and advice that our Agile teams have found helpful when they don’t have access to a BA.

Tip #1: Use a Whole-Team Approach to Requirements

The best way to gather requirements when a BA is not available is to take a whole-team approach. Having the whole development team involved with gathering requirements ensures that everyone has shared knowledge of what needs to be built and provides the added benefit of enabling the wisdom of the masses to replace the expertise and experience that a BA brings to the table.

A vital enabler of the whole-team approach is ensuring that all team members are empowered and have access to business representatives outside of the team. The whole-team approach won’t work effectively if team members don’t have easy access to the folks they need to talk to when gathering requirements.

Business representatives will sometimes take exception to multiple development team members approaching them; they may view this as a distraction. In these situations, team members have some responsibility to manage their interactions with the business. One approach is to schedule recurring meetings with the business and have team members prepare agendas and lists of questions in advance. Planning ahead of meetings with business representatives can help with engagement and make them feel that their time is being well utilized.

Tip #2: Minimize Work In Progress

Project teams can alleviate the burden of defining requirements for Stories and delivering them by limiting the team’s work in progress (WIP). One way to do this is to reduce context switching by ensuring that the team works on Stories from a limited number of Epics or Features at one time. Having the team focus on Stories that follow a common thread will also help maintain focus.

Tip #3: Track Work Not Done

Work not done includes Epics and Stories deemed low priority during Backlog reviews plus new requirements identified during development deferred to later. On most teams, work not done is not a concern; their focus is on completing what they have committed to for the current Iteration, and they know that their BA is actively managing the Backlog and keeping an eye on things on their behalf.

Without a BA on the team, there is a risk that something pushed aside will be missed. In these situations, the development team will need to find ways to focus on both their current iteration scope and work that is farther down the Backlog (e.g., deferred, or lower priority). Two ways that a team can tweak their process to do this include:

1. Becoming more active in managing the Backlog, including ensuring that all new work is added to the Backlog and that low priority items don’t drop off the bottom of the list and get lost.

2. Scheduling regular reviews with the whole development team to go over the Backlog. Reviews don’t have to happen every Iteration; once every major milestone, perhaps every two or three months, is sufficient. Note that a review is not the same as refinement; the intent is not to update the Backlog but instead ensure that everyone on the team understands outstanding work.

Tip #4: Use Business Requests to Identify Stories

BAs play a vital role in teams acting as filters and translators to help ensure that the Backlog contains Stories that the team can develop. Without a BA to fill this role, the team may be inclined to put business requests directly into the Backlog as Stories. Poor quality Stories may result because business representatives tend to think more about business requirements than functional specifications, nor are they likely to consider the technical implications of their requests.

The most effective way to maintain a high-quality Backlog when there isn’t a BA available to help manage it is to have the team treat all business requests as possible sources of Stories. Then, through Backlog Refinement, the team will have opportunities to break down the work into both functional and technically sound Stories and add them to the Backlog.

Tip #5: Encourage Face-to-Face and Verbal Communication

When development teams are responsible for defining requirements for Stories and delivering them, they may feel overwhelmed and lean towards indirect communication methods with the business. Relying on e-mails and text messages may feel more efficient because of their asynchronous nature, but it’s a false economy. The most effective way to communicate is always face-to-face or verbally—even if done online using Zoom, Microsoft Teams, a phone call, or other tools. Direct, face-to-face meetings and conversations between the team and business folks will help the developers better understand business needs and pick up information that may be out of context but essential to understand.

One way to facilitate face-to-face and verbal communications is to schedule regularly recurring meetings with the business. These meetings don’t have to be mandatory; it’s okay to skip a meeting if there’s little to talk about at the time. Cancelling or ending a session early is perfectly acceptable. The important thing is to leverage the power of habit by ensuring that the meeting is recurring and on people’s calendars.

Tip #6: Maintain Transparency and Trust

An often overlooked but valuable benefit that BAs provide is collaborating closely with business representatives and earning their trust. This trust can significantly help facilitate the Agile incremental and iterative approach. A business person who trusts the team will be much more willing to negotiate scope and make trade-offs.

Without a BA on board, the development team will have to work to earn the trust of the business themselves. Several ways that they can encourage confidence include:

1. Regularly reviewing completed work so business representatives will know what was completed and how it was implemented.

2. Promptly notifying the business when something changes. Nothing can erode the business’s confidence more quickly than when a team changes something and doesn’t provide an update—nobody likes a surprise. Development teams should treat their Stories as contracts. If something changes, then the Story needs to be renegotiated, and the business needs to be part of the discussion.

3. Starting Stories only when the team is confident that the requirements are well understood and approved by the business. If a Story appears risky from a requirements perspective, it should be deferred to a later Iteration. Short-term, the business may not be happy with a decision to postpone something, but this likely won’t erode their trust in the team nearly as much as the alternative scenario of the team committing to a Story that they later discover they are unable to deliver.

One way to facilitate face-to-face and verbal communications is to schedule regularly recurring meetings with the business. These meetings don’t have to be mandatory; it’s okay to skip a meeting if there’s little to talk about at the time. Cancelling or ending a session early is perfectly acceptable. The important thing is to leverage the power of habit by ensuring that the meeting is recurring and on people’s calendars.

Tip #7: Strive for High-Quality Stories

Many things define a high-quality Story. Without a BA, Story quality becomes a concern to all involved: the developers, QA Analysts, and the business.

Some tips to ensure high-quality Stories include:

1. Story Cards should be written in business-friendly language, and the intent should be clear to both the development team and business representatives

2. The INVEST framework is a valuable tool for defining high-quality Story Cards

3. Detailed requirements need to define, in a clear way, what needs to be delivered. The team should avoid committing to Stories where the requirements are not well understood (see Tip #6)

4. The detailed requirements also need to be clear regarding where QA Analysts need to focus their attention. A set of well-defined Acceptance Criteria will often satisfy this requirement.

Tip #8: Ensure Good Process for Backlog Refinement

Backlog Refinement meetings typically involve the BA and other team members meeting with business representatives to update the Backlog before the next Iteration planning meeting. These meetings occur during the Iteration and don’t involve the whole team, allowing the developers and QA Analysts to complete the Stories committed for the current Iteration. The BA often assumes responsibility for apprising the team of any significant changes to the Backlog during the refinement process.

Without a BA, preparing the Backlog for the next planning meeting becomes a team responsibility. The whole development team should attend refinement meetings so that they have an opportunity to absorb information that normally the BA would communicate to them. The whole-team approach ensures everyone has a shared understanding of the Stories, the overall product direction, what’s in and out of scope, and the background behind any decisions made. Also, effective refinement meetings should include ample opportunities for team members to ask questions and gain clarity when requirements and expectations are not clear. And, when there’s uncertainty, the team should hold off on committing to a Story (or Stories) until everyone feels comfortable with proceeding.

Tip #9: Manage Unclear and Missed Requirements

Implementing a Story often involves much more information than what is documented in the requirements. While documentation is an effective means for communicating functional specifications and creating a record of what was requested and built, it is not full proof.  Written words can be misinterpreted, and the creator can’t document what they don’t know. So, it’s not wise to assume that the requirements documentation contains everything the developers need to know to Build The Right Thing.

BAs play a key role in ensuring that unclear and missed requirements don’t result in issues post-development.  They do this through active collaboration with the developers and business representatives, answering questions, providing context, and clarifying requests. One way to fill this gap when a BA is unavailable is to ensure that the entire development team reviews the requirements before development starts. While multiple reviews can’t wholly replace a BA’s ability to provide clarifications and fill in knowledge gaps during development, at least the team will be able to leverage the wisdom of the masses beforehand to ensure that nothing significant is missed or misinterpreted. Some practical mechanisms to help ensure that the reviews happen include scheduling recurring review meetings, visible checklists, etc.

Large teams create additional challenges with keeping everyone informed and their efforts synchronized. When it becomes difficult for the entire team to review the requirements before starting each Story, the team may be too large. Ideally, a team should contain no more than 5 to 8 developers and QA Analysts.


Not having access to a BA will likely slow a team down because they have to take over analysis work. However, this does not have to hinder their ability to deliver. An experienced Agile development team can effectively fill the gap by using the Agile principles and practices to identify ways to tweak their processes and be effective.

News, Updates, and Insights