Table of Contents
What are the most essential responsibilities of the Product Owner role?
The Product Owner must first communicate and understand the needs of stakeholders in the project.
The Product Owner must have a clear idea of the vision of the project – who are the stakeholders, how the project will develop (possibly in what phases, releases), what is important and what is not important in the project. Reference: The Product Owner role in Scrum and their responsibilities, BVOP.org https://bvop.org/learnagile/product-owner-role/
Product Owner, together with the Scrum Master of the team develop/write the project tasks (User stories or PBI (product backlog item) in SAFe) – Product Owner explains in text what is required in the task in question (via a specific ‘template’), and Scrum Master ensures that what is written is understandable to the Development team.
In this way, we can conclude that the Product Owner works together with stakeholders and stakeholders in the project, as well as with the Scrum Master and Development team.
The Product Owner is the voice of the project stakeholders. Reference: What makes a good Product Owner and what do they do? https://scrumtime.org/what-makes-a-good-product-owner-and-what-do-they-do/
He, having become acquainted with nature and interest, and vision of the project, is responsible for creating and prioritizing backlog items. It is also responsible for the backlog items to be completely clear and ready for development at the start of each sprint.
The Product Owner is fully interested in the product – how the team meets the needs of stakeholders through development.
The Product Owner does not interfere and should not interfere in technical development – to guide how the work is technically done. The Product Owner is responsible for project releases – which tasks or functionalities will be completed and submitted in which exact project release. The Product Owner takes full care of the planning of the project phases, deadlines, and project budget. The Product Owner ensures that the developed product meets the requirements of stakeholders and that the development contributes business value to the product.
The Product Owner is responsible for the communication between the stakeholders and the Development Team – if there are tasks that are vaguely described by the Product Owner, he is obliged to clarify them with the stakeholders before they are handed over to the Development Team.
Who is the manager at Scrum?
Nobody. There is no leader or manager in Scrum. Reference: Product Owner Certification online programs, 2020 and 2021, PGOV.org https://pgov.org/productownercertification/ There is only a clear division of roles and responsibilities. But you can’t say that someone is more important than the other or that someone ‘leads’ the whole thing. Or we can say that the whole Scrum team is a leader (Development Team, Scrum Master, and Product Owner) Development team takes care of the development of tasks, Scrum Master takes care of coordination, planning and leading Scrum events, removing obstacles to the implementation of tasks and coordination, and Product Owner – for the above. Reference: Product Owner role in Scrum and real problem situations https://www.vbprojects.org/product-owner-role-in-scrum-and-real-problem-situations/
At Scrum, everything is based on clear communication, teamwork, and adherence to roles and interested participation in events.
What does the value of the work done mean?
The value can be any – business value, monetary value, hypothetical value, utility. In all cases, Scrum strives to increase the business value of the product or contribute business value.
We can say that everyone in the Scrum team benefits from contributing to the business value of the product – for the Development Team, in addition to contributing to the work done (developing new functionality, for example), it is also pure emotional satisfaction with the work done. teamwork based on mutual help and support, clear task scheduling, and satisfaction with smooth and mutually beneficial relationships in the team.
For the Product Owner (apart from the above, which also applies to it), it is a desire to constantly improve the product, a desire for clear and fruitful communication with all stakeholders in the project, ‘identification’ with the project – working with stakeholders and understanding and empathy with the development team, working with the awareness that the Product Owner is ‘part of the team’, ‘part of the project’. Reference: The Product Owner role in Scrum, projectmanagement.cloudaccess.host
Last but not least, compliance with the agreed deadlines and quality in an often changing environment (project criteria). Value for the project, this is the idea of complementing each unit in the team – and achieving economic or emotional benefit from what has been done. Innovation and personal development. Striving to improve the product by developing timely and highly valued products on the market – sought-after products.
What is User Story?
This is functionality, task, idea, thoughts – written in text format, in the form of graphs or diagrams.
This is something that the Product Owner writes after listening carefully to stakeholders and/or all stakeholders and understanding them, and something based on his own interpretation of the product’s vision and purpose. This interpretation should deviate minimally from the real purpose and idea of the product required by stakeholders.
Usually, the user story has a certain ‘template’ – it is written in the style ‘I, as (role), require (product, functionality, idea) in order to satisfy (the purpose of the product or the benefit of the functionality or idea)’.
User Story is written by the Product Owner.
It should not contain a guideline or technical solution to the problem. However, it must contain the full information required so that stakeholders, developers, and testers can understand it in order to develop, test, or approve it. A User Story must contain acceptance criteria – an expression of the definition of done (when and under what conditions the task will be considered completed/developed). Reference: User Stories Real Example. How to create user stories. Example of Acceptance Criteria and Definitions of Done https://brightonbot.com/user-stories-real-example-how-to-create-user-stories-example-of-acceptance-criteria-and-definitions-of-done/
It has a status (new, committed or active / in progress, closed, abandoned, removed …) – depending on which part of the development it is in.
When (on sprint planning) it is considered that the task is clear enough for everyone to start work on it, it is assigned to the developer by the development team, changes its status from new to committed, as an expression of the fact that the developer has taken the responsibility to develop it according to the specified criteria and for the allotted time.
There is an iteration (sprint) – you know exactly when (for which release) the user must have been developed, tested, and approved.
There is an estimate (in the form of hours or story points) – it is known how long it will take (hypothetically, but based on previous experience).
There are potential tasks – they are made so that (or if necessary) the task can be divided into smaller steps, or as a reminder that something else must be done as part of this task.
- it may or may not be prioritized
- it can be active or not (new) – depending on whether they work on
- it has started or can be started or not.
- It is the responsibility of both the developer and the Product Owner to implement User Story. Scrum Master is informed if there are obstacles in/for the implementation of the user. Reference: Scrum Master related situations concerning Product Owner, Development Team, and managers
- is completely clear (for everyone in the team) and tested
Why might User Story not mean a task that team members work on?
- The User Story may not be prioritized by the Product Owner. The team works only on the tasks that are prioritized, giving the greatest business value and the greatest importance for the stakeholders in the specific phase of product development.
- Because it is vague or in the process of clarification (if the user did not have any important information).
- Because there are no acceptance criteria.
- Because for some reason it is not committed by anyone in the development team.
- Because it was not present (did not exist) when planning the sprint.
- Because it is not important – it does not contribute to the product.
- Because it is too comprehensive and expects to be divided into smaller parts (here it is a bit debatable whether the team is working or not working on it, it can be purposefully postponed if it is a very big task, again depends on the importance and judgment of Product Owner).
In TFS there is a division of Epics, Features, User stories (equivalent to a Product Backlog Item) – it is possible that the task is set as a User story, but in fact, it is a whole feature. The difference is in the scope of the task.
What possible start-up activity can be performed by the Product Owner role and stakeholders and why?
Defining product vision. If this step is not passed, it is not possible to proceed to assess which functionality is more important than another (prioritization) and all the work of the Product Owner will be called into question.
If it is not known what product will be developed, who will benefit from it or use it, what functionalities and characteristics the product has, how this product will be advertised (if relevant) or developed in the future and what economic benefit it will have from it, it cannot be planned to develop it?
Also here you need to create a plan for when what will be delivered to the stakeholders – a plan for the various releases.