Seilevel
Back to Blog Home - Requirements Defined
Seilevel Home
Product Ownership

When a company decides, for whatever reason, that Agile is the right idea for them and they are going to go all out to switch over to Scrum as a methodology, the person they usually look to as taking on the new Product Owner roles (POs) are the existing Product Managers (PdMs). This makes all sorts of sense, since the PO represents the needs of the business and has the responsibility to make sure the business value is delivered by the project.  The trick is the PdM is likely already 110% maxed out by their current workload, so they can’t simply switch over to being that available-to-the-Scrum-team, ready to quickly answer questions mode that is expected in Scrum. It is expected and normal for a user story to need clarification during development in an iteration – and the basic Scrum arrangement is to expect the PO to be available to answer questions from the developers.

So, what do we do in anything larger than the simplest organization?  How do we handle the situation where the PO is already overloaded?  The key is to switch our thinking from simply a Product Owner to Product Ownership, where a team of people takes on the responsibilities of assuring business value is delivered. In this sort of team, the Business Analyst (BA), with specialized skills in requirements management and possibly a closer working relationship with the Agile delivery team, plays a pivotal role.

The PO and BA would together be responsible for doing project work such as crafting the definition of done with the Scrum team, gathering requirements and loading the backlog, and grooming the backlog as the project runs.  The PO can have the BA act as proxy in their place with the Scrum team when the Product Owner isn’t readily available.

This cooperative approach requires a tight working relationship between the PO and BA. Communication needs to be on-going. The Product Owner can work the backlog with an eye towards business needs and keeping stakeholders informed and involved, and the Business Analyst can work the backlog with an eye towards having the user stories well-formed and ready for the development team to tackle. Both need to be flexible in responding to change, and both need to be involved in managing the backlog and elaborating the user stories.

The PO may still be haggard, and finding ways to free up enough time for them to effectively work with the delivery teams is always a challenge, but working with BAs to cooperatively manage the requirements and backlog can make projects manageable.