Please follow
https://madanswer.com for more questions on agile certification
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.
A Tale of Two Agile Organizations
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.
