Last month, I presented a client-side session called, “What is an Agile Business Analyst (BA)?” At the end, someone asked me about the difference between an Agile BA and a Product Owner (PO), as they seem to inhabit the same territory of identifying and specifying requirements.
Because folks needed to get back to work, I only had time for a quick answer, which was that a PO has the power to change requirements or even redirect the whole course of the project. On the other hand, a BA can only suggest that either of those things might be advisable.
In essence, Product Owners act as customer proxies, so they need to have the power to make decisions. And, as Spider-Man’s Uncle Ben succinctly pointed out, "with great power comes great responsibility".
The typical responsibilities of a PO role include:
- Understanding the problem to be solved and/or the opportunity to be grasped.
- A clear vision of the product to be built.
- Communicating that vision to the development team and anyone else who’s interested and/or impacted.
- Completely committed to delivering the best possible product or solution.
- Being business-centric.
- Being trustworthy and trusted by the development team that they’re a part of, and the customers they represent.
- Working closely with internal and external stakeholders.
- Being available to the development team and stakeholders as required.
- Having business savvy and good business sense.
- Making quick decisions when required and/or necessary.
- Managing the product backlog.
- Helping plan the release.
- Prioritising and elaborating stories for iteration planning.
- Accepting (or not) the stories delivered at the iteration review.
That’s quite a list. Indeed, the PO seems to be a mix of business Subject Matter Expert (SME), Project Sponsor, and BA, with a touch of Project Manager thrown in.
This implies that a PO needs, at least, the following abilities:
- Great communication (written and oral) with technical and business people at various levels, and from various cultural backgrounds.
- Excellent interpersonal skills.
- Ways to think at, and make connections between, varying levels of detail from overall enterprise objectives and strategy, down to individual requirements and acceptance criteria.
- Formal and informal investigation, elicitation, and analysis.
- Formal and informal negotiation and mediation.
- Write well-formed user stories.
- Elaborate user stories with unambiguous acceptance criteria in natural and structured language, such as BDD or pseudocode, models (process, data, functional, decision, state transition, etc.), business rules, decision tables, and simulations such as prototypes or wireframes.
- Formal and informal priority assessment.
- Risk analysis and mitigation planning.
- Planning and management.
- Agile methods and lean thinking.
- Facilitation techniques.
- Formal and informal quality review methods.
Sadly, there isn’t always somebody available with this skillset (though it will become more common the more people attend our Agile training). So what are the bare necessities?
Mike Cohn, co-founder of the Agile and Scrum Alliances, says a PO is usually “a lead user of the system or someone from marketing, product management, or anyone with a solid understanding of users, the market place, the competition, and of future trends for the domain or type of system being developed”. If this is the profile of POs on your projects, then they will need help from you and other team members to supplement their own abilities.
If you can support your Product Owner, it’s to your advantage. POs increase the likelihood of successful Agile development outcomes.
After all, they take the responsibility, on behalf of the business, for articulating and accepting requirements. They also diminish the opportunities for miscommunication, which, in turn, reduces the number of nasty surprises in Sprint reviews.