The business analyst (BA) has played a key role in software development. But within a modern agile context, the role of the BA is less clear, and there is some confusion as to whether the product owner role subsumes that of the traditional BA. Let’s look at the roles the BA can play with agile teams and how to fully leverage their expertise to supplement or augment that of the product owner.
Business analysts (BAs) have played an important role in software development for several decades. In waterfall development, the BA was responsible for eliciting requirements from customers and subject matter experts and writing business requirements documents. Additionally, BAs often participated in or led the formal or informal testing after the development phase was completed.
Fast-forward to agile, and in particular the Scrum framework, and there is no defined role for the BA. The Scrum Guide defines three roles: product owner, ScrumMaster, and development team. Even teams practicing a framework other than Scrum, such as kanban or Scrumban, often stick with these three roles.
So, where does this leave the BA? Is there a role to play for these members of the organization who typically have valuable expertise in the problem domain? Fortunately, the answer is an emphatic yes, though the exact role may vary somewhat from team to team within an organization.
As Roman Pichler points out in his blog on Business Analyst as Product Owner, in some cases, the BA may transition into the product owner role. This is often a natural career move for a BA, but not in all cases. For example, some BAs prefer not to step into the type of leadership and customer-facing role that is required of product owners. These BAs prefer to work in the background in more of a supporting role. They may be full-fledged development team members, often depending on whether they support one or multiple teams. In this role, they will typically pick up some of the responsibilities of the product owner, which could include user story writing and accepting, coordination of user or SME acceptance testing, etc.
But wait: Pichler also warns in his blog to avoid the proxy product owner trap, in which the BA or proxy product owner acts as a go-between the real decision maker and the development team. How do we reconcile this apparent conflict?
The answer ultimately lies in pragmatism, which, as agilists, we should always embrace, because it’s consistent with our mindset. We inspect and adapt to find the best solution to problems, with the understanding that the best solution for one situation may be different from that for another situation. To elaborate, I will provide two examples from groups I have worked with.
The first example is with a set of seven agile teams that support a web platform consisting of several large applications. These teams do not have product owners assigned to the individual teams. Instead, two product managers are responsible for the product roadmap and prioritizing features for releases, in addition to interacting regularly with customers. The day-to-day role normally filled by product owners is supported by a group of five BAs who are responsible for writing user stories and working with the teams on a daily basis.
Effectively, these BAs function much like product owners, albeit without the customer-facing part of the job—and, perhaps more importantly, without the positional authority to make decisions that is typical of product owners. For this reason, it would seem to be less than ideal; however, the BAs’ ability to provide value is based more on their relationships than their position in the organization. Specifically, as the product managers become more comfortable with the BAs’ decision-making and overall understanding of the applications, they provide more autonomy for the BAs to make decisions typical of a product owner. In a similar fashion, the development teams, with time, recognize the BAs as the final authority for most day-to-day questions about user stories and related product decisions.
The second example is with a division of our company that builds and delivers features for their financial services clients’ web applications. They have roughly thirty teams that do this feature development. Each team supports anywhere from one to eight clients, depending on the size of the client and the amount of contracted work. Last year, this division underwent an agile transformation, and each team was assigned a product owner and a ScrumMaster.
Recently, I had the opportunity to visit this division with my colleague Doug Husovsky. We had conducted the training for the agile transformation and were returning to get some feedback on how the transformation was progressing. (Note that this was not cargo cult agile; Doug had the opportunity to spend a few months after the training was completed to regularly visit the division in a coaching capacity.)
When we sat down with a few of the product owners, we learned that they were spending most of their time in conversations with their clients, and they would scramble to find a few hours of time to write user stories just ahead of the next sprint. This is obviously not a winning formula for creating quality user stories. Moreover, these product owners clearly did not have enough time to interact with the development team as needed throughout the day in order to ensure questions were answered promptly as they arose during user story development and testing.
As we walked out of that meeting, it occurred to Doug and me that adding some agile BAs to assist the product owners could be a solution that would ensure the product owners are not the bottleneck in the development process. We were pleased when we ran into one of the site leaders shortly thereafter and learned they were already in the process of implementing this solution. Because the product owners in this example are in a one-to-one relationship with the teams, I’d expect them to maintain most of the ultimate decision-making on product direction, though it’s likely to vary from team to team. Doug and I look forward to following up in a few months to see how well the agile BA model is working for these teams.
In addition to playing the product owner proxy or filling in for some of the product owner responsibilities that have been detailed above, agile BAs can add value to a development team in many other ways.
For example, BAs can assist or play a lead role in many of the product discovery activities that were elaborated on in Teresa Torres’s recent blog What a Good Continuous Discovery Team Looks Like, including qualitative and quantitative data analysis, opportunity assessments, designing product experiments, and much more. Clearly, BAs can support agile teams in many different ways, though the role can and should be dependent on the needs of a specific team or set of teams.
I encourage you to think beyond the traditional duties of the BA in the pre-agile context and instead think about the role in terms of what you and your team really need.