Business Analysts And Product Owners

©2015 Dwayne Wright

In many ways, a good business analyst can be a great product owner. Both are responsible for knowing about the goals, requirements and ultimate vision for the product produced by a project. However, there are divergence's between the two roles that appear more often than not. I thought I might take a shot at documenting some of these divergences and please feel free to add your comments to the narrative.

In Agile environments, the product owner creates the vision statement and this becomes a reference point thereafter for everything the Agile team tries to produce. A business analyst doesn't create the product vision but they do document it in the form of business requirements, communicate it, collaborate with ours to get it approved and reference it via traceability for downstream work product. 

In many Agile environments, the product owner is viewed as the primary Subject Matter Expert (SME). A business analyst isn't a primary SME but is a primary subject matter point of contact. The difference between these may seem small on the surface but it can expand greatly below the waterline of your perspective. 

A primary SME will likely leverage their own knowledge and experience, so a single voice is dominant in regards to the overall vision. A business analyst relies on the knowledge and experience of many voices. They embrace viewpoints from these voices that match, differ and even oppose. A gap analysis is one technique in which a business analyst tries to visualize and analyze differences and then work towards a new shared understanding among the many voices. 

A product owner is more likely to add scope to a project than reduce it. Which isn't necessarily a bad thing in Agile environments because there are multiple ways Agile mitigates risks associated with runaway scope. That might sound a bit weird because many people make an assumption that Agile lacks scope management.  

Strong team dynamics, backlog grooming, iteration reviews and even retrospectives are all ways to manage scope that generally can not be found in phase gate systems. 

A business analyst doesn't work to cut scope for traditional reasons. The business analyst is more about quality and less about resource management, costs or schedule increases. However, they can and will classify requirements are invalid if they are not traceable upstream or even downstream within the requirements package. 

For example, lets say that we have a new requirement that the proposed system also needs to give every user a pony. Not just any pony but one that is all white, has a unicorn and emits rainbows as it trots. If a business analyst can trace this requirement back to an approved business case, they will do just that. A good business analyst would also make note of the constraint, associated risks and perhaps some model to show viability (or lack thereof) but they shouldn't knee jerk to cutting this feature for scope reasons.