What is an architecture backlog, and why should we have one?
Oliver Goldman defines an architecture backlog, and examines the similarities, differences, and relationships between that and a product backlog.
From the author of
From the author of
From the author of
Most software professionals are familiar with the product backlog, which is a list of planned and potential changes to a software product. For example, the product backlog for a task management application might include "add repeating items," a new and undoubtedly useful capability. Indeed, the product backlog concept is key to most iterative software development processes, and it gives teams a way to collect, manage, and prioritize future work that's well-suited to what are often dynamic, ever-changing environments.
An architecture backlog works the same way as a product backlog but, instead of capturing planned and potential changes to the product, it captures planned and potential changes to the system's architecture. And just like a product backlog, it's an excellent mechanism via which architects and architecture teams can collect, manage, and prioritize their work.
Items in an architecture backlog are often related to items in a product architecture backlog, but there's not a simple one-to-one correspondence between them. The are four types of relationships that can occur:
- One-to-none: Not all product backlog items will require any architectural work. Ideally, very few do, as that indicates that the system's architecture is well-suited for the product, and it enables rapid progress. New capabilities that "fit the mold" of existing capabilities often fall into this camp: if you've already added weekly repeating items to your task management application, monthly repeating items shouldn't require reworking your design.
- Many-to-one: Multiple items in a product backlog can sometime be addressed with a single change in the system's architect. Separate product backlog entries for weekly, monthly, and custom intervals for repeating items call out for a single design change. Identifying such cases is an essential skill for architects, as doing so drives simplicity and gains leverage from implementation efforts.
- One-to-many: Sometimes, though, what looks like a simple item in the product backlog can require more than one significant change to the system. If you're expanding from task management to calendar management, you might want to tackle that expansion as multiple work items. When that's the case, the architecture team can log those as separate items in the architecture backlog, making it easier to parallelize the work.
- None-to-one: Last but not least, the architecture team might identify changes that they need to make that don't correspond to a specific product backlog entry. For example, a system's architects might know that they need to change search index technologies in anticipation of future growth—even though the system already supports searching through your tasks.
These varied relationships illustrate why architects shouldn't try to work directly from the product backlog. Architects need to keep track of the relationships between items in the two backlogs, and it can be convenient if organizations use the same tools to track the two. But the lack of one-to-one relationships makes it clear that architects shouldn't try to work directly from the product backlog; it simply doesn't capture all their work items.
That is also why it's valuable for architects to maintain a architecture backlog. Without a backlog, your work tends to be driven by the product backlog—and only what's on the product backlog. Among other downsides, in this situation, the architecture work that needs to be done but doesn't correspond to a product backlog item tends to get ignored or forgotten. That's a poor outcome that, over time, will degrade the system's architecture and make future work more difficult.
Architects will sometimes try to address these problems by entering architecture items directly into the product backlog. That makes the architecture items visible, but it tends to confuse prioritization exercises. Product backlogs are prioritized by product managers (or product owners). Asking product managers to prioritize architecture work is both unfair to them and an abdication of architectural responsibility. Product managers should be aware of the architecture backlog, but they shouldn't be asked to do the architect's job for them by prioritizing that work.
An architecture backlog is, just like a product backlog, an essential artifact for iterative software development. It captures planned and potential architecture work items. It records the relationship—if any—between architecture backlog items and product backlog items. And it serves as an essential input to the architecture team as they tackle each next iteration.