The product backlog workflow

The emergence of the Kanban Guide for Scrum teams has given new metrics and practices to development teams on how they can augment their Sprint Backlog to manage their work. As these benefits are more and more integrated within Scrum teams, there is another backlog in the Scrum Guide that can benefit from the same metrics and practices. And that is the Product Backlog.

According to the Scrum Guide, the Product Backlog is:

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Scrum Guide, 2020, Product Backlog

This is a great starting point for the business to list what is needed in the product. I also find it has disadvantages as the life of the product goes from a couple of weeks to a couple of years. As time goes by, PBIs start piling up in the Product Backlog. More stuff comes in than actually comes out. Other people create PBIs in the Product Backlog. The product owner lacks the time to properly review them. It can then become a mess while the product is having success on the market. In this article, I explain how Kanban metrics and practices can leverage the way PBIs flow through the Product Backlog Kanban metrics for the Product Backlog.

The Kanban Guide for Scrum teams identifies Work Item Age as being:

The amount of time between when a work item started and the current time

Kanban Guide for Scrum teams, p. 5

While this is a valuable metric within the Sprint Backlog, let’s see how we can apply it to the Product Backlog. Before a PBI spends time in the sprint backlog, it will generally spend time in the Product Backlog as well. Examples of activities on PBI while in the Product Backlog are: refinement of the PBI, sharing its knowledge with the development team, and preparing the PBI for development. After an amount of time spent in the product backlog, it ends up in a sprint.

In the following image, we look at the Product Backlog from an aging perspective, meaning for how long (or old) each PBI has been in the product backlog. The Y-axis shows the number of days the PBIs have been there. At the top of the image, where it says WIP: 75, meaning the product backlog has 119 PBIs.

​Using the PBI age gives the Product Owner more clarity on the time spent by each PBI in his Product Backlog. While it can make sense for the Product Owner to have several ideas in flight, I believe it is reasonable to ask the Product Owner how long the idea should be in flight. Looking at the image above, a Product Owner could start by reviewing the oldest PBIs (the ones at the top) to see if they are still relevant. After more than 400 days (that’s more than a year) spent in the Product Backlog, is the PBI still meaningful?

Our second Kanban metric, the Work In Progress, shows the product backlog holds 75 PBIs. This could be seen as a reasonable amount of work. On the other hand, I’ve seen Product Backlogs with more than 500 PBIs in them. One can ask the question when there are enough PBIs in the Product Backlog. As we teach Scrum teams to limit their work in progress to lower their cycle time within their sprint, we could do the same with the product backlog. By limiting the work in progress within the product backlog, PBIs will spend less time in the product backlog.

Our third Kanban metric, cycle time, and its distant cousin, the Service Level Expectation (SLE), can also be of use in the product backlog. When capturing the SLE of the Sprint Backlog workflow from my current Development Teams, I generally get values between a few days up to being close to the duration of the Sprint.

Now what would be the desired SLE for a PBI in the product backlog workflow? I don’t think there’s a definite answer. At the same time, I believe it should be known and discussed to see if that SLE makes sense to the Scrum Team. In the following image, you can see the cycle time scatter plot for the Product Backlog workflow of a Scrum team. Yes, this is real data taken from a Product Backlog for a full year with 817 completed items.

​At the top, the summary box states that:

• 50 % of the PBIs take 5 days or less to go through the product backlog workflow
• 70 % of the PBIs take 36 days or less to go through the product backlog workflow
• 85 % of the PBIs take 288 days or less to go through the product backlog workflow

As I was saying above, I don’t think there’s a definite answer on what is a good SLE for the product backlog. On the other hand, I find it useful to have a conversation with the Product Owner to see if it makes sense to have such a gap between 70 % and 85 %.

Based on my experience with Kanban metrics in Scrum Teams, I’ve witnessed product backlog SLE of 89 days or less, 85 % of the time, and in another Scrum Team, it had a SLE of 59 days or less, 85 % of the time. In both cases, the number of PBIs in the Product Backlog was over 150 items.

As the Product Owner is using Kanban metrics on his product backlog, it also opens the door to new policies for the Product Backlog workflow. What is the maximum age a PBI can be in the product backlog? Does it make sense to have more than 100 PBIs in there? Is it getting difficult to browse through the product backlog with so many items? Is the current SLE acceptable and if not, what can we do to lower it? A retrospective could be a good opportunity to work with your Scrum team to answer those questions, leading them to new visualization, team, and pull policies around the Product Backlog.

From list to workflow

Even with the Kanban metrics perspective, our product backlog is still an ordered list as we’ve seen in the first image of this article. Let’s use the first Kanban practice, Visualization of the Workflow, to gain more transparency on this ordered list.

When using Kanban with Scrum, I find our instinct is to naturally visualize the sprint backlog workflow. We add new columns. We set WIP limits. We define pull policies. We actively manage PBIs in progress. Nothing prevents us from doing the same with the Product Backlog.

To get us started at transforming our list into a workflow, I’ve found the Definition of Ready between our Product Owner and his Development Team a good starting point. Another place to find inspiration is at Refinement meetings. By listening to conversations at that meeting, you can discover implicit columns where PBIs are in the Product Backlog.

Let’s take a very simple Definition of Ready with the following items to explain what I mean:

• Acceptance criteria are written and understood
• Scrum Team accepts user experience artifact
• All technical dependencies have been resolved
• External dependencies are identified

The third item in this list indicates there is some technical work to be done. Maybe a developer has to review the impact on the code of the PBI currently in the Product Backlog. Maybe a quick experiment with another team’s API has to be prototyped. All of this probably means a column named “Technical” in the Product Backlog will emerge.

The second item in the list above, Scrum Team accepts user experience artifact, seems to indicate there is some sort of UX being involved. This could underline a UX column in the product backlog.

From my experience, I’ve seen the following columns emerge in a Product Backlog workflow:

• To review: An entry point column where the PO checks if she accepts the new PBI in her Product Backlog. Examples of work in this column are checking if the new PBI is a duplicate of an existing one or asking a developer to investigate if the PBI is technically possible. By putting this column as the entry point, it invites due diligence on the PO to review new PBIs.
• To do: From what I’ve witnessed, this is the column of the Product Backlog with the most PBIs in it. It contains old bugs, wish lists, requests kept alive to reassure a stakeholder, and PBIs that will be coded (one day) to name a few.
• Technical: Anything that needs some technical attention (Ex: technical review of a proposed solution, proof of concept less than a few hours, high-level technical solution to get agreement).
• Functional: Anything related to UX (Ex: screens, logos, wording)
• To Refine: PBIs which will be reviewed during a Refinement session
• Refined: PBIs who were refined and are ready to go into the Sprint Backlog
• Candidate: A holding column for PBIs that are ready for the next Sprint

Please note that not all these columns appear in the Product Backlog workflow nor are they in this specific order. They are a compilation of what I have seen up until now. If you’ve worked with additional columns in your product backlog workflow, feel free to list them by writing a comment at the end of this article.

Our second Kanban practice, Limiting Work In Progress (WIP), can be of value for specific columns of the Product Backlog. Let’s take for example the Candidate column. In the following image, it is the last column of the Product Backlog. We show the interconnection between the Product Backlog and Sprint Backlog workflow through the Candidate and Ready columns.

​The Candidate column holds PBIs that are ready for development. They are held there until the Development Team requests more work, whether at the start of the Sprint or when the Development Team requires more work.

We can set a WIP Limit on the Candidate column of about the same size as the Ready column of the Sprint Backlog. As it is the column for pending PBIs ready for the next Sprint, we want to limit the number of items in this column. If the Development Team has a WIP limit of 10 PBIs per Sprint, my proposition is the Candidate column has around 10 PBIs.

​The Technical and Functional columns can also have a WIP limit. In one Scrum Team, we overloaded the development team by putting too many PBIs in the Technical column. Developers paid more attention to the work in this column and forgot to focus on their work in the sprint backlog. By putting a WIP limit of 4 on the Technical column, it limited their time spent on those PBIs during the Sprint.

On occasions where I’ve helped expand the product backlog into a workflow, I’ve also been witness to more engagement from the Development Team. As more transparency is gained in the Product Backlog workflow through columns and policies, some of them will require a contribution from developers. I’ve found this to open up the conversation on the level of engagement asked by the development team on upcoming requirements. This new level of transparency gives developers visibility on what is coming up and what they should do to prepare the PBIs before they are coded. Their pursuit of self-organization, it shows them the work to accomplish.

​However, I’ve had developers react negatively to this new level of transparency. Some arguments I’ve heard were how their time is solely dedicated to the Sprint Backlog and the Product Backlog is the realm of the Product Owner. On another occasion, developers initially did not know how to organize their time between PBIs in the Sprint and Product Backlog workflow. In this last situation, having a Refinement meeting during the Sprint would help developers focus on PBIs in the Product Backlog during the Sprint.

In conclusion

I believe a Product Backlog workflow is a major improvement on the initial list mentioned in the Scrum Guide. Kanban practices and metrics offer more visibility to the Product Owner on what resides in the Product Backlog. It gives her an additional toolset on how to manage her Product Backlog.

While the term DevOps continues to tighten the gap between developers and operations, the BizDevOps trend, where the gap between business and software development also tighten, could be initiated with a more visual and limited WIP Product Backlog workflow. Only the future will tell us.