Why Product Owner should treat Product Backlog with consideration

“The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.”
-Scrum guide

Meaning, all features Product Owner wants to implement should be included in The Product Backlog. With these requirements - usually written down as user stories - Development Team will know what to deliver.

Incomplete user stories cause delays in development

What can happen if you choose incomplete user stories for the next sprint? When developers start coding new features without all needed data, then they will get stuck while waiting for your clarifications. In many cases gathering missing data requires your consultations with stakeholders. In that situation, you won’t be able to give developers proper answers ad hoc and development will be needlessly delayed.

Without knowing both value and size you won’t build right things in the right time

Suppose you plan to deploy two user stories. After consultations with your stakeholders, you’ve established their business value. At first glance, it may be obvious that development team should work on the most valuable user story first, right? Well... not always. If you don't estimate size (complexity) of planned features, you won’t know how long your team will work on each functionality. Without knowing both value and size you won’t reach the best conclusion. For example, your team could get stuck in building a vast feature, while they could work on delivering few smaller user stories instead.

Broad requirements in user stories make estimations too unpredictable

Even though you can see benefits of estimating user stories, you could still be incapable of doing it properly. One reason of unpredictable estimates is having too broad requirements in one user story. If you don’t divide big chunks of requirements into small coherent user stories, the development team could experience more problems with their evaluation. It’s much easier for developers to make estimations when requirements are written down as several small user stories. For example: in most cases, functionality of shopping cart will be probably too complicated to keep in one user story.

Business pressure leads to technical debt

If you put too much pressure on releasing new features, dealing with technical debt can be moved to the second plan. Meaning, you won’t be able to allocate enough time for bug-fixing or code refactoring. This leads to numerous issues such as slowing down the pace of the development team or losing the stability of your product. 

As you can see, if you do not spend enough time on Product Backlog management, it can entail numerous unwanted problems. Nonetheless, if you include few handy habits into your workflow, you can avoid redundant delays, uncertainty, and technical debt, and ensure that you build right things in right time.

5 steps to keep your Product Backlog in good shape

1. Gather stakeholder’s requirements. First of all, as a Product Owner you are responsible for gathering feedback from stakeholders. It requires communication with management, customers, and all other people who may have an influence on your project or are interested in it. In addition to collecting requirements, you should understand value of suggested features.
2. Write down user stories. Based on all gathered data, proceed to write down user stories. These should contain main objectives and acceptance criteria. Even though Product Backlog doesn’t always have to be filled with only fully described user stories, each of them have to be complete before development team starts their work.
3. Estimate complexity. With the participation of development team, define the size of each user story. However, you don’t have to define exact time needed to develop each feature. Instead, developers can compare user stories and assign them numerical value when it comes to their difficulty. For example, the easiest story will be marked with 1 point, while the most complex one will get 10 points. After few completed sprints you will be able to establish a range of how many story points your team delivers in each sprint.
4. Define the importance of bugs and refactoring. Collect all data about existing bugs or possible code-refactoring from development team. Try to learn which ones are worth doing in the nearest future and which can wait. Also, try to deeply understand what benefits such work could bring to the product and what would be the consequences of leaving it untouched.
5. Sort items in the Product Backlog. After performing all actions described above, you can advance to sorting the user stories and other Product Backlog items. With acquired knowledge, you will be able to make the best decisions. Even though size, value, and all additional data should help you with sorting the product backlog items, it still is a bit of a guessing game. You can only be sure of the accuracy of your decision if you often release new versions of your product and gather feedback from your customers.

To get the best results try to perform all of these 5 steps in every sprint. With this routine, you’ll obtain the best results in the development of your product. Lastly, I’ve described three additional aspects, which every Product Owner should bear in mind:

Product Backlog is living artifact

It would be not effective to arrange product backlog just once or even very rarely. Agile Manifesto states that responding to change is more valuable than following a plan. If you often release a new version of your product, you can gather feedback from real users and react fast. Product Backlog as living artifact gives you the opportunity to quickly satisfy demands of the market.

Product backlog should be managed during the whole product lifecycle

Although crucial part of work is usually done in the first stages of software development, the Product backlog should be treated carefully through the whole product lifecycle. For example, when your product reaches the maturity stage, then balancing between bug-fixing, code-refactoring, and adding new features will get even trickier.

Learn to say ‘no’

In most cases, Product Owners are closely working with management and/or their clients. Stakeholders usually have a vast number of cool ideas to implement to your product. But your team, due to its capacity, probably won’t be able to develop all of them. That’s why sometimes you will have to say: ‘no’. Apart from many important duties, Product Owner is also responsible for deciding what not to include into Product Backlog.

Sources:

• http://www.scrumguides.org/scrum-guide.html

• Kenneth S. Rubin - “Essential Scrum: A Practical Guide to the Most Popular Agile Process, 1st Edition” ISBN-10: 0137043295

• https://youtu.be/502ILHjX9EE