Scrum Framework Fundamentals: Product Backlog vs Sprint Backlog-EN

This article is part of a series in which we review the fundamentals of Scrum, complemented with infographics that explain them. Other articles: Sprint, Planning, Daily, Review, Retrospective, Product Owner,  Scrum Master and Developers. 

Authors: Alonso Álvarez y Patricia Parreira

Scrum is officially defined through the Guide, a document created and maintained by the original creators of the framework, Jeff Sutherland and Ken Schwaber. Any book on the subject contains far more text than this guide, which has been continually reduced in size and lightened in terms of prescriptions.

The Guide contains the basic elements of Scrum: meetings, responsibilities and artifacts. The first two have already been covered in several articles, now it is the turn of artifacts.

The name may sound a bit strange, and it certainly does not correspond to the dictionary definition. For Scrum, artifacts represent value or work through transparency, one of the pillars of Scrum.

The three artifacts are:

• Product Backlog (or product stack)
• Sprint Backlog (or sprint stack or iteration)
• Product Increment (or Product Increment)

Each of the three artifacts also has a commitment that helps measure progress: 

• The Product Goal for the Product Backlog
• The Sprint Goal for the Sprint Backlog
• And the Definition of Done for the Increment.

Here we will look at the first two.

What is a Backlog?

A backlog or stack is an ordered list, usually of jobs, requirements, pending actions, tasks, etc.

The fact that the list is a list implies that there is one element after another, which means that they are done in sequence, not all at the same time. The order can be whatever we consider appropriate at any given moment. When talking about jobs, the usual order is priority (instead of alphabetical, by seniority…), where “priority” can mean several things: from value, to urgency, to effort, to risk and combinations of these factors and other additional ones.

The backlog model, as compared to more conventional models such as requirements documents, also offers flexibility. It is easy to change the order in which the jobs are in if we consider that one must be done before others.

There are several criteria to determine if a backlog has the right characteristics. A common and easy to remember and apply one is DEEP, created by Roman Pichler and Mike Cohn.

It is an acronym that stands for:

D stands for Detailed appropriately.

This means that the level of detail is not the same throughout the backlog, so that the elements in the “higher” part, those that are closer to completion, have a greater detail; the intermediate ones, which could be carried out in the medium term, have less detail; and those in the lower part, which we will do in more or less time or which may not be carried out at all, have little detail.

This is a way of ensuring that refinement effort is only invested in those that will be carried out with greater certainty and in less time.

E stands for Estimated.

This means that there is at least a first approximation of the effort required to carry out each element in a standardized and homogeneous unit (to facilitate comparison). If we apply the above criterion, the expected level of accuracy will be higher for the elements at the head of the stack, as opposed to those below.

E for Emergent.

This characteristic refers to the fact that a backlog is dynamic, so that it can accept new elements, or delete them, or adapt them, or change their order.

P for Prioritized.

As we said before, a backlog is an ordered list, and this order should mark the priority of the elements, so that the most priority elements are at the top, because they are the ones that should be undertaken first. This priority can be marked by different criteria depending on the needs of those who manage the backlog, under conditions that are applied homogeneously throughout the backlog.

Product Backlog vs Sprint Backlog What are the differences?

Product Backlog

Scrum defines the use of two types of backlogs. The first is the product backlog, a “pop-up and ordered list” that is the source of the team’s work and collects the needs and improvements of the product the team is working on.

The Product Backlog starts to be built before the first Sprint (it is necessary to start planning) and will remain “in the works” until the product is considered complete (usually never), or no longer makes sense, is of interest or provides value.

In other words, the content of this Product Backlog is subject to a continuous process of refinement. Although there are teams that hold meetings or formalized refinement processes, the Guide leaves a lot of freedom and only speaks of “refinement activities”. This is work to review the content of the Backlog, to break down elements into smaller ones (and thus reduce risk), to add details, to review the priority order in which these elements will be implemented.

One of these details, and not a minor one, is the size, which can be translated into cost, effort, complexity, or the scale considered by the team. This size is estimated, since we will normally move into an environment of uncertainty and novelty, which is where Scrum is most effective. Well, evaluating that estimated size is the responsibility of the people who are going to build the product in first person, the Developers. At the end of the day, whoever does the work is always in a better position to intuit how much work is involved in doing it.

The Product Backlog is defined around a commitment: the Product Goal.

This definition must exist to explain what the team is looking for with its work and provides a way to align efforts towards a common goal. This Goal is part of the Backlog and all the elements that define the work that remains to be done, are born from determining what it is that will allow this goal to be met.

The refined Product Backlog is the input to the Planning event. One of its outputs is the following artifact.

Sprint Backlog

Let’s remember what we said about Planning: its result is the Sprint Objective, the unfinished work, and a plan. That is: “why”, “what” and “how”. That “what”, the pending work, is the content of the Sprint Backlog.

It is a subset of the Product Backlog agreed by the whole team and defines the scope of what is to be achieved during the Sprint. But it is not a static view, it evolves as the team learns more things during the Sprint.

It is a basic Transparency tool that favors Inspection and Adaptation, since it is reviewed every day during the Daily or daily meeting, although it can be updated as needed at any time. Precisely to encourage this transparency, many teams use tools such as dashboards to reflect and update the status of the Sprint Backlog.

The Sprint Backlog is a planning tool in the hands of the developers, who manage it, although they may rely on the coaching work of the Scrum Master. Normally we can expect its content to be the tasks that add value to the product during the Sprint, and any other activity necessary to carry them out and that helps the team to move the work forward. For example, the Sprint Backlog is a good place to surface and track the resolution of impediments and roadblocks, which is also part of the work.

Just as the Product Backlog has a commitment to align the work, features, requirements… that will be part of the Product, the Sprint Backlog has its own commitment: the Sprint Goal. It is created during Planning and serves to align the work done during the Sprint in each direction.

These two artifacts play a fundamental role and are basic tools when it comes to delivering value through the last of the three artifacts, the Product Increment or Increment, which we will see in a future article.

Download complete infographic

¿Do you want to know more about Scrum practices?

We recommend the “Agile Fundamentals” training, a 24h course to start learning the knowledge and skills of Scrum and Kanban, accredited by ICAgile.

Go to agile fundamental course