When companies begin their agile transformation, one of the first challenges is understanding the new roles necessary to support the initiative. One of the most critical, which is typically a new concept for a company, is the role of ‘Product Owner’. What usually follows from companies is the normal questioning of ‘what makes this Product Owner role different from an Agile Business Analyst?’ The differences are important and, in our experience, understanding them is critical to success.
A Product Owner’s responsibilities, while not completely revolutionary, are generally an amalgamation of multiples roles…business representative, business analyst and project manager, to name a few. The reason behind combining these into one role is supported by our Scrum approach and is designed to provide a level of accountability that generally does not exist in waterfall shops. Since this is a new role, you need to identify the people that have the right potential to develop the skills required. We recommend the Product Owner role be filled by someone from the “business”, not IT. Someone who can be trained and coached to write stories and define acceptance criteria. Also someone who has the full support and understanding from their manager that this person’s commitment to the team will be far greater than anything they’ve experienced in the past. We also recommend the manager offload much of that person’s existing responsibilities.
So why train a Product Owner to write stories and define acceptance criteria, when you already have a business analyst that possesses these skills? It’s all about accountability. If a business resource owns the content of each sprint, there is no opportunity to play the blame game and there is less friction between IT and Product Management. By having this role played by someone in the business, the responsibility for articulating what needs to be built falls squarely on the organization seeking its value, thus creating more alignment and less opportunity for miscommunication.
It is also important to look at the Product Owner’s responsibility to “accept” stories. In every organization we have worked with, no one from IT has true authority to accept stories. Only the business can determine if completed work is acceptable and fit for the purpose. In Scrum there is one person and one person only responsible for defining and accepting stories and I can not stress enough the importance of not dividing up those responsibilities.
Aside from accountability, communication also plays a role. When the Product Owner comes from the business, it’s likely that communication between Product Owners and Product Managers will be more natural and fluid. As a result, the team is more likely to solve problems in a way that aligns with the business goals and there are fewer surprises in sprint demos. A Product Owner that literally “sits” with the development team and reports to the Product Manager can most effectively bridge the gap between business and IT.
So what about your highly skilled, highly valued Business Analysts? In our experience, we’ve seen it work well when an agile business analyst pairs with a Product Owner to help define acceptance criteria. I make an important distinction here between a traditional business analyst and an agile business analyst. They are often two totally different creatures with the latter being skilled in identifying ways to break down large initiatives into smaller pieces that still provide value and identify MVP.
When working with both a Product Owner and an agile BA, they can make sure they are tackling the problem from a holistic perspective. The Product Owner provides a user focus; the agile BA provides a systems focus. So while the Product Owner is vetting out what the user wants and the best way to provide business value, the agile BA is identifying edge-cases, error conditions, dependencies and impacts to other areas of the system and other systems. A good agile BA has a deep understanding of the current functionality of the system and is able to anticipate positive and negative impacts to other areas of the organization.
An agile BA may challenge the Product Owner or Product Manager to define the real business problem to ensure that the team is solving the right problem and will define improvements to business processes, assists decision-makers in gathering information to make decisions and helps quality assurance test solutions and products. An agile BA provides value by identifying the gotchas, helping to identify MVP, mentoring the Product Owners on how to break down features into smaller, cross-functional stories, and asking the right questions, then allowing the Product Owner to provide answers rooted in research and the goals of the larger organization.
There is no doubt an agile BA can provide a great deal of value; however, it continues to be important for the Product Owner to retain exclusive rights to two responsibilities in order to maintain accountability: accepting stories and managing priorities.
The agile BA can verify that a story meets the defined acceptance criteria but only a Product Owner can verify that the story is fit for the purpose. Unless the Product Owner accepts every story before it’s considered done, you will have alignment issues when you get to the Sprint Demo.
Only the Product Owner can manage the team’s priorities in the backlog – and by “manage” it is our recommendation that the Product Owner maintain the stories in the tool that is used by the team. They should be accountable for actually moving the stories in the tool, closing stories that are no longer required, and splitting stories, if needed, to meet MVP. While an agile BA or a Scrum Master can help with these duties, it is important the Product Owner has ownership of the team’s priorities. If they allow others to manage it they will quickly lose sight of all the scope and where the related stores are and when it will be done. They need to be in the details to properly guide the team.
Since the role of the Product Owner is a new role for many organizations we recommended identifying individuals that have these attributes: ability to communicate, a good business sense, ability to make quick decisions, a technical foundation and, most important, someone that can garner trust in both the team and Product Management. Once the right people are identified, we recommend up-front training on the new role, tool training, plus ongoing coaching. We have seen this approach increase overall success, provide for a more adaptable team / cultural environment, and enable the team to maintain the necessary focus.
Ready to start your Agile Transformation?
Download our free white paper now to learn how to leverage the power of experiences and a proven execution engine to both drive business and become more agile.