Tìm hiểu về Scrum Product Backlog trong Agile

Tìm hiểu về Scrum Product Backlog trong Agile

Firstly, You can read what is backlog on this topic: 06 types of backlog

In the simplest definition the Scrum Product Backlog is simply a list of all things that needs to be done within the project. It replaces the traditional requirements specification artifacts. These items can have a technical nature or can be user-centric e.g. in the form of user stories. The owner of the Scrum Product Backlog is the Scrum Product Owner. The Scrum Master, the Scrum Team and other Stakeholders contribute it to have a broad and complete To-Do list.

Working with a Scrum Product Backlog does not mean that the Scrum Team is not allowed to create and use other artifacts. Examples for additional artifacts could be a summary of the various user roles, workflow descriptions, user interface guidelines, storyboards, or user interface prototypes. However, these artifacts do not replace the Scrum Product Backlog but complement and detail its content.

The Scrum Product Owner uses the Scrum Product Backlog during the Sprint Planning Meeting to describe the top entries to the team. The Scrum Team then determines which items they can complete during the coming sprint.

Each Scrum Product Backlog has certain properties that differentiate it from a simple to-do list:

  • An entry in the Scrum Product Backlog always add value for the customer
  • The entries in the Scrum Product Backlog are prioritized and ordered accordingly
  • The level of detail depends on the position of the entry within the Scrum Product Backlog
  • All entries are estimated
  • The Scrum Product Backlog is a living document
  • There are no action-items or low-level tasks in the Scrum Product Backlog


Scrum Product Backlog

Only entries that add value
Each entry in the Scrum Product Backlog must have some kind of customer value. Entries without any customer value are pure waste and should not be present anyway. The Scrum Product Backlog can include entries for the exploration of customer needs or various technical options, a description of both functional and nonfunctional requirements, the work necessary to launch the product, and other items as well, such as setting up the environment or remediating defects. Some tasks may not add direct value to the functionality. Nevertheless they might add value by increasing quality or reducing incidents in the long term.

Living document
The Scrum Product Backlog is changed throughout the whole project. If needed, new requirements are added and existing requirements may be modified, defined in more detail or even deleted. Requirements are no longer frozen early on. Instead the final set of requirements within the Scrum Product Backlog is also developed iteratively, together with the resulting software. This is different to traditional requirements engineering but allows maximizing customer value and minimizes development effort.

Different level of details
The requirements in the Scrum Product Backlog have a different granularity. Only those requirements that shall be implemented during one of the next sprints are defined in greater detail and everything else is more coarse-grained. The simple reason for this is that it does not make sense to invest time and effort into the specification of these requirements, as most of these requirements will have changed anyway until implementation starts.

No low-level tasks
The Scrum Product Backlog shall not contain the detailed requirement information. Ideally the final requirements are defined together with the customer during the sprint. Breakdown and distribution of these requirements is the responsibility of the Scrum Team.

The Scrum Product Backlog is ordered
All entries are prioritized and the Scrum Product Backlog is ordered. The Scrum Product Owner with the help of the Scrum Team does the prioritization. Added Value, Costs and Risks are the most common factors for prioritization. With this prioritization the Scrum Product Owner decides what should be done next.

All entries are estimated
All the entries within the Scrum Product Backlog have to be estimated according to the agreed definition (e.g. story points). This estimation can then be used to prioritize entries in the Scrum Product Backlog and to plan releases.

Working with the Backlog
The backlog needs regular attention and care – it needs to be managed carefully. At the start of the project the Scrum Team and its Scrum Product Owner start by writing down everything they can think of easily. This is almost always more than enough for a first sprint.

After this initial setup, the Scrum Product Backlog has to be maintained in an ongoing process that comprises the following steps:

  • As new items are discovered they are described and added to the list. Existing ones are changed or removed as appropriate.
  • Ordering the Scrum Product Backlog. The most important items are moved to the top.
  • Preparing the high-priority entries for the next Sprint Planning Meeting
  • (Re-)Estimating the entries in the Scrum Product Backlog

The Scrum Product Owner is responsible for making sure that the Scrum Product Backlog is in good shape this is a collaborative process. When using the Scrum Framework about [wc_highlight color=”red”]10%[/wc_highlight] of the Scrum Teams total time should be reserved for maintaining the Scrum Product Backlog (discussion, estimation etc.).

The collaborative maintenance of the Scrum Product Backlog helps to clarify the requirements and creates a buy-in from the Scrum Team.


[wc_highlight color=”red”]IMPORTANCE OF PRODUCT BACKLOG[/wc_highlight]

As we have reviewed in one of our prior articles, the [wc_highlight color=”yellow”]Product Backlog is the list of incremental product features or functionality that the product owner expects on the product[/wc_highlight]. This is the list the Scrum Team would refer to at the beginning of each sprint and choose the top priority features to enhance the product. So far, so good.

One of the big mistakes organizations that are new to adopting Scrum do is to underestimate the importance of the product backlog. The purpose of this article is to help you understand why the Product Backlog is crucial to any scrum projects success.

To Understand why Product Backlog is Important – Imagine this Scenario in the Sprint Planning for the 1st Sprint

The entire team is assembled in the meeting room including the scrum master and the product owner. This is the first sprint and everyone is excited to get started on the next batch of product enhancements. However, there are no user stories ready nor are the details ready. What do you think would happen?

The product owner will try to visualize and document the product enhancements as part of a user story and then the team will start analysing the story so that they can estimate it and get started on the work. The first few days of the sprint is going to be wasted before the team has at least one or two user stories that are in “Ready” state for development. Of course, if the team is big, just one or two stories may not be enough to fully utilize the team and hence we are probably going to waste a few days of every team members time until we have sufficient user stories for everyone.

Not to mention the cascading effect this is going to have on subsequent sprints as well because in this Sprint the product owner would be struggling to supply enough stories to keep the team occupied and by the time there are enough stories, Sprint 1 is over and we would’ve reached Iteration Planning day for Sprint 2 and are again back to the same state where the backlog of stories or requirements is not ready.

Do I need to explain more about why the Product Backlog is Important?

Real Life Trivia:   The example above is not fictional and I have seen that happen in many projects where the product owner or the team did not spend time preparing for Sprint 1 and majority of sprint 1 was spent getting the backlog ready and the product output of Sprint 1 was barely anything worthwhile. 

Pre-Sprint Readiness Check of the Sprint Backlog

Experienced Scrum Masters do not wait until Day One of the first sprint to find out whether the product owner has gotten started on the product backlog. They usually identify a few key members of the team and have them get started on discussions with the Product Owner on the potential product enhancements at least a few days (or even weeks) prior to Sprint one. This way, the preliminary backlog of user stories or features is ready before Sprint 1 starts and there is no wasted effort.

An argument here can be made that no work should begin before the start of the Sprint and if we have people working on user stories prior to sprint 1, aren’t we deviating from what Scrum recommends?

Yes, this argument is quite valid but Scrum does not actually recommend that. One of the assumptions in Scrum is that a “Well Defined” product backlog is ready when we arrive in the iteration planning meeting. Without this product backlog the team cannot build anything product in that sprint and hence it is assumed that some work would’ve gone into getting the product backlog ready before the Sprint planning. Get the picture?

In one of our earlier articles on Scrum Meetings, we had a meeting called the “Backlog Refinement” meeting where the product owner and a few members of the team get together to review the product backlog to understand the complexity & relative priority of the important items so that the next iterations planning meeting can be fruitful. It’s the same concept here and we have some members of the team working on the product backlog so that right from Sprint 1, the team is able to deliver incremental product upgrades.

Real Life Trivia: Some Scrum Teams even have a Sprint 0 where only a few members of the team and the product owner get started and their goal is to prepare the initial product backlog before we start Sprint 1. What we name this preparatory period is entirely up to us but the idea here is to make sure there are enough backlog items for the team to be productive from the start.

Have you faced such situations in your scrum projects or have any inputs for fellow scrum masters? Do sound off on the comments.

Leave a Reply

Your email address will not be published. Required fields are marked *

13 + fifteen =

This site uses Akismet to reduce spam. Learn how your comment data is processed.