SoftwarePlant is now BigPicture! Learn more
Jan 12

Product Backlog – everything you need to know

The importance of backlog is something you cannot underestimate. All the features, whether key or minor, should be included within it. Yet, the backlog is so much more than just a to-do list. Let’s dive into Product Backlog aspects.

What is a product backlog?

The backlog is a well-defined list of tasks. According to Atlassian, a product backlog is a prioritized list of work for the development team that is derived from the roadmap and its requirements. The most important items are shown at the top of the product backlog so the team knows what to deliver first. 

Importantly, the development team works on the product backlog items by iteration or continually. Meaning, the developers aren’t bound to the product owner’s work pace.

What does the product backlog include?

The most common feature of the Product Backlog is the presence of User Stories – informal, general explanation of a software feature written from the perspective of the end-user or customer. 

User Stories are not equal – each item can have a different size, importance, and level of description’s detail. The closer the developers are to work on those items, the smaller the user stories should be.

How does the product backlog work?

It’s a good way to streamline your team’s work by prioritizing tasks and items needed to be done in current and upcoming sprints. To put it differently, a product backlog can be an effective way for a team to communicate what they are working on and what they plan to work on next.

Why is the product backlog important?

Because, it represents feedback from many sources, such as developers, sales, marketing and end-users. Product Backlog helps you understand the main goal, and achieve it by breaking it down into smaller, more manageable chunks.

Can the product backlog be changed?

It’s a part of the Agile approach, and as we know one of its core rules is flexibility. Even Scrum confirms that belief, that you can’t change the Product Backlog, is a myth. Why? Because it’s unwise considering the core premise of Scrum: we can’t create detailed plans for the future. Even if that future is a single Sprint, it is entirely possible that new insights or impediments emerge as the Development Team works through the Sprint Backlog.

Product backlog note

Remember: product backlog isn’t set in stone.

Who owns the backlog?

Product Owner, yet they’re not the only person who maintains the Product Backlog. As the Scrum guide states the Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. But it doesn’t mean the Development Team’s contribution is forbidden. On the contrary, they should add their own Story Points and items, if they help maximize the value of their work. 

How to manage product backlog properly?

  1. Don’t hoard user stories – delete those you don’t need or those which don’t bring any business value.
  2. Update the backlog on a regular basis
  3. Make it visible to every interested party.
  4. Add tasks – only if you want to work on them soon.
  5. Prioritize your backlog – the team must know which items can wait, and which are critical.
  6. Make backlog rules and tell them about to members and stakeholders.
  7. Be open to other people’s ideas on user stories…
  8. … And ask for feedback.
  9. Ask yourself “what” is in the backlog and “why” it’s there.

When to do product backlog refinement?

According to Scrum Guide, Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. It’s also known as Backlog Grooming and it is not just one event – it’s an ongoing process, as your backlog needs regular updates. Depending on the team’s product knowledge or the number of items added to the backlog regularly, it is recommended to refine your backlog daily, weekly, or per Sprint. As usual, this frequency should be adjusted to your team’s workflow and stakeholders’ needs.

Benefits of product backlog

Imagine you must build a ship, but you have no manual – this is what working without a backlog looks like. Product Backlog is both important and beneficial, and the main advantages it brings are the following: 

  1. It keeps the team up-to-date with expectations and current workflow.
  2. Items prioritization serves as direction to the team and supports sprint planning.
  3. It helps to estimate the time an item will be released.
  4. It increases the team’s work efficiency.
  5. It facilitates collecting feedback from different stakeholders and interested parties.

Remote backlog planning

What is the difference between a product backlog and a product roadmap?

Think of it as of a Russian doll – a story within a story. Product Roadmap is about a longer-term development, it usually consists of a timeline that can span into years and presents the big picture. Meanwhile, Product Backlog is a chunk of this timeline that represents one or a few upcoming Sprints. When the roadmap represents grandeur strategy, the backlog focuses on tactical solutions and work that must be done in the upcoming weeks and months.

What is the difference between product backlog and user stories?

Similar to the differences between backlog and roadmap. User Stories are a part of a Product Backlog, and represent a feature as a story, told from the perspective of the person who desires the new capability.

Agile product backlog vs sprint backlog

 

How to create a product backlog?

  1. Add Ideas.
  2. Clarify, refine and polish items in the backlog.
  3. Prioritize the items.
  4. Regularly refine (or groom) the backlog.

How to Create a Scrum Product Backlog

Product backlog best practices

  1. Keep it transparent and understandable.
  2. Drop the items you won’t be working on.
  3. Refine the backlog regularly.
  4. Don’t manage it by yourself – let developers do it.
  5. Leave space in the backlog to fill with additional items.
  6. Keep the product’s vision clear and visible.
  7. Talk and share your thoughts at the end of each sprint.

Product backlog estimation techniques

Planning Poker – one of the most popular planning tools. Each team member gets a set of cards with numbers. The numbers are usually in the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, and 21. Then, the Product Owner reads out a  story, one by one, from the backlog. After each story, team members show the card with the number that reflects the level of effort they believe the story holds. Once all the votes are in, the team members with the lowest and highest estimates explain why they choose their numbers. The team then re-estimates user stories as per the new perceptions discussed. Once the agreement has been reached that score is recorded with the story to which it relates, the team can proceed. Here’s a handy Jira app that supports the Planning Poker technique

T-Shirt Sizes – this technique allows team members to group together items of similar size into respective bins with popular t-shirt labels: extra small, small, medium, large, extra-large, and so on. The decision about which item goes to which bin is taken upon a discussion between the team members. 

T-Shirt Agile Project

Dot Voting – simple and fast, this technique is recommended for projects with a small set of items. Each team member gets a certain number of stickers. With them, they can vote for selected items. The more points the item gets, the bigger the item is. This method works for both small and large groups.

Dot Voting Backlog Planning Technique

Product Backlog common pitfalls

  1. Not considering Product Roadmap when preparing the Product Backlog.
  2. Bad or unclear description of Backlog Items.
  3. Not prioritizing items in the Backlog.
  4. Keeping the Backlog to yourself.
  5. Ditching or irregular Backlog refinement.
  6. Relying only on Product Owner to fill the Backlog.
  7. Not filtering items in the Product Backlog.

Deep product backlog – what does it mean?

“Deep” product backlog isn’t about conspiracy or veiled metaphors – it’s an acronym that presents the good practices of a well-refined backlog, and can be expanded to: 

Detailed appropriatelyUpcoming items in the backlog can be easily understood by team members, without being overly detailed.

Emergent – A product backlog should evolve, adding new items as we learn more about the problem space.

EstimatedEach upcoming item should have an estimate of how long it will take to complete

PrioritizedItems on the backlog should be ranked with the most valuable items at the top.

With this knowledge, you will be able to understand what is in the Product Backlog, as well as prepare one by yourself. 

About The Author

Content Specialist @BigPicture since 2021. He was previously working for the biggest media outlets in Poland, e.g., Wirtualna Polska, Rzeczpospolita, where he was writing about video games, biotechnology, and startups. Now he explores the vast world of Agile and Hybrid approaches. Loves good research, short sentences, and clear communication.