The Product Backlog

This is one in a series on Scrum Intro. The preceding post is here.

Intro

The Product Backlog is usually the first mentioned of the artifacts. In some sense, Scrum starts with the Product Backlog, or at least the first Sprint cannot start without a Product Backlog. The Product Backlog is a list of all the work for the team. We also think of the Product Backlog as the list of all the new features for the current product.

User Stories

One name for the items in a Product Backlog is PBI (Product Backlog Items). We also speak of those items as User Stories, especially if they are in the User Story format.

The User Story format is:

As a <end user role>

I can <do something>

So that <explain purpose or next step or because>.

Who can contribute

It is important that the Product Backlog include all the work of the team. More on this later.

Anyone can contribute to the Product Backlog (the PBL). This is important and often mis-understood. Any team member can propose a PBI. Any Business Stakeholder can propose a PBI. A customer can propose a PBI.  Anyone.  Well, anyone with a lick of sense.

Does the PO have to accept all contributions?   No.  Use a little common sense.

The PO can judge an item out of scope. The PO can improve the quality of an item proposed for the PBL. The PO can rewrite a PBI.  And the PO can prioritize each item.  (Well, it is a somewhat complicated process how a PBI gets prioritized.  Ultimately the PO is responsible that the ordering of the PBIs is good and becoming better.)  So, some items will go low on the list and may never get built (done, worked on, etc).

Prioritzed

The PBL is prioritized. The final prioritizer is the PO. By this we mean that anyone can suggest things to be considered in the prioritization or suggest new data that would affect the prioritization. In general, we first say that the prioritization is mainly based on Business Value or the value to the end customers.

Later we say that prioritization should mainly be by POI (Business Value divided by investment — with investment being mainly cost or effort). In truth, there are other factors as well (dependencies is a key factor).

PBL Length

The Product Backlog should go out a reasonable amount. Jeff Sutherland has said a typical length is one year for a typical product. Surely this could be less for some products and more for other products. In my experience, many PBLs do not go out far enough.

This is actually a serious problem, because it means that the PO is choosing from too few items “what is the most important PBI to work on next.” That means that the team is typically not working on the most important thing it could be working on.

The 80-20 Rule

In general, for a given product, the PBL should help the PO do the 80-20 rule or something close to it. That is, the Team does 20 percent of the work and delivers 80 percent of the Business Value. This is hard to do (for many reasons), but focusing on this issue is very very useful. For example, if the team did 20 percent of the work and got 50 percent of the Business Value, that would be a serious and very useful improvement.

Kinds of Work

The PBL should include all the different kinds of work the team must do. The PBL should include any legacy bugs, meaning bugs or defects that existed before the team started this working on the product. The PBL typically includes technical debt (sometimes expressed as technical stories). So, the PBIs include stories to fix the technical debt.

If we are automating QA tests, then the PBL probably needs to include PBIs to automate the existing manual tests or needs PBIs for the work to set up or improve the automated testing.

Sometimes we have a separate list of “small enhancements.” Often these enhancements are small changes to the existing set of features. When we describe the vision of the next release of the product, it does not include small enhancements to the existing features. Hence, these small enhancements are often work outside the vision of the next release — except that someone feels we must do some of them. There can be other categories.

We do not have separate Product Backlogs. Each team only has one Product Backlog. Hence, “everything” (all the different types of PBIs) must be prioritized together in one Product Backlog. Not always an easy job.

PBL Refinement

The Product Backlog must be refined or groomed over time. New items are identified later, and may be identified soon as part of the current release or maybe a later release or maybe never will be built.

Product Backlog Refinement or Product Backlog Grooming includes many things. Among them are identifying new stories, breaking up larger stories (stories too big to go into a Sprint well), putting Story Points on stories, adding or revising the Business Value points on stories, adding details to stories (as much as the team needs), reorganizing the order of the stories, etc., etc.

We have a whole book to describe Product Backlog Refinement. See our book on Agile Release Planning.

The next post in this series is here.

« « The Artifacts || “Path to CSP” – The A-CSM » »