Flow Framework Part 2: The four types of items in a product backlog

projecttoproductI am a Technical Product Owner, working for Croesus, and I’ve always felt that something was wrong in my product backlogs for a long time. After reading the book “Project to Product” several times, and gained some experience with the concept, I can now confirm: there are four types of items in any product backlog. They are mutually exclusive and comprehensively exhaustive (MECE). Mik Kersten, the author of “Project to Product”, makes it clear when explaining the Flow Framework, but I wanted to try it before writing about it. Are there really four types? Why not five or three?

Four types of items flowing the value stream

 Features

Everybody knows that type of flow item… I mean, it’s the obvious one! All product managers, or project managers, are asking them most of the time. According to M. Kersten, a feature will “deliver new business value and will be pulled by internal or external customers”. This new value will add new business results and will be visible to the customer.

 

 Defects

When the customer experiences a problem with the product, we call it a defect. It means that there is a quality problem so the fix will deliver the missing quality.

 

 

What are the two other types of items that we should find in our product backlog?

For years, I thought only about bugs and features. But, now that I have spent the last year experimenting with the four types of items in my product backlog, and getting demands about security and refactoring, architectural changes, I had to admit that they are not bugs or features. The two other types are Risks and Debts.

Risks

This type of item includes various kinds of security, regulation, and compliance. This work can be pulled by business analysts, chief security officer (CSO), or any tools like Claire or Nessus analyzing security breaches. Any findings will have to be planned, worked, tested, deployed, and maintained. This work will not be visible to the customer if done appropriately. On the contrary, the customer will be notified via the front page news when an important risk item will have been dismissed by the product team. So, the priority of the type of item will have to be fairly high over defects or bugs.

Debts

The last kind of item is my favorite one and I will have many articles coming up to explain how we control it in my teams. It’s technical debt reduction, which, according to M. Kirsten, “describes the need to perform work on the software and infrastructure codebase that, if not done, will result in the reduced ability to modify or maintain that code in the future”. Examples of that will be refactoring, API addition, infrastructure automation, performance improvement. We will do this kind of work to speed up the future delivery of features and bug fixes.

What advantages will I get to manage my product backlog with these four types of items?

The short answer will be “Agility”.

Transparency

The first and obvious advantage is transparency, one of the three pillars of agile. Once you get each type of item his own space, you will be able to see what is going on with your product. It will be very informative for the stakeholders and will lead to technical, and business discussions.

Inspection

If you have better visibility over debts and risks, you will be able to better inspect, by making the right analysis. If the risk and debt items are lost and hidden behind features and bugs, or worst, invisible, it’s not possible to do the right inspection in time.

Adaptation

Better transparency and inspection will lead to a better adaptation. With the right processes in place, you will be able to take better strategies when dealing with features, defects, risks, and debts.

Conclusion

I was pleasantly surprised when experimenting with the last two types of items. Most of today’s tools like Jira, Azure DevOps Boards, Trello, are not offering these four kinds of items by default. It’s very unlikely, but at least, now, I know, and you know too!