The Best Advice from Scrum and Agile Experts on Managing Your Product Backlog

First, let’s clearly define a product backlog. Scrum organizes projects into a series of focused work periods called Sprints, and each Sprint usually lasts two weeks. Before the Sprint begins, the team and the Scrum Master (who functions as a coach) create their Sprint backlog, which is a list of what they intend to accomplish in the upcoming Sprint. 

The Sprint backlog is drawn from the larger product backlog, which is a complete list of all features and functionality that needs to be added to the product. The product owner is in charge of prioritizing the product backlog. (The product owner also represents the needs of the customer and other stakeholders and guides the development team’s work.) The product backlog is vertically ranked so the most important tasks are listed at the top, and the Scrum team usually selects items from the backlog based on priority. The product backlog will change and evolve over time based on user requests, business needs, and broader technology trends.

As a side note, you can also make use of a product backlog in another Agile framework called Kanban. Although Kanban is based on limiting work in progress (WIP) instead of using fixed-length Sprints (Scrum), the information in this article can be applied to Kanban projects as well.

A well-constructed product backlog ensures your work is productive and valuable, that the product meets customer needs, and that it aligns with your organization’s goals. Just as with your personal “to do” list, you need to constantly manage your product backlog. This process is often called refining or grooming the product backlog. Priorities change, tasks get accomplished, and ideas are discarded. Without updating your backlog, it will become disorganized and won’t help you stay on track.

To get started creating a product backlog, some Agile experts recommend starting with a product roadmap. This is a strategic plan that offers a longer-term outlook for your product.  Roman Pichler, an expert trainer in Agile product management, said that many product owners and managers focus too much on feature details in their roadmaps and not enough on big vision. He developed a goal-oriented roadmap template that emphasizes the product goal and the features necessary to reach the goal.
 
While your roadmap might include long-term goals for several releases, the product backlog should focus on listing work for the next release in greater detail. Future releases should be placed lower down and expressed in less detail. Then, take the information from the roadmap and translate that into tasks and work items. 

Each product should have its own backlog. If your product is quite large or part of a suite of interrelated products, it can be confusing to determine what constitutes a product. Agile expert Kenneth Rubin, a consultant with Innolution, says that the goal is to minimize the number of component teams and component backlogs, so he prefers to use one backlog whenever possible. However, for very large projects with tens or hundreds of teams, this isn’t practical, and in those cases hierarchical backlogs can be used with one backlog for large-scale features and a separate backlog for each related area of work.

Work items on the product backlog are often expressed in what are called user stories, a description of how the feature will work from the point of view of the user. A user story is small enough that it can be accomplished within a Sprint. 

Chuck Kroll, an Agile coach who trained teams at Fidelity Investments, recommends a traditional formula for user stories:  “As a (type of user such as customer), I want (goal) so that (reason),”  Kroll said. “This makes [it] clear who will use the feature, what it entails and what  business value it offers.”

User Story vs. User Epic: How Detailed Should Backlog Items Be?

A much bigger story is called an “epic” and can take several Sprints to accomplish. Epics need to be broken down into stories before work can begin. 

Mike Cohn, Founder of Mountain Goat Software which offers Agile and Scrum training, offers this example of an epic: a hotel company wants a system to determine the most it can charge for a hotel room depending on variables such as competitors’ rates, season etc. “As a hotel operator, I want to set the optimal rate for rooms in my hotel.” That breaks down into user stories such as “As a hotel operator, I want to set the optimal rate for rooms based on prior year pricing,” and “As a hotel operator, I want to set the optimal rate for rooms based on what hotels comparable to mine are charging.”

As you prepare user stories for the product backlog, the higher priority items should have more detail to help the team execute them accurately. This can include diagrams showing a feature’s workflow or a description of its details. 
“The most important advice that I see overlooked is that product backlog items do not all need the same level of detail,” said Cohn. “Items coming into the next Sprint need to be moderately detailed. Items further out should be progressively less detailed.”

Imagine the following user story: As a website visitor, I want to be able to buy a plane ticket at the cheapest price offered to my first choice airport  or nearby airports. Because this nears the top of the product backlog, you should add details to the user story such as: the function should check fares for all airports within 100 miles; it should give me the ability to sort the fares by distance from the first-choice airport as well as by price. 

Pichler recommends that product lifecycle is important in deciding how granular to make the product backlog. Young products should have shorter, less detailed backlogs, which allow you to experiment with new ideas and change your product frequently to optimize it. On the other hand, older, more stable products benefit from a more detailed backlog because you are more able to anticipate how the product will evolve.

Release cycle is another factor in your product backlog. As you start work on a new version or a big release, there are more unknowns and what you learn will result in potentially big changes to your backlog. So a shorter, less detailed product backlog makes sense early in the release cycle, Pichler explained. 

Bill Wake, an Agile consultant who now works with Industrial Logic Inc,  came up with a widely used model and mnemonic for the characteristics of a good user story using the acronym INVEST:

I - Independent - Stories should not overlap and ideally can be implemented in any order.
N - Negotiable - The story captures the essence but not the details, which are agreed upon by the participants.
V - Valuable - The story offers clear value to the customer. 
E - Estimable - You are able to assess the effort involved. This might be a time estimate or in what are called story points, an arbitrary unit of measurement that rates relative complexity (such as XS, S, M, L, XL or 1, 2, 4, 8, 16). 
S - Small - “Good stories tend to be small,” Wake said. This means that the story should be accomplished in (at most) a few 40-hour work weeks from a dedicated person, or divided among team members. 
T - Testable - The user story should be measurable or actionable in some way, according to Ulf Eriksson, founder and product owner of the IT testing platform ReQtest.

Cohn stressed that not every item on the backlog needs to be a user story. “I meet teams who think every product backlog item should be a user story. User stories are great - when there are users around. But some things that belong on a product backlog aren't necessarily directly for users. Those items do not need to be written as user stories.” 

This would include work on the backend or other tasks that are distant from users. Cohn recommends describing these tasks using feature-driven development  (FDD) syntax (verb + result + object, i.e. “Validate the password of a user”).
The four types of items commonly found on Scrum backlogs are features, bugs, technical work, and knowledge acquisition. Features usually lend themselves to being expressed as user stories while the other items do not. 

If you are just getting started, don’t worry: you don’t need to start your project with a perfect product backlog. Begin by brainstorming necessary tasks, and this will provide enough information for your first Sprint. Then, you can expand your product backlog as you learn more about the product, user needs, and feedback.

“My main tip regarding product backlogs would be to keep it simple. It's just an ordered product breakdown structure,” said Laurens Bonnema, an Agile consultant at Xebia in the Netherlands.

C.J. Boat, an Agile team leader for insurance marketplace Ensurem, agreed. “Make reasonable expectations! If you let your backlog get too massive, or do not properly organize your work, the backlog, and sprints, can become so crowded they will fall apart,” he said. 

Once you have added the tasks, it’s time to order the product backlog. Place the more important work above less important work. You can do this based on your priority rating, making judgments as you go on how to rank items with the same priority rating.

“As you add tasks to your backlog, assign them an initial priority rating,” said Kevin Lonergan, Principal Project Management Consultant at Britain’s PMIS Consulting. “A simple three-level priority will do: 1 - critical to achieving the business goals,  2 - useful but not critical, 3 - would be a bonus if these items get done.”

Some practitioners say a better method is  ordering the list on other criteria such as risk, ROI, cost-benefit, a bucket model like MoSCoW (must have, should have, could have, won’t have), the impact one story has on another, estimated time to implement, or dependencies.

Xebia’s Bonnema favors the Weighted Shortest Job First (WSJF) method, written about by Donald Reinertsen in “The Principles of Product Development Flow” and developed further by Dean Leffingwell, creator of the Scaled Agile Framework. It’s a formula for prioritizing the product backlog based on task duration and a weighting for cost of delay. “I haven't come across a better way to consistently prioritize backlogs at every level correctly than WSJF,” Bonnema said. Tasks stay on the product backlog until they are complete or until the product owner decides they are no longer needed. 

To determine when a user story is completed and can be removed from the backlog, teams should develop a standardized “definition of done.” This is the acceptance criteria for a feature that ensures all team members know what is expected of the work they deliver. Kelly Waters, author of All About Agile believes that "done” should mean shippable. Jeff Sutherland, CEO of Scrum Inc., uses the popular Agile phrase  “done done,”  meaning that at the end of the sprint, coding has been completed and software testing is finished at the feature level with no bugs. When your team’s definition of done is met, an item can be moved from the product backlog to the complete column.

Now that you know what a product backlog is and what does and doesn’t belong on one, here is your checklist for crafting your first product backlog:

1. The product owner is in charge of the product backlog. If this is you, you are in charge of creating the product backlog, but you don’t need to be the only person involved. Scrum team members and other stakeholders can participate.
2. Remember the product backlog is the complete list of all user stories and other work items for the product.
3. Think of every task you can and write it down. Be as specific as possible and ask for input from all relevant parts of your organization and customer feedback.
4. Craft stories from the point of view of the user and include an action and a reason. (As a _, I want _, so that_.) Think of all different users. Write these on index cards or use an online tool. Apply tags to make the planned release clear.
5. Include bug fixes, knowledge acquisition, and technical work.
6. As product owner, you alone rate the importance of each item to the organization ranging from very high to very low or another method. You can survey users to have a solid basis for these decisions. 
7. For each work item, also provide an estimation of how much effort is involved.
8. Rank the product backlog. 
9. The work that the team commits to tackle in a Sprint is the Sprint backlog, and this is separate from the product backlog. The Sprint backlog does not change during the sprint. Items are considered complete and removed from both the Sprint and product backlogs when they are “done done.”
10. When new work comes in, add it to the product backlog in the right position. When  you gather new information such as feedback, you may delete or reorder items. 

When you’re finished, you should end up with something like this:

At this point, congratulations are in order if you successfully drafted your first product backlog and got your Scrum team working on a batch of valuable user stories in a sprint. But it’s still not quite time to relax. 

Once created, the product backlog must be continuously maintained and updated. This process, also known as product backlog grooming or refinement, keeps your backlog current based on information from the marketplace, users, the product team and your organization’s management. By staying on top of backlog grooming, you ensure that the development team is always putting its effort into the right things, that you are ready for the next Sprint, and that you utilize your resources well and deliver the best possible product to your customer. 

An easy way to remember the objective of the product backlog refinement process is the DEEP acronym. Your goal is to make sure your product backlog is always DEEP: 

D - Detailed appropriately so that items at the top of the list have more detail than those at the bottom. 
E- Estimated - Each product backlog item, or at least those involved in the next release, should be estimated by story points or time. As your team gets more work under its belt, its velocity - the rate at which it finishes items from the product backlog - will become clearer and make estimating easier.
E- Emergent - This means the product backlog is adapted to new items or information that emerge.
P- Prioritized - All items on the product backlog are ordered with the most important ones at the top. 

Even with your best efforts to keep your product backlog running smoothly, glitches can arise. Agile experts who have worked with many teams and on a variety of projects have tips on troubleshooting and avoiding problems.

Agile coach Kroll said the most common problems he sees arise from a lack of participation from project sponsors, who need to be involved on a daily basis, and a tendency for them to press the team to meet time targets that are not driven by the team’s actual throughput. The solution is for managers to shift from a traditional “planned vs. actual” project mindset to an Agile approach. 

Jonathan Roger, a project manager and Scrum master for AndPlus, recommends keeping an “icebox” at the bottom of the product backlog for unprioritized and ungroomed ideas. “Product owners can keep track of longer-term desired features without the pressure of keeping them in a priority order, and teams can add their potential ideas for product owner review. It also serves as a good starting point for feature requests from customers or stakeholders.” 

PMIS Consulting’s Lonergan recommends careful selection of the product owner as a key to success. “One person must carry out the role of product owner - not a committee,” he stressed. “They own the product backlog. Ensure the product owner drives the development of the backlog.” 

“The No. 1 (mistake) is undoubtedly appointing the wrong person as product owner due to lack of authority, domain knowledge, lack of time, etc,” Lonergan added. 

From simple task management and project planning to complex resource and portfolio management, Smartsheet helps you improve collaboration and increase work velocity -- empowering you to get more done. 

The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed.

When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.