Options:

Alexander Rachmann Jesko Schneider Frank Engel

Product Owner in Scrum

State of the discussion: Requirements Engineering and Product Owner in Scrum


Scrum is today the most discussed method of agile software engineering. The connection between requirements engineering and agile methods itself is a widely discussed topic; the role of the product owner in particular arouses attention. In our view it is time to collect and condense the arguments without choosing a side.

The Scrum Guide defines the role of the product owner as “responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.” On the one hand, this gives the product owner freedom to do his work. On the other, this makes it hard for an unexperienced product owner to live up to the role.

In the RE-community there is consensus that the main activities of RE are the elicitation, documentation (including modeling and formulation in natural language), validation, negotiation and management of requirements. From this perspective, the product owner - as defined in the Scrum Guide - implements some of the RE-activities, but not all. Some activities are spread to other roles, i.e. to the Scrum Master or the development team.

This discrepancy led to arguments regarding the extension of the role of the product manager –leading consultants for requirements engineering have already incorporated services such as “rent a product owner,” “requirements engineering in agile practices” or “product owner as requirements engineer.” Furthermore, arguments for the product owner as a requirements engineer are stated in magazines and blogs. However, the Scrum founders strongly discourage the interpretation of the product owner as a requirements engineer (and by the way, the same holds for the role “business analyst”).

But still, there is no consensus on how to regard requirements in scrum and how the product owner lives up to her role. It is time to sum up the current discussion and elicit the main points of view.

Introduction

The process of software and systems engineering today is a topic of wide and sometimes emotional discussion. The hegemony of classic plan-driven approaches is not beyond controversy any more. Agile approaches seem to take the stage. Requirements Engineering, as one phase (be it as a phase at the start of system development or a concurrent phase) has to adapt to the agile approaches.

Today Scrum is seen as the most promising approach. To the requirements engineer, it is of vital interest to understand how requirements are treated in the scrum framework, especially because problems of handling requirements are named as main reason for developing Scrum [Sutherland 2004]. To this effect we recap how scrum evolved to the modern version, focusing on requirements i.e. the role of the product owner (second chapter). In the third chapter, we discuss alternative ways to define the work of the product owner in respect of RE-activities in Scrum roles. The fourth chapter is a conclusion.

Scrum

From the rugby approach to scrum

Scrum is based on the rugby approach by Nonaka and Takeuchi, published in the mid-80ies. The two did not focus on software engineering, but rather took a substantial look at general product development. Some basic properties of modern scrum go back to this rugby approach: multidisciplinary, self-organizing teams and (organizational) learning as a key point in the development process [Takeuchi and Nonaka 1986, see also Sutherland 2004]. However, Takeuchi and Nonaka did not make a statement on how to connect the project team with the (in RE-terms) stakeholders, except for: “Top management kicks off the development process by signaling a broad goal or a general strategic direction. It rarely hands out a clear-cut new product concept or a specific work plan. But it both offers a project team a wide measure of freedom and also establishes extremely challenging goals.” In his presentation at the OOPSLA ´95 Ken Schwaber introduced the scrum development process and thereby defined the product manager as the leader of the management (concerning a defined project) [Schwaber 1995]. In later releases, this role was shifted to the product owner.

The Product Owner

The current scrum guide defines the product owner as the “sole person responsible for managing the Product Backlog“ and the backlog as the “single source of requirements for any changes to be made to the product” [Sutherland and Schwaber 2013]. According to the IREB´s definition of a requirements engineer, that definitely includes the requirements management activities. However, the IREB understands the role of the requirements engineer as someone who gets her or his information from the stakeholders, i.e. the requirements engineer works based on the pull-principle. In scrum, the product owner “may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item´s priority must address the Product Owner. For the Product Owner to succeed, the entire organization must respect his or her decisions” [Sutherland and Schwaber 2013]. This strongly suggests that the stakeholders have to work based on the push-principle.

In Central Europe this notion is, according to our experience, hard to implement in companies. Most often, product owners do represent a committee and product owner work is based on the pull-principle. But this means that this ‘pull product owner’ is “someone […] between the developers and the person in charge of the product” [Schwaber 2011]. According to Schwaber, the product owner may not be someone who is writing detailed user stories, i.e. a requirements engineer or a business analyst.

However, the problem of implementing the product owner in an organization exists and several strategies have evolved. In the next chapter we will highlight a few that may shine a light on the product owner and her or his requirements engineering activities.

State of the discussion

In practice there are too many variants of product ownership to discuss here. We made a subjective selection of approaches that are inventive and relevant. However, there may be other approaches not known to us that may be as relevant and inventive as those presented. Furthermore, in practice the approaches do not stick to a certain typology. Hybrid forms or evolving forms may be present.

The not-Proxy Approach

The intention of Scrum was to introduce a role that was the direct contact person for the developers. In terms of the discipline Requirements Engineering, the product owner is one of the stakeholders. The activities of eliciting, documenting and modelling the requirements are tasks of the team (“Yet, I do know that someone who is writing perfect user stories is not using Scrum to optimize the job of product management.” [Schwaber 2011]). That means someone in the team without an explicit role has to do the translation of the high-level requirements (“user stories”) to detailed requirements. How this is done is not defined within Scrum.

In picture 1-a) we draw an overview of the roles. The stakeholders (“ST”) are placed at the left as a group of people. They have to push their requirements to the Product Owner (“PO”). The PO is part of the Scrum Team, as is the Scrum Master (“SM”) and the Development Team (“DT”). Someone in the DT may take the role of a requirements engineer (therefore “DT/RE”).

The Scrum Master / Requirements Engineer Approach

Gottesdiener and Gorman describe several approaches in regard to the connection between business analysis and product ownership. Although business analysis and requirements engineering are not the same, both roles have the same need to take a position in the agile worldview. And both (can) support the product owner in her or his work. Gottesdiener and Gorman propose a combination of the business analyst with the scrum master, see the “SM/RE” in picture 1-b. In our case, of course, the Scrum Master would be associated with the requirements engineer: “Great Scrum Masters are facilitative leaders with a diverse set of analysis skills and strong communication and facilitation abilities. In addition, they have a sound understanding of the business domain. [Requirements Engineers] with those strong skills are good candidates for the Scrum Master roles” (Gottesdiener and Gorman 2011). Instead of referring to a requirements engineer, Gottesdiener and Gorman speak of a business analyst or a project manager.
Gottesdiener and Gorman divide the work of the product owner into a strategic and an operative part. The operative part may be done be the scrum master (participate in backlog grooming, specify acceptance criteria for backlog items, review and approve user stories, attend daily standups). Although not explicitly stated by Gottesdiener and Gorman, this suggests a pull-strategy by the Scrum Master / Requirements Engineer.

The Product Manager & Product Owner Approach

Another pull-approach is an interconnected product manager outside of the scrum team. The product owner pulls requirements from the product manager, the product manager understands requirements from the stakeholder. This is, to our knowledge, a widely used practice. How the product manager learns the requirements of the stakeholders may be out of scope from the viewpoint of the Scrum framework. This approach is quite similar to the “über-“Product Owner, proposed by Gottesdiener and Gorman.

The disadvantage of this approach is that the PO does not know the internal strategies and intentions of the customer. This may hinder her or him in optimizing the value of the work of the scrum team.

The Customer Team Approach

A quite innovative approach is the customer team approach, proposed by Sahota. The customer team contains the stakeholders (“gold owner”, users), the product owner and RE-related roles (domain experts, Testers, User Interface designer). The RE-related roles are also part of the Scrum Team. The Scrum Master is not in any of the teams, but rather a serving leader for both teams outside of a team hierarchy.

Abbildung 1 Approaches to product ownership

Conclusion

In our opinion, there is no approach that fits all organizations. If one accepts this as true, it is perfectly clear that the role of the product owner will be interpreted differently. We presented some of the widely discussed approaches to product ownership. However, to our knowledge, none of the above mentioned approaches are empirically safeguarded (a good read on empirical evidences of agile methods: [Janes and Succi 2012]). It seems advisable to choose one approach and determine its usage.

References



Alexander Rachmann

Alexander Rachmann advises companies on the linking business and IT. His strong interdisciplinary knowledge of business administration and computer science enables him to work as an ideal Requirements Engineer, Business Analyst, or System Analyst. He has worked in industries such as e-commerce, healthcare, IT security, and software development. He holds a doctorate degree in economics, master's degrees in computer science and information science and a diploma in business computer science.

Jesko Schneider

Jesko Schneider worked as a consultant with a focus on Business Analysis, Requirements Management and Usability Engineering. He built up consulting services for Requirements Engineering and Usability Engineering in an international consulting company. His industry focus lies on telecommunications. He is a well-known trainer for Certified Professional for Requirements Engineering from the IREB. In his role as Requirements Engineer, Business Analyst, System Analyst or Product Owner, he is always the linkage between business and IT. He holds a degree in media informatics.

Frank Engel

Frank Engel looks back on over 10 years’ experience in project management and Requirements Engineering. Prior to his time as a Partner of the Anforderungsfabrik, he was responsible for an international consulting company as Unit Manager. Topic of his business unit was Requirements Engineering and Management. His role in projects is Product Owner, Project Manager and Requirements Engineer. He studied business information systems. Always linking business and IT!