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.
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
- Jeff Sutherland: Agile Development: Lessons learned from the first Scrum. researchgate.net/publication/251784359_AGILE_DEVELOPMENT_LESSONS_LEARNED_FROM_THE_FIRST_SCRUM, 2004.
- Ken Schwaber, Jeff Sutherland: Software in 30 days. John Wiley & Sons, Inc. 2012.
- Jeff Sutherland, Ken Schwaber: The Scrum Guide. Scrum.org 2013
- Ellen Gottesdiener, Mary Gorman: It’s the Goal, Not the Role: The Value of Business Analysis in Scrum. In: Agile Connection. June 2011. http://www.stickyminds.com/article/its-goal-not-role-value-business-analysis-scrum
- Ken Schwaber: Product Owner not proxies. In: Ken Schwaber´s Blog: Telling It Like It Is. January 2011. http://kenschwaber.wordpress.com/2011/01/31/product-owners-not-proxies/
- Michael Sahota: Customer Team Helps Product Owners Survive. In: agilitrix. March 2010. http://agilitrix.com/2010/03/product-owner-and-customer-team/
- Hirotaka Takeuchi, Ikujiro Nonaka: The new new product development game. In: Harvard Business Review, January, February 1986, p.137-146
- Ken Schwaber: Scrum Development Process. In: OOPSLA 95 Business Object Design and ImplementationWorkshop.
- Andrea Janes and Giancarlo Succi. 2012. The dark side of agile software development. In Proceedings of the ACM international symposium on New ideas, new paradigms, and reflections on programming and software (Onward! '12). ACM, New York, NY, USA, 215-228.
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 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 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!
Comments (3)
This topic is Still relevant today as I see organizations (and teams) still struggling to definitevely define the PO role when it comes to requirements. Even within an organization teams do not necessarily have a standard approach. One reason may be the domain knowledge and experience of the PO as you have pointed out. Maybe there is no definitive role and it is upto each organization (or team) to find that sweet spot. But therein lies the ambiguity which continues even after all these years.
Good article and a very relevant topic. I am currently working within a team resembling the Customer Team - ie. as an RE within a scrum team responsible for representing the business to agile development teams. The exact role of the requirements engineer in this configuration is in many respects, however, still to be defined: how many of the goals and techniques of the IREB syllabus can in fact be applied within the context of a single user story?
Such topics also recently addressed in an IREB white paper (http://www.ireb.org/fileadmin/IREB/Download/Homepage%20Downloads/REandAgile.pdf). However many questions, to my mind at least, remain open here....
Dear Mr. Rogers,thank you for your kind feedback.
In this article we only discussed the role product owner. However, there are a lot of topics aside from roles, e.g. artifacts (user stories, use cases etc.) or techniques. We are confident, that most of the RE-activities can be useful in agile projects. Further research, especially exchange between experts, is the key to the advancement of the discipline.