The role of the BA on your software project

Next Mile and Space Cowboy have collaborated on a four-part series about requirements. You can read the first part here. This second article describes what your program’s BA does and doesn’t do.

—

The business analyst (BA) shepherds work through the cone of uncertainty, advancing an idea from its strategic inception to its operation in live infrastructure. BAs navigate the solution domain using information gleaned from the product owner, technical lead, and other sources. BAs often become the right hand of the product owner by transforming high-level directives into actionable work.

The BA’s sensing, analysis, and definition work culminate in criteria—the requirements—that a future solution must meet. These functions can be performed without a dedicated BA role and many teams do so successfully. When teams and organizations grow in size, it can make sense to locate these responsibilities in a specialized role.

The specific responsibilities assigned to the BA will depend largely on the team’s composition, ways of working, expectations of the role, and the capabilities of the person assigned to the role. Generally, a business analyst works through an input stage, a sense-making stage, and an output stage. Often, a BA works all three stages simultaneously.

Input stage duties:

• Elicit current and future state information from technical and business domains.
• Identify stakeholders, decision-makers, approvers, and experts.
• Identify assets, tools, outputs, and audiences.
• Solicit documentation preferences from audiences.

Sense-making stage duties:

• Define the gap between the information available and the information that’s needed.
• Prototype outputs and get feedback from audiences.
• Identify conflicts among stakeholders
• Periodically review outputs for issues and opportunities.

Output stage duties:

• Document the current state as needed to baseline future state conversations.
• Document the future state:
  • Remember BAs, write for your audience, not for yourself!

  • Document collaboratively whenever possible.

• Flesh out issues in a management tool according to team norms:
  • Draft descriptions

  • Gather and mark up screenshots

  • Write acceptance criteria

• Socialize and gather feedback on all requirements artifacts.

Depending on team composition and task distribution, some of these activities may have more emphasis than others for any given BA role. The BA toolset includes elicitation techniques such as workshops and interviewing, sense-making tools such as mental models and visualization techniques, and publishing tactics which depend largely on the toolset available within IT, but also an awareness of what to use, when to use it, and for whom.

The BA should develop rapport with the people in the following roles to understand their objectives and the challenges they face:

• Product owner/manager. The BA should understand their objectives, obstacles, and priorities while keeping them informed of everything they are working on.
• Lead developer. The BA must understand what they need to see in requirements and bring them problems to solve, not just solutions to implement. Where the lead developer has concerns, the BA should ask for feedback.
• Lead QA engineer. A key audience, the BA should gain familiarity with how QA is performed and understand the level of detail needed to support testing.
• UX designer. The BA should pore over designs to understand interaction patterns, identify data-driven and interactive elements, understand application behavior, and identify gaps.
• Scrum master/project manager. The BA should keep the SM and/or PM advised on priorities and work in the pipeline, raising issues that may impact timeline or resource needs. They should support communication by providing details and analysis. In agile environments, they should keep them informed about how the team is operating.
• Non-technical stakeholders (sales, marketing, operations). BA interactions with stakeholders outside the team can vary widely, but the key takeaways should always be objectives and business drivers. BAs will likely support the product owner in delivering communications that balance transparency with brevity.
• Other BAs. Other BAs may be on the same team or adjacent teams. They should align on areas covered and sync up periodically to minimize overlap and gaps. In some environments, we’ve seen BAs share what works and what doesn’t.

Many people mistakenly view the BA role as a production role, but as you see above, it’s primarily an interfacing role. Any BA work done in a vacuum breaks these stakeholders’ link to the project and undermines their buy-in.

Given the broad skillbase and interfacing skills of the typical BA, they frequently cover project capability gaps they shouldn’t. Most often, those are gaps left unfilled by an absent (or incompetent) product owner, technical lead, or UX designer.

Product owner

Product owners should lead stakeholder conflict resolution. Normally (and correctly), they’ll need ammunition from the BA in the form of decision support information, e.g. what the options are, their associated costs/benefits, second-order consequences, etc. That’s where the trouble comes in: the Product Owner often focuses externally on managing stakeholder expectations, monitoring team output, and reporting up, so internal work like settling technical arguments between workstreams lands on the closest substitute, the BA.

Technical lead

While the product owner shields the team from stakeholder interference and the BA defines the solution itself, technical leads focus on implementation in code. Technically-savvy BAs may have the wherewithal to suggest a technical approach, but the tech lead must live with the decision, so BAs must take care not to usurp architectural control. The BA brings technical leads well-defined success criteria for the business’s objectives. How to accomplish them is up to the technical lead.

UX Designer

Although nobody confuses BAs and UX designers in practice, the work of one butts up against the work of the other. The problem isn’t with the partnership of these two roles, but in late-coming requirements changes that impact the design and how those changes get handled. Sometimes last-minute changes can’t be helped, but similar to the problem of designers getting too specific too quickly, the BA/UXer duo can get stuck in a doom loop making round after round of adjustments to high-fidelity design assets. This can be even harder when using an external design partner, especially one trying to move on to their next project.

Practical challenges faced by your BA

Engaging a BA won’t guarantee that ideas march through the cone of uncertainty into user-facing reality. Three challenges surface more than others to block BAs from help teams make meaningful progress:

Just “gathering”

One of the demeaning myths that seems to persist about the BA role is that they simply gather requirements, as though requirements grow on trees. Elicitation—meaning “to draw out though skillful means”—is a more apt term for this activity, but it still does not wholly describe the means by which requirements are acquired. In many cases, the BA is in a position to identify problems and propose solutions. These problems come in many forms such as requirements gaps, requirements conflicts and, more vaguely, the furrowed brow of another team member.

Stakeholder misalignment

Stakeholders may not always agree on what to accomplish or when. The BA is not usually in a position to resolve or defer these conflicts. This can result in ambiguous requirements or requirements that contravene one or more stakeholders’ stated objectives. Since businesses hold product owners accountable for what the team is working on at any given time, the product owner must be able to resolve conflicts with stakeholders in order to preserve forward momentum. The BA can support the product owner in this by identifying where stakeholders conflict and where they don’t.

Agile’s downsides

Agile methodologies were made by and for small teams comprising both tech-savvy business leads and business-savvy technicians. As organizations grow in size, this becomes increasingly difficult to achieve. We compartmentalize out of necessity.

In addition, incremental methods introduce layers of management and requirements communication can turn into a game of telephone. This is often done in the interest of protecting peoples’ time from conversations that are not relevant to their role. While understandable and even appreciated, this approach increases the risk of miscommunication. The BA counteracts these forces by watchdogging the communication itself and by advocating for better communication practices, such as including all relevant parties in meetings.

If you’re in charge of a large engineering project, maintain vigilance against issues to help your BA succeed.

---

Space Cowboy and Next Mile make requirements effective. Reach out to us for software and hardware requirements that make your project more efficient.