The relationship between Product Owner, Business Analyst and Tester
March 3, 2010 2 Comments
In an Agile/Scrum team the Product Owner manages the Product Backlog, a Business Analyst may help further elaborate the backlog. Acceptance Criteria is “one of the” or the output of that elaboration. A Tester may futher define the Acceptance Criteria and write test scripts to verify it. What is the relationship between the three roles? Inseparable, acquaintance or in a love triangle?
My thoughts spring from the fact that I have frequently seen a gap between the tester and BA/Product Owner’s understanding of the requirements. I accept that the BA comes from the business perspective and the tester from the system/specification perspective. How can the two reach the same understanding of what the end system will deliver?
Mashooq Badar 
Given your setup of people above (and I have seen it, just not always that way), I tend to encourage thinking about it this way:
1. The business stakeholders are responsible for figuring out what is important to the business, and communicating those goals with the business analyst.
2. The BA is responsible for figuring out what it means (i.e. quantifying and specifying) to achieve those goals and communicating them with the product owner.
3. The product owner is responsible for determining which of those measurable goals will be addressed with her product. She also validates / collaborates with the BA to assure that those measurable criteria are really measurable.
4. The tester is responsible for assuring that the measurements for the goals are concrete and practical, collaborating with the BA when they need to be modified. The BA then circles back with the stakeholders to assure that the adapted measurements are still aligned with the goals and will (when met) allow the business to achieve those goals.
5. In parallel with tester-feedback, the developers are responsible for assessing the feasibility of the stories / requirements that articulate the goals of the business, and collaborating with the tester to assure that they understand the precise success criteria.
6. The dev team is also responsible for communicating feasibility / cost estimates with the product owner.
7. The product owner is responsible for prioritizing the business need relative to other needs, now that both value and cost (ROI) are understood, and communicating that scheduling (right now, near future, distant future) with the BA.
8. The BA is responsible for assuring that this timing of delivery works for the business stakeholders in the context of the overall business initiatives.
That feels like a “heavyweight process” when written as I did above – but it is not. You should view it as an affirmation of the principle that agile is about conversation not about process.
If you draw it like a flow chart; which you should only do to help someone understand how it works, not as a matter of defining policy and approval gates :); it looks like a mess!
Thanks for asking this great question!
@sehlhorst (on Twitter)
Thanks for this excellent answer to my question Scott.