Basic tools of the Product Owner work

Managing the product backlog

The product backlog is the primary tool of the Product Owner’s work. The Product Owner takes total responsibility for it and cannot delegate it. The Product Owner has to ensure full and smooth flow of information and its clarity. That will help the main stakeholders to understand what is their money spent on, why the team deals with particular tasks, and in what order will they be done. In short – project members, mostly the business team and the development team, must know the current stage of work. The Project Owner has to ensure communication and keep tracking product backlog organized and up-to-date.

Priorities

Prioritization is establishing a hierarchy of the specific requirements in the backlog. This task is important because it has an impact on the sequence of works and helps to understand in what direction the product is heading. Clearly defined priorities represent the strategy chosen by the Product Owner, which is followed to achieve as much value as possible. Priorities also deliver a background to the development team. Thanks to that, the team exactly knows what to expect in the upcoming sprints. It enables to make better decisions in the field of architecture, which results in higher quality of the final product. It is easy to see one of the Scrum pillars: Transparency.

Priority in the product backlog very often takes a simple form: the user story on the top of the backlog is at that particular moment the most important, the one at the bottom  has the lowest priority.

Please note that the importance of requirements and the product strategy are not carved in stone. Like everything else in the projects done in Scrum, they need to be analyzed, confronted with reality, and updated (Scrum’s pillars: Inspection and Adaptation). The Product Owner constantly learns and gathers information about projects, so that is why they have to verify the product backlog and, based on the current knowledge, assess the validity of the adopted priorities. This way, not only they organize the backlog, but they also take care of the efficient use of time and budget. For example, if a particular task drops out of the top 10 to a one-hundredth position, probably there is no need to analyze or estimate it. That time can be used for the user stories with a higher priority.

Defining user stories right

In projects, we can distinguish three basic components:

• Task – the technical aspect, defined directly by the development team. Created and maintained in the sprint backlog.
• User story – it is the description  of requirements prepared by the Product Owner, based on the user perspective. This value-adding component can be implemented within one sprint. It is not always a new functionality.
• Epic – similar to the user story, but its scale and impact are much larger. It is an extensive story (also maintained in the convention of the user perspective), including a large area of the system. It is not possible to implement an epic within one sprint, and that is why it is not subject to estimation more precise than the so-called T-shirt sizing. Before you start working on an epic, you need to break it into smaller user stories that will be included in the estimation process, prioritization, and planning.

While creating user stories and their prioritization, it is worth to  consider the development team competencies. In principle, a Scrum team is  a team of people with interchangeable skills; therefore, particular tasks can be done by a couple of members of this team, though that is not a universal rule. A good Product Owner knows the abilities of their team and takes into account production capacity in specific areas. Therefore, tasks are created in a way that balances the distribution of work in the team. It requires flexibility since, even with the iterative approach, some jobs have to be done in a sequence. In situations like this, you can take the risk, for example, ask front-end developers to work with fake data instead of keeping them waiting until the back-end finishes their job. Of course, there is a possibility that at the integration stage differences needing some correction will reveal. Still, it is a much better solution than idle waiting, which creates unnecessary costs and grows frustration in the team.

Adaptation

Describing components by the Product Owner should not be done excessively and with exaggerated precision. It is important to present an issue and provide crucial information. Once again, Scrum pillars, Inspection and Adaptation, come to the fore. Every day we gain knowledge that helps us better understand the implemented project. This knowledge can change our point of view dramatically, which will result in invalidating  precisely described user stories, and the time spent on them will be a waste.

The role of a Product Owner is managing the backlog continuously and delivering necessary knowledge on time – neither sooner nor later, here the prioritization helps a lot. A properly organized product backlog shows at first glance what should be worked out and defined as a matter of a priority, and what can remain as a little sneak peek.

The measure of a good Product Owner, among other things, is the ability to work with the project scope starting with its definition through prioritizing, to skillful distribution of attention on particular competence areas. Mastering the fundamental rules of backlog management or requirement creation is only the first step in the direction of expanding knowledge and skills that are required of a Product Owner.

Optimization of the value arising from developer work

The Product Owner cooperates with the development team on an on-going basis. However, the Product Owner is not in formal control of them (in opposition to a Project Manager). Product Owner’s job is to deliver answers to key questions and explain all doubts during the implementation of a project. Product Owner can assign this task to another person, but takes responsibility for all the mistakes that might surface because of this delegation. That confirms the actual role of a Product Owner in the project and one-person responsibility. It is consistent with another pillar of Scrum: Transparency. Every member of the team knows to whom turn  a specific question and where to look for support with respect to user stories and the product backlog.

Sound and close cooperation between the Product Owner and the development team is extremely important when there is a risk of a threat to the sprint goal. In that case, the team, together with the Product Owner has to work out changes within the sprint, so its goal will be achieved to the greatest extent possible. It can be done by eliminating low priority tasks or dividing some components and distributing them into the next sprints. The team provides technical support and assistance at the manufacturing side, and the Product Owner controls the business needs.

However, you must bear in mind that the Product Owner should not assign job to individual members of the team, but only have in mind their competencies and let them create value during the whole time of the lasting project.

Summary

Clearly, every seemingly simple issue includes many nuances. Having a reality check, sometimes even a violent one, during project implementation creates additional obstacles. Regardless of time pressure, stakeholders, or the team, you need to remember fundamental rules applicable to a product backlog: it should always be defined, it should have the form of understandable requirements, and ist should have specific priorities assigned. This approach provides a solid basis for process improvement within the project team following the feedback from the team and stakeholders.