As a product owner, you are sometimes referred to as the “single, wringable neck” in Scrum. While traditional methods may have afforded you to communicate everything about a product by writing a big, stuffy document, Scrum dictates that you are to become a part of the development team; work with the team to deliver the highest value features and functionality and to safeguard the ‘system or product as a corporate asset’ via the just-in-time elaboration of requirements. What in the world do you do?

After some initial investigation and discussions, you realize that the product backlog forces you to make choices. Now you not only have to consider the customer impact of a feature, but you have to analyze that feature/functionality in terms of ROI to the business. What WILL you choose for engineers to work on that brings the highest value to the organization? What are customers clamoring for first? What technical upgrades or decisions need to be made that perhaps are more important long term for overall product stability and scalability? In fact, what is the product vision? Being tasked with writing a product backlog is no small feat.

Tips for an Easier Product Backlog

As excruciating as writing your first product backlog can be, be advised that this list of features/functionalities/defects/enhancements is your best friend. Here are some general tips to make the product backlog work for you.

1. The product backlog is yours, so own it. You may consolidate features, push them to the bottom, or (gasp) eradicate them totally from the list. The good news here is that this list is yours, and it should reflect the latest and greatest valuation of items, from highest to lowest, at all times (or at least on an iterative basis). Stay one iteration ahead of your developers, and utilize development expertise to help you prioritize. A good rule of thumb is to focus on the top 20% (the backlog "staging area") when considering priority for the next iteration; however, do scan the entire list from time to time to make sure nothing is being overlooked.
2. Communication points. Each line item of the product backlog serves as a communication point between yourself and the development team. Many new product owners stress because the product backlog seems too high level. This is how it is intended to be, because the breakdown of requirements and stories is meant to be a team activity. Certainly there are times when detailed requirements are known about a feature, and this is fine; however, when details aren’t known, you have your team to help you understand what that is all about. The backlog is a master list to ensure that communication is happening between you and the development team.
3. Expert Negotiations. Working with your team to understand, define, and estimate the backlog builds a common foundation for negotiation. The backlog empowers you and your team to make educated, intelligent trade-offs. Sometimes this can occur as ‘feature consolidation’, whereby one feature can be gained by the implementation of another. Often, the development team will advise you when they feel that a backlog item is not necessary, since they can make a small change elsewhere to meet the vision and theme of the release. This allows you to remove a backlog item and choose another in its place. And of course, sometimes it just boils down to a good old-fashioned discussion of “what’s more important, x or y? Because we only have enough time to do one or the other, not both.” Eventually, by sharing the product vision and backlog, the development team will become product advisors to you, explaining where time can be saved, new ways to satisfy the customer, and alternate or expanded ways to meet the vision of the product.
4. Learn how to prioritize. Sometimes, early prioritization efforts reveal unknown prioritization criteria. How do we prioritize? What is important to our product? To our business? To our customers and stakeholders? Some examples of prioritization criteria used by product owners are: RGT (run, grow, transform [product or business]), ROI (expressed as a value of 1 to 10), Critical rating (1 to 10), High Level Estimate, Customer Requested By. These criteria are dependent upon the type of business and what the needs are; develop what is best for you and your product. If you find yourself stuck in prioritization mud, it’s best to gather your colleagues for a discussion to work your way out of it.
5. Inspect and adapt. Your first backlog might not be a work of art, but through communicating with your team, working through a couple of iterations, and applying what you know, your backlog will begin to take shape. Don’t sweat it; just retrospect and apply what you have learned to make a product backlog to be proud of. The good news is that if you make a mistake, you’re only one iteration in.