If you’re thinking that the Agile methodology doesn’t make clear the business analyst’s job…well, you’re not wrong. However, you may be looking in the wrong place.
Learning Tree’s business analyst in Scrum course follows the Institute of Business Analyst’s when defining the role of “business analyst.” Drawing from the institute’s “A Guide to the Business Analysis Book of Knowledge (BABOK)”, the course says that a business analyst is (emphasis added):
…any person who performs business analysis tasks…no matter their job title or organizational role. Business analysts are responsible for eliciting the actual needs of the stakeholders – which frequently involves investigating and clarifying their expressed desires – to understand underlying issues and causes.
That, of course, isn’t a job — it’s a set of tasks that might be part of several different jobs. What’s easy to lose track of, though, is that these business analyst tasks are essential to maximizing the value of the Agile team to the organization.
The key issue, according to the institute, is that person performing these business analyst tasks “play a role in aligning the designed and delivered solutions with the needs of the stakeholders.” Notice that the analyst isn’t necessarily responsible for designing or implementing a solution. Instead, the business analyst’s job is to ensure that the delivered solution is a real solution for the organization and not just something that the team wanted to build.
For a solution that’s valuable to the organization, an agile team must understand the trinity of problems, issues, and results:
Understanding all three components of this trinity is essential because the team must address the needs of the business both in a way that works and in a way that achieves the organization’s goals.
But, even after devising and developing a solution, these business analyst’s tasks don’t end. The team also should drive the changes required to implement the solutions. Further, these tasks are going to require all the stakeholders to collaborate. That collaboration isn’t going to happen by accident — some level of facilitation is required…which is, again, a business analyst task.
This list of tasks is probably already more than can be performed by one person. As a result, there are probably several people on the team performing these tasks and they may have a variety of job titles, including ‘enterprise architect’ and ‘product owner’ (or even ‘business analyst’).
This relationship between business analyst tasks and the Agile development style isn’t an accident. If you look at the twelve principles of Agile, you can see that most of those principles are directly related to typical business analyst tasks.
These four principles depend on business analysis input:
Another three of the principles of Agile require facilitation, which is a key business analyst task:
In Learning Tree’s course, we go beyond these principles to discuss the concrete tasks that require a business analyst. Those include eliciting requirements (and empowering other members of the team to do the same), managing those requirements, and developing a system of metrics to determine both how successful any solution is and how the team is growing and developing.
Which leads to one job role that seems tailor-made for the business analyst. Once you start discussing requirements management in an Agile environment, you inevitably end up discussing the role of the Product Owner. The Product Owner role only became fully recognized in 2010 in Roman Pichler’s book “Agile Project Management with Scrum: Creating Products That Customers Love.” It’s not an accident that the title of the book that started defining the Product Owner’s role has, as its subtitle, “Creating Products That Customers Love.” The Product Owner is responsible for ensuring that the team is focused on delivering products that have real business value — that address the trinity of problems, issues, and goals. That definition brings us right back to the business analyst playing “a role in aligning the designed and delivered solutions with the needs of the stakeholders.”
Obviously, for a solution to have real business value, return on investment and total cost of ownership must be assessed (another business analyst task). However, value to the organization isn’t just in the numbers. Solutions must also contribute to the organization’s mission, which may involve intangible benefits. An organization that prides itself on software that’s “easy to use” may not be able to quantify the benefits of improving the user experience but does know that constantly improving that experiences is essential to the organization achieving its goals. Again, a business analyst will be conversant with both these quantitative and qualitative metrics.
Because the Agile team always has more potential items it could do than the team can do right now, the Product Owner is tasked with managing that backlog of items. Because those items’ value includes qualitative measures, these items may only have a relative value. While all items may not have an absolute valuable, the team must still know which items are more valuable than other items on the list because of their qualitative value. Only by this ordering of items by their “relative value to the business” can the team to decide what’s the “next right thing” to work on and, as a result, maximize the team’s value to the organization. Again, assessing the value of some item to the business is a business analyst task.
You may not be able to see a “business analyst” job title in an Agile team. But wherever the value of the team to the organization is addressed, someone performing business analyst tasks is going to be required. That opens quite a lot of opportunities for a business analyst, including the critical role of the Product Owner.