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.

Tip #10: Review Epics and Features with the Business

Before the team starts on an Epic or Feature (or any large body of work), there should be a formal review with the business. A high-level review will help ensure that the team understands how the work fits into the larger product vision, the key objectives, and what the business hopes to achieve. This recommendation is related to Tip #9 around managing unwritten requirements. Without a BA, extra steps need to be built into the process to ensure that the development team knows the bigger picture beyond what’s written in the detailed requirements.

Tip #11: Hold Regular Team Retrospectives

Regular Retrospectives supports the Agile principle of Continuous Improvement by providing opportunities for the team to inspect their processes and identify improvements.  In the absence of a BA, Retrospectives become even more critical because the team has more processes on their plate. Regular Retrospectives will help ensure that the team can identify opportunities to improve the way they gather and manage requirements.

Tip #12: Task Stories as a Team

Tasking is the process of breaking a Story down into small, concise chunks of work. Tasking is essential because a Story is too large for a team to collaborate on effectively. A Task list provides concrete work items that facilitate team self-organization. A benefit of Tasking is that it serves as a checkpoint to ensure that the requirements are well understood and complete. A team that has difficulty reaching a consensus on a Task list is an indication that the requirements need more work.

When there isn’t a BA available, the entire team should attend the Tasking meeting. BAs often play an essential role during Tasking to help clarify requirements and fill knowledge gaps. Without a BA, the team needs to make an extra effort to self-check that everyone understands the requirements. Having the whole team attend the Tasking meeting helps fill the gap of not having a BA available to facilitate a collective understanding of what needs to be built.

Tip #13: Make Analysis Work Visible

When a team is responsible for gathering requirements for Stories, they should plan the work and build it into their planning process.  Two common approaches include:

1. Treating analysis work as Stories

2. Wrapping the work into Stories as Tasks

With the Stories approach, analysis work is managed like Stories. Analysis Stories are identified where needed and added to the Backlog, assigned to Iterations and considered complete when the functional requirements are ready. A key advantage of this approach is that it facilitates team self-organization around the analysis work, avoiding a common trap of repeatedly assigning requirements gathering to one or two individuals—usually a junior developer or team lead.  But using Stories for analysis work can significantly increase the number of Stories in the Backlog. Also, adding analysis Stories to the Backlog may make requirements gathering work very visible to the business. Business folks may find it challenging to understand dependencies across Iterations. That is, if a Story can’t be delivered until Iteration X+1 because the analysis work first needs to be completed in Iteration X, the business may not be happy with having to wait.

The other approach for planning analysis work is to integrate the effort into Stories as development Tasks. With this approach, all the business representatives will see in the Backlog are Stories for business functions, which, of course, they will be able to relate to easily. However, business folks may question some Estimates for Stories if they include extra effort for analysis. Another disadvantage of this approach is that adding analysis Tasks to Stories creates internal dependencies that could potentially increase delivery risk. If an analysis Task gets bogged down for some reason, then the whole Story will be delayed.

Tip #14: Regular End-to-End Reviews

BAs are often responsible for completing an end-to-end system review when a large chunk of work (e.g. an Epic or Feature) is finished or a milestone is reached. The assessment helps ensure that all the pieces fit together at a high level. BAs are well equipped for this task because they work outside the day-to-day development stream, making it easier to find time for this activity and view the system more holistically.

Without a BA, the development team will need to do end-to-end reviews themselves. The best way to ensure that these checks get done is to treat them as Stories and add them to the Backlog. Review Stories should be assigned to Iterations at significant milestones, for example, when an Epic or Feature is completed. Managing end-to-end reviews as Stories and adding them to the planning process will ensure that they are not missed and that time is allocated for the team to complete them. Additionally, the reviews should be done on pre-production environments with real integrations to external systems in place.

Why not have QA Analysts complete end-to-end reviews if there isn’t a BA available? There are two reasons why this is not a good idea:

1. QA Analysts are less likely to have time because they have a lot on their plates already testing completed functionality and keeping up with the developers. As noted earlier, QA Analysts are more involved in the Iteration planning and delivery cycle. In contrast, BAs work more outside of this cycle and have more flexibility.

2. QA Analysts may not have the holistic view that BAs have.

Tip #15: Use BAT Tasks

Tip #12 recommends that the whole team be involved with Tasking Stories. Many teams add Business Acceptance Testing (BAT) to every Task list. Common Tasks reused on multiple Stories are referred to as boilerplate Tasks—BAT is a common boilerplate Task. BAT involves the BA and business representative(s) meeting to review the functionality for a Story to assess completeness. BAT is usually one of the last tasks completed before a Story is considered development complete and passed on to quality assurance.

Not all teams include BAT in their Task lists—they rely on the BA to monitor progress on the Story and schedule and complete the review on the team’s behalf. Without a BA, however, BAT becomes a development team activity. In these situations, the team should ensure that every Story includes a BAT Task so that this activity is not missed and time is allocated to complete it.

Tip #16: Post-Stand-Up Meetings for Discussions

Most Agile teams have daily Stand-up or Scrum meetings—it’s an easy and effective way to keep team members informed and in synch. When there isn’t a BA and the team is responsible for gathering requirements and other business analysis activities, it’s helpful to supplement the Stand-up with a planned, informal follow-up discussion. The extra meeting time provides an opportunity for team members to collaborate and get up to speed on requirements and other related work. Some teams call this the 16th-minute meeting or discussion (because Stand-up meetings are often time-boxed to 15 minutes).  

Tip #17: Prioritize Review and Demos

Agile teams use feedback in combination with Incremental and Iterative Development to ensure they stay focused on Building The Right Thing and delivering value. Review and Demo meetings are vital for gathering feedback, and BAs play a significant role in recording and assessing input. However, without a BA, there is an increased risk of the development team not receiving all the feedback that they could be. BAs represent an additional set of ears in the meeting to receive input, and they also bring to the table a perspective that is different from the rest of the team. One way to compensate when a BA is not available is to ensure that everyone, the development team and business representatives, understands the importance of the review meetings, that they happen regularly, and that everyone attends.

Tip #18: Leverage the Wider Community

BAs will often tap into an organization’s collective knowledge base outside of the team (the organization’s hive mind) to get the information they need. Within an organization, there are often many unwritten queues that can be helpful that can only be obtained through informal channels. Teams that don’t have access to BA will be handicapped in this respect—they need to be conscious that a broader community within their organization can help them. Wherever possible, specialist groups and subject matter experts should be consulted to provide guidance.

Conclusion

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