The product owner is an ideal. I have experienced this myself as product owner and business analyst in a scrum team. How many organizations have a job title that can cover the role completely? If not, is your organization ready to change in order to fit the scrum method? 
The organization I work in is not but it is still possible for the scrum team to have an efficient product owner. In our team, it was decided to adapt the role to fit our organization by establishing a product owner team in which I as business analyst am a member. This article describes how we established the team. I have put special emphasis on the role the business analyst plays, and I assume that the reader is familiar with the scrum method and terminology. The model described will most likely not fit all organizations but it can serve as an inspiration for others when working with fitting the product owner to their situation.
The structure of the Product Owner team
The scrum team I am part of is responsible for small and medium size development tasks required for supporting new business opportunities, but also for keeping the platform up to date. For example ensuring good performance as the use of the platform expands. The product backlog is quite dynamic with high priority user stories being added with short notice. In our work as a scrum we have particularly benefited from the focus on "working software". This has resulted in greater motivation for the team because we all like to see results, and a better cooperation with business and users since it is easier for both parties to compromise when working with frequent release dates.
Due to the job roles in our organization, and the fact that business and IT sit in different locations, it is not possible for one person to take on the role full time and completely fulfill the product owner's responsibilities. It was therefore decided by management that the scrum teams in our organization should have a product owner team; a business representative, a business analyst and the manager responsible for administering the budget (also the team's HR manager).
In our team we also added two new aspects to the role. One is the subject matter expert. The business representative in the team is very good at prioritizing between the user stories, ensuring coherence with business strategies and managing business stakeholders. However, it is not in his (or anyone else's for that matter) job role to have detailed knowledge about all corners of the platform. Therefore we decided to include subject matter experts - usually end users with detailed business knowledge. They participate in developing user stories within a particular area, and are appointed when it is decided to start grooming a story.
The second aspect is the responsibility of coordinating product owner activities. That is, facilitating meetings in the product owner team, and ensuring that the backlog is up to date, tidy and accurate. In our product owner team there are two monthly meetings; one where we decide what to add to the backlog, and one where we decide which stories we would like to have delivered in the next sprint. On both meetings we discuss which stories to start grooming, and the status of stories that are currently being groomed. We also discuss how we ensure that the right resources both from IT and business are available so the team can actually deliver a given story.
The business analyst's role
I am 50% product owner and 50% part of the team as business analyst. In the daily scrum, the development activities and the demos I participate as a business analyst. In grooming and planning sessions I participate as both product owner and business analyst. According to our scrum coaches the product owner is not part of the team because then you are not able to challenge the team, and the coaches do not recommend the model that we have chosen. However, as long as both you and the team are aware of when you take on which hat, I believe the advantages by far outweigh this risk. The great advantage is that I can cut some corners in the business analysis activities because I have been involved in every part of the process. I often say: "As a product owner, I think it is very important.." or "As a business analyst, I think we need to..." to separate the two roles both for myself and the team.
As product owner I plan the grooming sessions. I also develop the user stories, and ensure that they are ready for planning. The product owner team defines the stories on an overall level, and specific content is developed with input from the team and the subject matter experts. I participate in the planning sessions and clarify questions for planning.
One of the disadvantages with scrum that I have heard mentioned by user experience specialists is that the focus on working software and the pace of development leaves little room for end user involvement. As business analyst and product owner, I am in a position to prevent this in our team. I make sure that end users are involved in the grooming, and if necessary I define user stories with the particular purpose of involving end users. For example, we have a separate user story for every user test that we do.
My other focus area is architecture. Again, the focus on working software can compromise good architecture but I believe that our team has found a good balance. We often release new development in a pilot to a limited number of users, and an important part of this pilot is also to evaluate the architecture. For example, will the tables be able to handle the amount of data expected? If not then we need to have a user story that delivers a better table design before implementing with additional users. I take it on me to argue for this in the product owner team and communicate the consequences of not doing it. The insight required for doing this is obtained in the daily work with the developers in the team.
When defining user stories with the purpose of involving end users or improving architecture it is quite difficult to follow the user story template: "As a ... I want to ... such that I can..." . However, I believe that in focusing on end user involvement and architecture I fulfil my mission as a business analyst; that is bridging the gap between IT and business. It is within these two focus areas that I can deliver competences and insight that the other members of the team cannot offer. And as long as the team is generally committed to delivering working software - the meaning of which is discussed in the team on a regular basis - I am not worried because all formalia is not being followed.
The business representative's role
The business representative decides which user stories to add to the backlog. This is done on a monthly basis or ad hoc if something urgent comes up. All user stories are discussed in the product owner team before being added to the backlog but the business representative has the final word. At this point the user stories are quite high level and can be developed into several user stories once the grooming starts.
The business representative is mainly responsible for accepting deliveries and prioritizing between the user stories. The prioritization is based on his negotiation with the different stakeholders in the business and it is therefore important that he has a good relationship with management in the business. Acceptance of the delivery is done on the demos, of course, and can be done on recommendation from an subject matter expert. He also appoints subject matter experts and other resources required from the business, e.g. testers. He participates in the last hour of the planning of each sprint. During this hour the sprint plan is discussed between team and business representative, and this is his chance to challenge the plan and request any changes. If the product owner team works well, this should not be the course of any controversy. But prioritizations can be changed once the business representative sees what can be fitted into the sprint, or other changes on that level applied.
The resource manager's role
The resource manager of the scrum team is also part of the product owner team but plays a smaller part than the other two. He participates because he needs to be aware of which resources are required to meet the business expectations to the platform. Also, the product owner team works best if they are in direct contact with management in IT as well as in the business, and neither the business representative nor the business analyst has this access. Last but not least he administers the budget for the platform and the status of this is valuable information for the product owner.
The process
When the product owner team was initially established we had a workshop in the team with the purpose of deciding how to work together and share the responsibility. A few of the most important stakeholders also participated. In preparing the workshop I created a large poster where I wrote down all the responsibilities of the product owner. I also added the stakeholders of the team to ensure focus on them as well. On the workshop we discussed each item on the poster to ensure coherent understanding of the meaning of it and wrote the name of the responsible person in the team. Likewise, we talked about the stakeholders and decided who was responsible for managing that stakeholder. During this workshop we identified the need for subject matter experts, and added that to the poster. After the workshop I wrote down the result in a formal agreement approved by all. In the agreement I made sure to use the names and not roles of the members of the product owner team. I do not want the agreement to be generic because if a member of the team is changed, the agreement should be renegotiated.
Author: Line Karkov has a Master of Science in Information Technology from Aarhus University, Denmark. Since 2007 she has been employed as a business analyst in the internal development department of a Northern European group within the banking industry.