A few years ago I quantified the 4 Quadrants of the Product Owner role as a means of communicating the depth and breadth of the role.
My intention at the time was to provide guidance to agile teams about the level of difficulty in performing within the role. I also had the intent to provide enough nuance so that Product Owners would realize that they typically would need help. That even though Scrum emphasizes a singular Product Owner per team (backlog), that more than one person might be needed to help fill all of the requisite skills and daily chores.
As part of the 4 Quadrants, I bundled the activities of a Business Analyst under the Product Owner role. It doesn’t mean that the Product Owner needs to be a Business Analyst. It just means that they have to either (1) have these skills themselves, or (2) have access to these skills within their team in order to effectively perform their job.
Another Perspective
Recently I came across an article by Jacqueline Blackman that explores both roles. Here’s a link to it: https://www.b2ttraining.com/yin-yang-business-analyst-product-owner-roles/
When I first read the article, I felt that Jacqueline was overemphasizing the BA role and somewhat trivializing the PO role.
To illustrate this point, here’s a snippet from the article. She has two lists of “Shared Activities – High Level Skills.
For the PO, it entails:
- Subject matter expertise related to the people, processes, terms, definitions, and software
- Strategic visioning
And for the BA, it is much more exhaustive:
- Analytical skills to ask the right questions, dissect, organize, translate and cross reference requirements
- Prioritization methods
- Progressive elaboration
- Feature based road mapping
- Effective user stories
- Acceptance criteria definition
- Elicitation techniques
- Facilitation techniques
- Communication styles and techniques
- Negotiation
- Reconciliation and traceability of missing details
- Full coverage of the core components of software design
Clearly a solid Product Owner will have many of the skills that she identifies for the BA. As I read the article, several times I might add, I was getting a bit frustrated with her BA-skewed assumptions.
But then I re-read her closing paragraph and I felt much better. Here it is...
Closing Paragraph
Not only are there times when one person can play both roles, but there are also times when members of the team with various titles can divide and share the roles.
Like most things we talk about around software development, every organization does things differently and the lines are often blurred as to who does what. There are blurred lines between what titles companies use and several different blended/hybrid definitions of roles. Product owners may be called product managers or business owners. The product owner may have the role of project sponsor and/or subject matter expert as well. More and more, it’s less and less about the titles. It’s about the skills and capabilities to create a high performing team.
What is most important to understand is what tasks and responsibilities are generally associated with a particular role, and then determine the best way to make sure you have coverage of those skills on your team.
Wrapping Up
Well said Jacqueline!
I’ve always said that IF a Product Owner is lucky enough to have a BA as a partner, the teams’ results are usually far better.
But if they don’t, that doesn’t imply they can do a sloppy job or ignore BA activity. It just means someone (potentially less skilled) needs to do their best to fill that aspect of the Product Owner role.
I’d also prefer if instead of specifying developer vs. testers vs. BA as functional roles, we simply made them part of the team in our discussions.
Thanks for sharing your thoughts.
Stay agile my friends!
Bob.