Is the Business Analyst a Product Owner or Tester on Agile Projects?

There have been many articles lately about the role of the BA on Agile projects. Some postulate that the BA role is closest to the product owner. After all, it is often suggested, they reside with and represent the business. They are in the best position to be the final voice when defining and prioritizing requirements. Others believe that the key role for the BA on Agile projects relates to testing. Since they define the requirements, they should complete the appropriate testing processes to ensure the final solution meets the requirements. I believe that neither of these is a business analyst role. That’s not to say that someone with the title of BA cannot play other roles as well. It’s just that when they are playing these other roles, they are not doing business analysis work.

BA as Product Owner.

The role of the product owner is essentially that of the business subject matter expert (SME). Their main accountability on the project is to articulate the vision and define and prioritize product requirements. Their role, as the sponsor’s key delegate, is to make business decisions. The BA has accountability to both the business and the project. On the one hand BAs need to ensure that the end product or service meets the business objectives, and that the requirements are defined completely and correctly. However, they also need to ensure that the end product or service meets the project objectives and that it is delivered within the project constraints. Finally and maybe most importantly, BAs are not decision-makers. They are facilitators, consultants and, hopefully, trusted advisors.

BAs as Testers.

Testing on Agile projects is an essential role. While theoretically the delivery team wears multiple hats, one of which would be that of tester, practically speaking I have seen more instances where outside testers fulfill this role. With the wide-spread use of automated testing tools on many agile projects, it is helpful to pay attention to testing on its own with its own resource(s) devoted to it. It seems to me that, as with any approach, separating both business analysis and testing from development work, makes a great deal of sense.

BAs as BAs.

So where do BAs most effectively fit into an agile project. BAs are most effective doing BA work, but the work needs to be done just-in-time.[1] Here are just a few ways the BA can support the agile project:

1. Help the sponsor and product owner define and articulate the business problem and product vision
2. Elicit requirements using a variety of techniques, including facilitating cross-functional requirements workshops
3. Assist the product owner in developing user stories and the associated acceptance criteria so the delivery team will know when they’re done.  These criteria need to be more complete than, for example, “the order has been placed.” I have found that creating specific criterion tends to be difficult for product owners.
4. Trace user stories to business objectives and the product vision and throughout the sprint to ensure it’s actually been delivered as imagined.
5. Model the “as-is” and “to-be” business processes.
6. Model the expected system interactions, particularly when software is being developed.
7. Look for gaps in data requirements between what is in place and what is needed. Model the data requirements or work with the appropriate people to ensure that the data will support the new solution.
8. Create mock-ups of the new user interfaces.
9. Support the product owner by discussing business and technical impacts of and dependencies related to priority decisions. 
10. Assess how ready the organization is to accept the change.

“Grooming” the Backlog.

So how can BAs do all the things BAs do so well without preventing the team from delivering an increment in short time frames, such as 2-4 weeks? By ensuring requirements are defined completely and correctly before each sprint begins. The BA can work with the product owner and other business and technical SMES as the delivery team completes each sprint. However, the BA is working on requirements for the upcoming sprint, rather than the current sprint.

While many organizations use the term “agile” to mean doing things in a quick and dirty way without adding a layer of business analysis bureaucracy, others have considered the consequences of omitting the role of the BA and are now recognizing the vital role BAs can play.

[1] In the 2010 survey, The State of Business Analysis in Agile IT Practices, participants indicate that “requirements for Agile projects should be immediately consumable by IT project teams. 72% of companies surveyed indicated that requirements should consist of process flows (or visual use cases) or visual story boards in lieu of only textual lists and paragraphs. Requirements that include visual assets (such as business process diagrams, use cases, user interface mock-ups, and data relationships) require less interpretation from project teams and are more accurately leveraged for project direction” (Executive summary p. 4 http://www.requirements.net/2010/06/30/now-available-the-state-of-business-analysis-in-agile-it-projects-survey-report/)

Don’t forget to leave your comments below