Categories: AgileBusiness AnalysisProject Management

Is the BA 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 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? As BAs doing just-in-time BA work. Here are just a few ways the BA can support the agile project:

Help the sponsor and product owner define and articulate the business problem and product vision
Elicit requirements using a variety of techniques, including facilitating cross-functional requirements workshops
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 criteria tends to be difficult for product owners.
Trace user stories to business objectives and the product vision and throughout the sprint to ensure it’s actually been delivered as imagined.
Model the “as-is” and “to-be” business processes.
Model the expected system interactions, particularly when software is being developed.
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.
Create mock-ups of the new user interfaces.
Support the product owner by discussing business and technical impacts of and dependencies related to priority decisions.
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.

If you found this post interesting, you might also enjoy reading Avoiding Conflict Between the PM and BA, Part I and Avoiding Conflict Between the PM and BA, Part II. (You must be a Watermark Learning Member to access this article. Membership is free and allows you to access valuable skill-development tools, such as articles, webinars, eNewsletters and special discounts.)

Elizabeth Larson, PMP, CBAP, PMI-PBA, CSM

Elizabeth Larson, PMP, CBAP, CSM is a consultant and advisor for Watermark Learning/PMA. She has over 35 years of experience in project management and business analysis. Elizabeth has co-authored four books and chapters published in five additional books, as well as articles that appear regularly in BA Times, Project Times, and Modern Analyst. Elizabeth was a lead author/expert reviewer on all editions of the BABOK® Guide, as well as the several of the PMI standards. Elizabeth also enjoys giving presentations, and her speaking history includes repeat keynotes and presentations for national and international conferences on five continents. Elizabeth enjoys traveling, hiking, reading, theater, and spending time with her 7 grandkids.

Next Increasing Chances for Sponsorship Success »

Previous « Scrum vs. Waterfall: The Fight Continues

View Comments

Nuno Santos says:

November 15, 2016 at 5:38 am

Dear Elizabeth,

totally agree!!! I had some discussions that as a BA my role could "disappear" in agile contexts, and several LinkedIn groups discuss this topic as well.

As a BA I had an experience within an agile team, and I did:

- participated in elicitation events (e.g., meetings, workshops)
- specify and model "to-be" requirements (e.g., UML, BPMN)
- "translate" them to user story statements
- mock-up design
- write test plans based on the requirements.

Kind regards,
Nuno Santos