Product Owner’s duty in Agile oriented product development practices is to be in charge of Product Backlog management of each scrum team. What exactly does that mean?
First and foremost, Product Owner’s responsibility is to maintain the Product Backlog in collaboration with the team and external stakeholders, as well as manage a portfolio of features. However, their duties do not end there. Product Owner must provide organised work to development teams and optimise the items, such as user stories and tasks.
Here’s a list of practices on how to organise the project with Product Backlog.
Product Backlog Know-how
What are the practices to do manage Product Backlog well?
1. Clear vision
To well manage the Product Backlog, a clear vision of the product should be defined. Once it’s done, it’s way easier to help the team to get on board and describe the project in a clear and understandable way. Not sure how to do it correctly and effectively? I recommend checking out Roman Pichler’s explanation.
2. Describe how to manage the Backlog
As I mentioned before, the Product Owner holds the responsibility to maintain the Backlog, but everyone should participate in it and keep it updated. It’s up to the whole team to provide all the necessary input to Product Backlog. By creating a plan on how to manage the Backlog we can easily involve all the team members in that process.
An absolute minimum is to describe (in wiki for instance) what each state of work item means.
3. Create your Product Backlog
Product Backlog is created by adding user stories and their complementary tasks. This process relies on describing the requirements in an understandable way, at the same time showing the purpose of the developer’s work.
So, when your request for quotation consists of a list of requirements, we focus on the work item itself. To define it, perform the following steps:
1. Title
Creating items requires defining an appropriate title. We use a natural scheme:
[view name] + call to action title | feature name related to one main functionality, e.g.
2. Authorization
All collateral and dedicated information (such as frontend item, backend item, dependency item or milestone item) should be described as a tag.
3. Description
Description content should clearly express the needs of business or users and consist of any elements that may support developers in their work. It should represent the perspective of a potential user of the product. That’s the example of the user story’s format:
As a (role), I need (capability), so that (receive benefit).
4. Acceptance criteria
In a nutshell, acceptance criteria can be defined as expected results of a particular Product Backlog item’s implementation and are used as strict guidance and proved by performed tests of application. Informally, the acceptance criteria explain when the work item can be considered done.
5. External link
I personally use separate an “external link” field in the User story description. If I have supplementary materials, examples of solutions that the client likes or data analyses, I link to them in a separate field. In this way, I emphasise the importance of these materials in a clear and obvious way and, almost mechanically, I can support the discussion during planning session.
4. The importance of priority and risk
The aim of Product Backlog is to specify the order. We should prioritise the list of features and requirements. The higher the number, the greater the business value.
The most important responsibilities land on the top of the list, so each team member always knows what to do next. Order of the Product Backlog may be based on priority, value, dependencies, risk or severity (in case of defects).
There are multiple prioritisation techniques. Below I describe the ones I frequently use in my projects:
Walking skeleton
It presents Minimum Viable Product (MVP). It is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components
MoSCoW
The acronym stands for Must have, Should have, Could have, Won’t have requirements. MoSCoW is the simplest and the most popular approach to prioritisation.
Business value
Highly efficient approach if you have a validated business idea. Why? In this technique, it is a stakeholder or product owner who estimates and decides which user stories bring the most financial value.
Technology risks
It consists of prioritising the estimated amount of risk for feature implementation. The approach is to implement the riskiest features first and finish with fully predictable engineering tasks. Unfortunately, as far as I know, there is no such thing as fully predictable engineering tasks. It works if you have a validated business idea or a working product under update.
HiPPO – Highest-paid person’s opinion
Unfortunately, it doesn’t provide enough transparency for team members and can prevent data-driven decision-making. I would therefore recommend it as an additional, complementary method.
5. Refine your Backlog often
Review and prioritise your backlog frequently to:
- define work to do by adding details to work items, if necessary,
- define the acceptance criteria and the definition of done,
- make sure requirements are sized appropriately,
- keep work in order or reorder work to create priority order,
- help your team know what’s most important to deliver next,
- maintain clarity of project purpose,
- track dependencies.
6. Access to Product Backlog gives transparency
As you already know, the Product Backlog is considered a list of items needed to create the product. A good idea is to provide access to all involved parties, such as the management office, product teams, and stakeholders at all times and have sufficient user rights. Besides, in order to make the work more transparent to the stakeholders, it’s advisable to share the Product Backlog with them, so they can continuously check the last status and provide feedback.
Everything Development Team Needs
Product Backlog is used for sharing information, organising work, and much more. What really works well for me, is that I’m fully in control over the Product Backlog.
A well-managed Product Backlog helps your team accelerate development progress. It is also considered as an alternative to detailed documentation in project management agile practices, which serves as a guide for both product teams and business stakeholders.
So, if you don’t need to document the scope and detailed initial requirements or formal approval of documentation phases, it’s the best way to gather all knowledge about the product.
