Who is the product owner of the and what are its duties?
The Product Owner is the liaison between the development team and the customer. Contrary to its dubious name, the owner of the product is not the contractor or the producer of the project. It is a bridge between all the members involved in the project. Scrum is a relationship-based methodology, and the most valuable consistency of the Agile statement to interpersonal relationships is valued more than the documentation. But as mentioned, implementing such relationships between development team members and customers is not an easy task.
Suppose in a project, the development team consists of 8 people. On the other hand, customer representatives should consist of two managers at two different levels and two operators. Communication between these people will require a lot of time and energy and frequent meetings. The communication of each member with each other will eventually turn the meeting into a complex and completely meaningless communication network. There is an easier way to solve this problem in Scrum.
All communications to be established are centrally managed in the role of the product owner. Communication in this way makes things more efficient because the distribution of communication will be more comprehensive and will make other roles more focused on their tasks instead of engaging in a complex relationship. The product owner has four duties, which are described below:
1. Specify software specifications
The most obvious task of the product owner can be considered as needs engineering. The product owner is always looking to identify software requirements during development. He is in constant contact with managers, operators, and other people involved in the project. He also studies organizational documents, charts, and diagrams, and reports discovering the true needs of the software.
The product owner then realizes what the customer expects from the software. It then translates these expectations into the development language, which is the software requirements, and delivers them to the development team. Hence, it goes without saying that the product owner is a development specialist or software engineer.
The only document owned by the product owner is the product backlog. The product backlog is actually the heart of Scrum. Any development action by the development team must be done by changing the items in the product backlog.
The only person who can make changes to the product backlog is the person who owns the product. The product owner, after identifying the needs, prioritizes them and enters them in the product backlog. Backlog items are prioritized and the only person who can prioritize these items is the product owner.
The product owner sees the project from the customer’s point of view, with the difference that, unlike the customer, he shares the same language with the development team. So what he wants from the development team is what the customer expects. He knows what features the software should have, what features are more important, and what features should be implemented faster.
He transfers this knowledge to the development team in a prioritized way in the product backlog. The team cannot interfere in the specifications of the product to be manufactured and is solely responsible for implementing what the product owner has entered.
The product owner guarantees the customer that the required capabilities are implemented correctly and in a timely manner in the software and that the final software has the specified specifications. For this reason, the product owner is always concerned during the development of reducing the product backlog items, or in other words, increasing the capabilities of the software and tries to execute it correctly.
2. Release and sprint scheduling control
Planning for Sprint and Release is one of the most sensitive tasks in Scrum. Its sensitivity is due to the fact that at the end of each sprint and finally each release, a feature must be added to the software. This is done as a team by the Scrum development team, Scrum Master, and product owner. What is delivered to the customer at the end of the release is often determined at the suggestion of the product owner.
The customer has expectations about the software being completed at intervals. These expected time intervals often coincide with the release time intervals. Since the product owner is the guarantor of working software at certain intervals, he always tries to control the release schedule in a way that meets the customer’s expectations. But he is not the only one who decides on this planning.
The product owner must agree with the development team that is primarily responsible for the development. Because the expectations, which are also fed by the customer’s expectations, may be practically impossible, which in turn makes the development team responsible for presenting the work taken at the end of the release, to meet some needs of the soldier.
3. Prepare test cases
The product owner does not simply determine the capabilities that need to be developed. It also explains how these capabilities work. For example, if the software data search feature is one of the features requested by the product owner, he determines how, based on what items, and in what format the search should be performed by the end-user. This allows the development team to implement exactly what the customer wants.
Sometimes an item that the team has implemented after spending a lot of time will not be accepted by the customer. This state of ambiguity is called implementation. To avoid this, the product owner must write down the terms of compliance with customer expectations before implementation so that it is both an agreement document between the team and the customer and a guide on how to build an item.
The team can also test the implemented items based on this document. The terms of the agreement can be stored in plain text with the item, or it can be used as a more advanced model such as a case test. The test cases consist essentially of the text of the conditions, with the difference that their steps are more clearly stated. After completing a case test item for which it is written, it is executed to test the completed capability and to show the extent of its compliance with customer expectations.
The product owner, as the person who has complete control over the software requirements, is responsible for writing the test case. Test cases for an item are usually written and prepared before the item is developed.
4. Two-way communication
It is not the job of the product owner to just transfer the customer’s request and needs to the development team. Rather, he has a duty to have feedback from the development team that also informs the customer of the development team. For example, the client may have a request for a software feature that the development team finds unworkable due to technical constraints. The product owner will notify the customer of such conditions and ask them to reconsider their request.
About KSRA
The Kavian Scientific Research Association (KSRA) is a non-profit research organization to provide research / educational services in December 2013. The members of the community had formed a virtual group on the Viber social network. The core of the Kavian Scientific Association was formed with these members as founders. These individuals, led by Professor Siavosh Kaviani, decided to launch a scientific / research association with an emphasis on education.
KSRA research association, as a non-profit research firm, is committed to providing research services in the field of knowledge. The main beneficiaries of this association are public or private knowledge-based companies, students, researchers, researchers, professors, universities, and industrial and semi-industrial centers around the world.
Our main services Based on Education for all Spectrum people in the world. We want to make an integration between researches and educations. We believe education is the main right of Human beings. So our services should be concentrated on inclusive education.
The KSRA team partners with local under-served communities around the world to improve the access to and quality of knowledge based on education, amplify and augment learning programs where they exist, and create new opportunities for e-learning where traditional education systems are lacking or non-existent.
Professor Siavosh Kaviani was born in 1961 in Tehran. He had a professorship. He holds a Ph.D. in Software Engineering from the QL University of Software Development Methodology and an honorary Ph.D. from the University of Chelsea.
Executive-level IT strategist with over 20 years of experience in successful IT, product management, and business information systems initiatives. Senior liaison and progressive leader with the ability to plan broad-ranging initiatives while understanding impact and requirements from both business and technology perspectives. Strong employee advocate dedicated to aligning staff skills with product needs, and mentoring personnel in growing skills and career paths. Well-versed in a variety of design, development, and project management methodologies (i.e. SAFe Agile/Scrum, Lean Six Sigma, CMMI, UML, etc.), with a talent for guiding business process improvement through the adoption of industry best practices and standards.
Malaysian University of Technology (UTM)— Ph.D. Computer Engineering (Software). Skills:
Organizational Architecture — Implementing Information Structures — Software Engineering — Agent-Oriented Architecture — Software Project Management
