A product backlog represents all of the goals and desired outcomes within the development of a product. They are the specific tasks a team hopes to complete when they set out to design or improve upon a product.

What makes a product backlog so effective is its agile nature. Backlogs are in constant evolution, changing and adapting based on the current needs of stakeholders and customers. To keep a backlog up-to-date and in its most effective form, it needs to be continuously refined and adapted. This process takes time, but there are simple, powerful strategies for maintaining a quality backlog.

A good product backlog has four characteristics. It is:

• Detailed appropriately
• Estimated
• Emergent
• Prioritized

We’ll cover all of these attributes in detail, including how you can ensure your product backlog is in good health. But first, let’s get on the same page about product backlogs and the refinement process.

Transform your flat product backlog with

Easy Agile TeamRhythm

Try Now

What is a product backlog?

A product backlog is a prioritized and ordered list that represents the work to be completed by a development team. Backlog items are derived from the product roadmap and are organized based on the tasks that are most vital — the ones that will make the biggest impact at any given time.

Backlog items represent what it will take to develop a new product or improve an existing one with new features. It’s all of the work a team will tackle in the future, but it’s also a flexible, living organism that evolves as a development team learns more about the product and its stakeholders.

The product owner is in charge of ordering and prioritizing backlog items, placing high-priority items at the top. They are also responsible for backlog refinement, which ensures all backlog items are organized, have appropriate details, and are ready for any upcoming sprint planning.

Product backlogs vs. sprint backlogs

Sprint backlogs are quite similar to product backlogs, but they serve a different, more specific purpose. At the beginning of a Scrum, the product owner arranges the product backlog items that are to be completed by the Scrum team in that sprint.

The Scrum product backlog represents a small subset of the overall product backlog. The product backlog is the entire bottle of wine, while the sprint backlog is the glass of wine you’re going to tackle next. In this analogy, the Scrum master is the sommelier, providing guidance, context, and feedback throughout the sprint.

At the end of the sprint, a sprint review is conducted with the stakeholders to better understand what to tackle next. Backlog items that weren’t completed may be pushed back into the larger product backlog to get to at a later date or during the next sprint. Another sprint planning meeting will prepare the team to tackle the next batch of backlog items.

Why does a backlog need refinement?

Backlog refinement isn’t a luxury task reserved for when you get a chance to tidy up. Refinement is a key part of product backlog management that ensures a backlog always has the most recent, up-to-date information.

Refining the backlog prepares it for the development team, saving time in the long-run. The process helps to prioritize items and ensures there’s nothing in your backlog that you no longer need.

As you’re well aware, the agile methodology centers around flexibility and the ability to evolve a plan as new information or roadblocks appear. What you thought was important at the beginning of product development may not be necessary anymore, or your stakeholders may have turned you in a completely different direction.

Product backlog refinement includes:

• Adding detail to high-priority backlog items for greater comprehension.
• Improving and reviewing estimates.
• Removing items that are no longer relevant to the product.
• Adding items based on new stakeholder feedback.
• Making adjustments based on the most recent bug fixes.
• Prioritizing items that bring customer value.
• Ordering backlog items to deliver the most impact over the next sprint.

Backlog refinement takes time, but it’s well worth the effort to have a healthy, up-to-date backlog that’s always ready for the development team.

DEEP: The key attributes of a good product backlog

Roman Pichler, the author of Agile Product Management with Scrum: Creating Products That Customers Love, developed DEEP to describe the key attributes of a good product backlog. The acronym DEEP helps product owners and development teams understand how to make smart decisions while maintaining a successful backlog.

The concept is applied throughout the product backlog refinement process, which is a critical part of backlog management. Backlog refinement, previously called backlog grooming, is an ongoing process that ensures a backlog is in tip-top shape. We like to think of it like trimming the branches of a plant.

To help a plant grow, you need to prune and trim it. The refinement process adds details where needed and prioritizes items based on the current information a product owner has from team members and stakeholders.

DEEP stands for Detailed appropriately, Estimated, Emergent, and Prioritized.

Following these guidelines and best practices will lead to a quality backlog, which will lead to smooth product development and a successful end result. Let’s dig into each attribute. 🔎

Detailed appropriately

Details matter, especially as a user story rises in priority. As a backlog item gets closer to being completed or moved into a sprint backlog, it requires more detail. Upcoming backlog items should be detailed appropriately, so they can be better understood by the development team. The closer an item is to being completed, the more detail it should have.

On the other hand, items that are lower on the priority list don’t require nearly as much detail. It’s a poor use of time to add details to lower priority items since you never know how the backlog is going to evolve. You could waste a lot of time detailing low-priority items when they might be removed or revised later on in the process.

Estimated

Thorough estimation should be focused on high-priority items that will be tackled soon. As you refine your backlog and add more details to top-priority items, you can improve your estimation. A good option is using story points to zoom in on the details. They can help you accurately and practically reflect the reality of an item from the customer’s perspective.

📘 Read our guide to incorporating user story points to start using this technique.

Since not much is known about them, it’s difficult to properly estimate items that are lower in priority. When you are further down the priority list, your estimation will be more of a guess since you don’t have all of the information yet. In these cases, use a simple agile estimation technique, such as t-shirt sizing (labeling work items as XS, S, M, L, XL) to make a guesstimate. Based on the information you have at that moment in time, make an approximate estimate on the exertion required for that backlog item.

Emergent

The more you learn about the product and its customers, the more you can improve your product backlog. The backlog is a living document that represents your plan at any one given time. It’s not set in stone, and it should see revisions and improvements as you go.

With the information gleaned from retrospectives and stakeholder feedback, you can update the backlog to reflect what you’ve learned along the way. Allow your backlog to evolve, adding, removing, and refining items as needed.

Prioritized

A product backlog needs prioritization. Items at the top are a higher priority, and items toward the bottom are a lower priority. When deciding which items should be prioritized, consider the value each item will provide.

Your team can maximize its efforts by prioritizing the backlog items that will provide the most value to customers at any given time. Since this will change depending on the current needs of your customers, you need to continually adjust and refine your priority order.

Achieve a DEEP product backlog with Easy Agile

Easy Agile is dedicated to helping agile teams work more effectively. We have a suite of Jira apps designed for teams that want to develop products that put the customer at the forefront of decision making.

Easy Agile TeamRhythm transform your flat product backlog, prioritizing based on value to the customer and bringing the customer journey to life. They help teams organize and prioritize user stories while visualizing the customer journey. Keeping your customers embedded in your process will help you make refinement decisions that are in the best interest of the customer, no matter what phase of development you’re in.

Learn more about our agile apps and follow our blog for the latest content for Jira teams.

Backlog prioritization is a never-ending task for product owners and product managers. As priorities evolve in response to changing business needs, or even as work is completed, or adjustments to team resourcing are made, it's important to maintain focus on the work that will deliver the most value by keeping your backlog in good shape. Agile estimation techniques can make prioritizing your backlog faster and easier.

So, let's take a look at some specific methods to prioritize your backlog and see how agile estimation can help deliver the most value to your end-users and stakeholders.

5 ways to prioritize a backlog

Of course, there are more than five ways to prioritize work items in a backlog. But, we've picked a few of our favorites that, when combined with an agile estimation process, help keep our product backlog prioritized so we can breeze through sprint planning.

1. Weighted Shortest Job First

Wow, is that a mouthful! Let's use the "WSJF" acronym to refer to this SAFe technique. Not as intimidating as it sounds, WSJF is a simple formula that assigns a business value to product backlog items.

WSJF = Cost of Delay ÷ Job Duration

Cost of Delay is the sum of three relative metrics:

• User/Business Value: the relative importance of the work item.
• Time Criticality: the decline of user/business value over time.
• Risk Reduction: the reduction of business or technical risk.

To determine the relative size for Cost of Delay, think of the lowest business value, the smallest decline in value over time, and the least risk reduction as a 1 value. The same as with Fibonacci sequence story point estimation, adjust that score appropriately when comparing work items to score them relative to one another.

The Job Duration is also expressed in relative terms. If you estimate your work items using relative estimation with story points, the story point value equals the Job Duration.

If you're using this technique to prioritize a large amount of work in a backlog where some items have only been t-shirt sized, convert your t-shirt sizes to standard Fibonacci numbers and use that value.

Warning: Be careful with converting t-shirt sizes to story points. You'll need a way to flag the t-shirt size work items that you converted to story points. You and your Scrum Master need to recognize those as t-shirt level estimations rather than the real story point estimates that come with fully refined work items.

See more at a glance in Easy Agile TeamRhythm, to make prioritizing your backlog faster

💡Tip: Add up to three extra fields on issue cards

SEE HOW

2. MoSCoW

Must-have, should-have, could-have, and won't-have are the buckets used to prioritize a backlog with the MoSCoW technique. The product team defines these designations based on the product's unique features and competitive offerings.

Each work item falls into one of those categories. The easiest part of this process is sending Won't-have items directly to the trash and getting them out of your way. Next, prioritize must-haves first and then should-haves. The could-have items naturally fall to the bottom of the backlog.

Take these items through your regular refinement meetings with your team members, and assign each item a t-shirt size or story point value. You're then ready to add the right amount of work items to your sprints or releases based on your teams' velocity or the number of story points they expect to finish during a sprint.

3. Kano

The Kano model of prioritization uses five classifications:

• Must-be: the basic functionality that your users expect.
• Attractive: a pleasant surprise for your users, but no one is going to be upset if it's not there.
• One-Dimensional: work items that make your users happy and will disappoint them if they aren't part of your product.
• Indifferent: work items that are unimportant to your customers. Often, these work items represent technical debt or enhancements that help the software development team develop more efficiently or work in the latest versions of their tech stack — but your customers really don't care about them.
• Reverse: the process of undoing a previous feature or update. If you've ever built a feature or made a UI update that your users hated, you understand reverse work items. Oops. Unfortunately, sometimes these are necessary evils, especially when it comes to security features or transitioning users to a new product after retiring a legacy product.

Like the MoSCoW method, you'll estimate these work items during refinement and then add them to your iteration or release plan. But, different from MoSCoW, you may want to balance out your sprints and releases with work items from each classification.

4. Stack Ranking

The most brutal of all prioritization techniques, stack ranking forces teams to have a linear rank of work items, which means there is only one top priority, one second priority, one third priority, and so on. Brutal!

Once you get used to it, stack ranking is a useful way to force product managers to make tough choices between work items. Even if two work items can be completed during the same sprint, it's up to the PO to determine which one gets done first, and then that choice is reflected in the sprint backlog.

Often, this job becomes easier when it's put in dire terms. For instance, if you only had one day to attract new users to your product, what work would you want in production? BOOM! There's your top priority.

The nice thing with stack ranking is that it allows POs to slide smaller work items into current sprints when other higher-priority work is too large. Adding the larger work item over-commits the team based on their velocity. Those small work items serve to fill up sprints so teams can maintain velocity and be as productive as possible. So, just because a two-story point work item is two-thirds the way down the backlog doesn't mean it will never get done.

5. Story Mapping

Story mapping helps you visualize the customer's journey through your product from start to finish. (Yep, we stole that straight from our other excellent article on story mapping.) For advanced story mappers, take what you’ve learned about story mapping, and think about how you can add MoSCoW or Kano techniques to your story maps.

Perhaps your epic backbone at the top of the user story map could represent the buckets in the MoSCoW method?

If you're like us, your story mapping sessions are productive brainstorming activities, and you'll leave the sessions with way more work than you can accomplish. By applying MoSCoW or Kano principles to the stories in your user journeys, you’ll discover the most important stories to prioritize and the stories that can wait for a later release.

Building agile estimation into backlog prioritization

We've given you five different techniques to corral your work items into an organized, prioritized, value-delivering product backlog:

1. Weighted Shortest Job First
2. MoSCoW
3. KANO
4. Stack Ranking
5. Story Maps

We've also shown you ways to incorporate agile estimates like t-shirt sizes and story points into your prioritization process to keep your team delivering the most important work while maintaining velocity and dazzling your customers and stakeholders.

We encourage you to take these ideas, share them with your team, and give them a try. If you need help using the Story Map concept, try Easy Agile TeamRhythm. However your team prioritizes its product backlog, remember to put the most important work first and then adjust those priorities as needed. Keep it easy and keep it agile!

It’s one of the most common practices in agile software development; the flat product backlog. We’ve all seen them, we’ve all contributed to them, and we’ve all inevitably drowned in them.

In its simplest form, a flat product backlog is a laundry list of ‘stuff to do’ that will ultimately provide value to the customer. These actionable items are prioritised (top to bottom) in the order the value will be delivered. If a team is adopting the Scrum method the backlog is split into future sprints to provide an indication of what will be delivered and when.

Depending on the size and requirements of the organisation, the list of things to be done could be 10, 100 or 1,000 actionable items. It’s easy to see how managing the latter comes with the challenges of updating, assigning, grooming and scheduling these items.

What’s Wrong With Flat User Story Backlogs?

So far we know that flat backlogs represent a list of things to be done. This comes with its challenges, and its shortcomings were best described by Jeff Patton when he said;

We spend lots of time working with our customers. We work hard to understand their goals, their users, and the major parts of the system we could build. Then we finally get down to the details — the pieces of functionality we’d like to build. In my head I see a tree where the trunk is built from the goals or desired benefits that drive the system; big branches are users; the small branches and twigs are the capabilities they need; then finally the leaves are the user stories small enough to place into development iterations.



After all that work, after establishing all that shared understanding, I feel like we pull all the leaves off the tree and load them into a leaf bag — then cut down the tree.



That’s what a flat backlog is to me. A bag of context-free mulch

How do you pick an item from a list, and deem it the thing that’s going to provide the most value to your customers, without that additional context?

Shortcomings of a Flat Product Backlog

• The flat backlog makes it impossible to discover the ‘backbone’ of your product — the customers interaction experience with the product
• Arranging user stories in the order they’ll be delivered doesn’t help a product manager explain to others what the system does
• The flat backlog provides no context or ‘big picture’ around the work a team is doing
• A flat backlog makes it hard for the product manager to determine if they’ve identified the relevant user stories
• Release planning is difficult with a flat backlog. How do you prioritise what to build first in an endless laundry list?

User Story Maps

A story map is a visual representation of the journey a customer takes with a product, including the activities and tasks they complete. This visualisation helps the team to focus development on providing the most value to customers and their desired outcomes.

It provides context for teams by answering the following questions:

• Why are we building this?
• Who are we building this for?
• What value will the solution provide for the customer and when?

The story map still showcases the ‘stuff to be done’, the difference here though, is the way in which this information is visualised. As you can see, rather than listing these items out, each item is contextualised under a bigger piece of work. Besides the way the information is visualised, the key difference between a flat product backlog and a user story map, is the focus on the customer journey. Let’s unpack this by breaking down the anatomy of the user story map.

What A User Story Map Achieves that a Flat Product Backlog Can’t

• Focus on Desired Customer Outcomes: the visualisation of the customer journey allows teams to identify and implement features based on customer outcomes, and track progress at a glance against a story map
• Bring the Customer Journey to Life: the transformation of the flat product backlog to a customer centric story map means teams have a better understanding of their customer journey and what their customers want and value
• Prioritising Actions Based on Value to the Customer: visualisation of the customer journey allows teams to prioritise work based on “value to customer”, resulting in better outcomes and less waste

Are you getting lost in your flat product backlog? Are you stuck in an endless development cycle, but not really sure for who or why your building features?

Easy Agile TeamRhythm

Easy Agile TeamRhythm supports User Story Mapping, sprint or version planning, backlog refinement, and team retrospectives.