Do you want our logo?
Do you want our logo descriptionKnow our brand.
Do you want our logo descriptionKnow our brand.
A while ago, while debating with a teammate about the roles, artifacts and events that exist within Scrum, we realized that there are many doubts about the role of the Product Owner.
As a result of this debate, I have decided to shed some light on this profile and highlight 30 realities about the role of the Product Owner in Scrum.
1. The Product Owner is another member of the Scrum Team. Perhaps the clearest and most obvious, but best not to take anything for granted.
2. It is not the same as a traditional Project Manager.
3. The Product Owner must be a single person, under no circumstances multiple people will share this role or it will be played by a committee. This helps us not only to simplify and streamline communications, but when prioritizing the backlog, no conflicts will be generated.
4. They are not responsible for the progress status of the development during the Sprint, this is the responsibility of the Development Team.
5. They must work together with the Development Team to develop a Sprint Goal. This is carried out in the Sprint Planning and it is likely that the Product Owner comes with a defined business objective but that it must be adjusted along with the Development Team throughout the event.
6. If they work together with multiple teams for the same product, they will only have one Product Backlog, in no case one per team. This will help to have a unique and global vision of the entire product, and also anticipate dependencies.
7. They can not modify the Sprint Backlog, since this is an artifact that belongs to the Development Team.
8. They are the owner of the Product Backlog, nobody, absolutely nobody else can manage this artifact, and they can not delegate its management.
9. Must be the one to monitor and share the progress of the Product Backlog.
10. Is responsible for creating, maintaining and ordering the Product Backlog. They can ask for help from the rest of the Scrum Team. For example, they can ask the Development Team for help writing the Stories and the Scrum Master can help with the best techniques to maintain and sort it.
11. They can update the Product Backlog when they consider. Remember that the Product Backlog is an artifact that is alive therefore it can change continuously (as much as the Product Owner considers).
12. They must ensure that the Product Backlog maximizes the value of the product and represents the needs of the stakeholders. For this, they must encourage feedback not only from stakeholders, but also from the market.
13. They can rely on the Development Team to refine the Product Backlog. This work is very important, because it helps us to anticipate situations, to detail more those PBIs that can be addressed in the next Sprint Planning, identify dependencies ...
14. Must collaborate with stakeholders, user groups and product managers to get them involved and extract ideas to incorporate in the Product Backlog.
15. They can add a catalog by "points of value" to the PBI and order it based on the value that each item contributes to the product. In addition, they must take into account the dependencies among other products, backlog items, areas ... for the ordering of the Product Backlog.
16. They can delegate the User Stories script to the Development Team.
17. They will be in charge of clarifying the requirements of the Product Backlog if the Development Team needs it.
18. They are not responsible for making the effort estimates of the Product Backlog items, but can provide more detail on the definition of the items, helping the Development Team to refine the estimate.
19. They must attend the Sprint Retrospective, as this is the perfect opportunity to inspect and create an improvement plan about the Scrum Team.
20. They must summon the stakeholders to the Sprint Review.
21. They must provide the Sprint Review and in it they must (and can count on the help of the rest of the Scrum Team):
22. They can not change the start or end date of a Sprint. The duration of the Sprint is something that defines the Development Team and must be fixed in time. The Product Owner can not influence this aspect.
23. They can cancel a Sprint as long as the Sprint Goal is obsolete. This situation is extremely abnormal, but it could be the case.
24. They are responsible for the entire life cycle of the product.
25. They are in charge of monitoring the TCO (Total Cost of Ownership) and this entails contemplating all the investments (conception, development, operation and maintenance) to be made in the product
26. They should try to receive feedback from the market by frequently releasing product increments. Something that we constantly repeat is "inspect and adapt" and this is something that can be applied not only to the method of work, but to the product.
27. Must be the one who knows the most about the progress towards the business objective or the launch (of an increase) of the product.
28. Decide when an increase of product to production is released. The Development Team must ensure that this increase meets the needs to be released to production.
29. Must have the ability to decide, to influence the organization and have time. In many occasions we can find that the Product Owner occupies a high position in organizations and this can have a double reading: the positive one is that they will have the capacity to influence the organization and the negative that consequently they will have a complicated agenda and little time.
30. The Product Owner does not choose who or how. It is the Development Team that performs the tasks and chooses how to do it, while the Product Owner indicates what (to do), reflecting it in the Product Backlog with items.
Comments are moderated and will only be visible if they add to the discussion in a constructive way. If you disagree with a point, please, be polite.