What if you do not know what Scrum is?
First of all, you should at least read the Scrum Guide (PDF) and start following it. If you do not follow this guide, then you are doing anything but Scrum. Essentially, the product owner is committed to maximizing the value of the product for the end user. He can delegate his duties to someone from the team, but he alone should be responsible for the result. It should also be the only source of product knowledge for the team. If the developer has a question, he goes only to the owner of the product. He finds out all the details, resolves the dependencies (if any) and agrees further actions with the developer.
What mistakes do Product Owners make in Scrum
Do not use the INVEST method to create User Stories
The essence of the INVEST method is simple and that each User story must meet the following criteria:
I is independent. By the beginning of work on history, all dependencies must be resolved. This rule is sometimes violated. For example, to make 1 tutorial will take 5 points, and then each tutorial will take 2 points.
N is negotiable. The development team should have the opportunity to discuss options for implementing this story. perhaps using the Pareto principle, and do 80% of the work in 20% of the time.
V is valuable. The story must have value to the end user. A button that says “coming soon” is more valuable to the user than abstract architecture.
E - estimable. History must be appreciated. Sometimes, in order for History to remain independent, these dependencies must be resolved. To do this, it is worth introducing the practice of Backlog refinement (or Backlog grooming): often this is an ongoing process during the work on the increment or a separate meeting for the Development Team. During such meetings, the Product Owner presents stories and asks them to evaluate or say what the team lacks.
S - small. The smaller the story, the better. It’s not worth breaking stories into architectural layers (base, backend, client, etc.) - nothing good will come of it, since history will lose its independence.
T is testable. In my practice, getting a stable and developing product without using TDD will not work, so all stories should be testable.
Not friends with Scrum master
Scrum master is a leader-servant. He makes sure that the rules of the game are clear to everyone. He will hold all the rallies, help put Backlog in order, act as a coach and write this article.
Try to implement immediately a big feature
Often, product owners come from companies that do Scrum only in words. And it becomes obvious that they do not understand how to compose User stories: they try to implement them on the same architectural layers or ignore the INVEST method in other ways. It is worth starting with the decomposition of a big feature into small working prototypes - such that you can produce it over and over again, each sprint of work, thereby creating value for the user.
Make a mess in Backlog
When Backlog becomes like a dump of outdated ideas and bugs - this is the saddest thing that can happen to a project. Planning and grooming turns into shifting stories from the bottom of Backlog to the beginning and vice versa. A developer who has free time will not be able to find the current bug to fix it.
Do not plan ahead
Many will not agree, but in Scrum it’s easier to plan ahead. The product owner knows the speed of the team. For example, it is equal to 15 points per week. For a month a team can give out 60 points, for a year - 720 and so on. After all, no one bothers to ask immediately to evaluate the stories in advance and from them already draw up their plans?