Operational Backlog

The Operational Backlog is the appropriate location to represent work required in the product that may not have direct customer value and would not be written or represented by the customer. Examples of items in the Operational Backlog are code re-factoring or other technical debt, environmental or infrastructure setup, ongoing maintenance activities, etc...

While these items could be located in the Product Backlog, they typically are not directly exposed to the stakeholders during sprint reviews and are not required to be calculated in the Release Burn Down Chart. Often times Product Owners have difficulty having these items in their Product Backlog because they have little understanding of them. However, it is important that the items in the Operational Backlog be balanced and prioritized with the items in the Product Backlog during the release. Often this balance in prioritization requires discussion between the Product Owner and an architect representing the team. Too much focus on either backlog will negatively impact the other. If the Operational Backlog items are ignored, the technical debt will increase and the product architecture will become fragile increasing future development efforts. Too much focus on the Operational Backlog may be interpreted as over-engineering a solution and the team will miss out in early visibility and feedback of new features.

Items in the Operational Backlog may be pointed like user stories or simply tackled as operational tasks during a sprint. Either way there is a cost in time and resources to tackle the Operational Backlog. Over time Product Owners tend to get comfortable in representing from a high level the value of certain items in the Operational Backlog and include them clearly in the release planning.