An Introduction to the Product Backlog

Note: We are referring to scrum in this document but each event/ceremony or artefact will have an equivalent in other methodologies and frameworks.

Consider each event/ceremony as a way of creating repeatable moments that enable the right discussions to happen and decisions to be made, effectively and efficiently.

The Product Backlog (PBL) is an essential artefact in Scrum and similar agile software development frameworks. It is an ordered list of things that might be needed as part of the product. It is the single source from which all requirements/functionality flow. This means that all work the team does comes from the Product Backlog. Every feature idea, enhancement, bug fix, documentation requirement - in fact every piece of work the team does - comes via the Product Backlog. This enables all the team time and effort to be expended on the most beneficial things.

Note: Individuals within the team may have other responsibilities that they need to fulfil. Whilst this is not uncommon, this should be carefully looked at to see how it can happen in harmony with the concept of true teamwork and being there for one another to achieve the common goal.

This raises an interesting and often overlooked point...that the PBL may contain all sorts of "things to do" and as such isn't really a "Product" Backlog.

However, the most popular way to create a product backlog is to populate it with user stories, which are short descriptions of functionality described from the perspective of a user or customer. Read more about User Stories here.

TIP: How to prevent the Product Backlog becoming a 'To Do' list

Ideally, the PBL remains a concise description of product features and functionality that stakeholders and the team can quickly understand at a glance. To achieve this:

the Team tasks and other 'To Do' items that are repeated every sprint are not added to the PBL but are added to the Sprint Backlog during Sprint planning.

"In Scrum project management, on the first day of a sprint and during the planning meeting, team members create the sprint backlog. The sprint backlog can be thought of as the team's to-do list for the sprint." - Mike Cohn

The Product Backlog needs to be easily filtered and as such all items need to be correctly categorised and associated with one another when any dependencies or parent-child relationships occur. Read More about the type of items a Backlog should contain.

So is this the Product Specification?

No. Some of the information stored in the PBL makes up part of the Product Specification, or Product Definition as it is sometimes called. An agile product specification is composed of a set of hierarchical information, from a high level vision, through to fine details in acceptance criteria.

Who Owns the Product Backlog?

The Product Owner (PO) is responsible and accountable for the PBL, although the PO should have help in producing it and keeping it up to date. PBL items may originate from the Product Owner, from team members, or from other stakeholders.

The PBL includes high level descriptions of all the capabilities required in the product, but does not need to have everything in detail. Details are provided "just in time", in the Backlog Preparation activity, known as Backlog Refinement, and the Sprint Planning meeting.

Maintaining the Product Backlog

Since Product Backlog Items (PBLIs) are quite often large and general in nature, and since ideas come and go and priorities change, keeping the Backlog well organised is important. Backlog maintenance, often called Backlog Refinement (originally called Backlog Grooming), is an ongoing activity. This activity includes but is not limited to:

keeping the Backlog ordered, typically in implementation order
removing or demoting items that no longer seem important
adding or promoting items that arise or become more important

Read more about Product Backlog Maintenance.

Product Backlog Refinement

One key aspect of this refinement activity is to prepare for the upcoming Sprints. In aid of this, the refinement activity gives special attention to preparing items that are coming up for implementation, are near the top of the prioritised list. There are many things to consider, including but not limited to:

Each item entering the Sprint should ideally represent an increment of "business value". Therefore the Product Owner needs to be actively engaged in understanding and selecting slices.
In most cases you will only be able to deliver value with some UI changes, some logic changes, and some persistence / database changes. Thus, a story is a vertical slice through the system (see below).
The team needs to be able to build the item within a single Sprint. Therefore software engineering members of the team need to be engaged in determining how big the slices can be.
The whole team needs to be clear on what is intended. Therefore testing members need to be engaged in proposing acceptance criteria and preparing clear examples.

Depending on the nature of the product, other skills and inputs may be needed. In every case, backlog preparation is best considered as an activity for all the team members, not just the Product Owner.

Prior to every Sprint, the Product Owner prioritises the PBL items so that the most important items can be ‘pulled’ from the backlog and into the next Sprint at the Sprint Planning meeting.

The Thin Vertical Slice

“Vertical slice” is a shorthand for:

“ A work item that delivers a valuable change in system behaviour such that you’ll probably have to touch multiple architectural layers to implement the change. ”

When you call the slice “done”, the system is observably more valuable to a user. This is contrasted with “horizontal slice,” which refers to a work item representing changes to one component or architectural layer that will need to be combined with changes to other components or layers to have observable value to users.

When teams work in vertical slices, they:

Make value explicit in their backlog
Have more conversations about value
Tend not to accidentally build low-value changes
Get value sooner
Get earlier, higher-quality feedback
See constraints and inventory more easily and can respond accordingly
Become more predictable in delivering value (because working software becomes the primary measure of progress)

Whilst this seems obvious, there are many reasons why this wasn’t, and often still isn’t, the norm. Two of the most common are:

It takes imagination and effort to be able to identify valuable slices that are small enough to be defined, developed and delivered in a single sprint.
Teams may not be set up to have the knowledge, skills or authority required to do this.

TIP: The Product Backlog sits slightly in the 'Solution Space'

You'll often read or hear that The User Story must not consider technical implementation detail which tends to get translated as, "A User Story is the WHAT and the WHY".

Whilst this is true, in the full process from moving from an idea or identifying a possible opportunity, to delivering the resulting solution and realising the benefits, the top of the Product Backlog is certainly more in the Solution Space versus the Problem Space.

Because a user story is essentially a description of a change in system behaviour from the perspective of a user, it describes something a user wants to do with the system or wants the system to do for them that it doesn’t do today.

It’s not a description of a person wanting to accomplish a task somewhere, as in Jobs to be Done (JTBD). It’s a description of a person wanting to accomplish something in your system. JTBD is great for customer empathy in the problem space. User stories are great for translating that customer empathy into a series of changes to a software system, while maintaining the user’s perspective throughout.

Concepts:

Prioritised

The word "order" or ordered is sometimes used instead of "prioritised" list. It helps suggest that you can't have more than one no.1 or no.2 priority for example.

Sprint

A sprint or iteration is literally just a fixed time-box, typically a 2 week period.

The MVP (Minimum Viable Product)
The Product Roadmap